I anticipate this problem can’t be solved in a way I’d like, but I must ask anyway.
If I have two women in a room (each one of kind woman), each with their own name, and the player types ‘X WOMEN’, I want to force disambiguation. (e.g. Do you mean Jane or Donna?)
I usually achieve this kind of thing by allowing both objects involved in the comparison to be recognised by the same plural word, so that Inform can’t decide. In this case, the word would be ‘women’, but this is a fundamental plural name for a kind set by Inform, so the game instead gathers the women together then says ‘You can’t use multiple objects with that verb.’
I doubt that I can or should hack ‘women’ out by changing the plural of woman to some arbitrary untypeable word? (and then manually make every woman be understandable as ‘women’)
I am adamant that I don’t want to tweak EXAMINE to allow it to work on multiple objects. e.g. Allow ‘examine [things]’. This also rules out me using the extension ‘Actions on Groups’.
I haven’t come up with a real solution. The best I’ve got is to only let one of the women be referred to as ‘women’, meaning it would cheatily favour her whenever you used the plural in the presence of both. This means ‘women’ isn’t even recognised if she isn’t around at the same time as her friend, but in the current situation, she always is.
I think the cleanest solution to the default plural names thing ends up being making things privately-named, the downside being that it’s up to you to write explicit Understand lines for your things.
lab is a room.
A woman is usually privately-named.
Alice is a woman in the lab. Understand "alice" as alice.
Consuela is a woman in the lab. Understand "consuela" as consuela.
Understand "woman", "women" as woman.
Test me with "x women / alice / x woman / consuela".
> test me
(Testing.)
> [1] x women
Who do you mean, Alice or Consuela?
> [2] alice
You see nothing special about Alice.
> [3] x woman
Who do you mean, Alice or Consuela?
> [4] consuela
You see nothing special about Consuela.
I should clarify that “things” there was colloquial; you probably don’t want to try this with the thing kind or you get some unfortunate behavior where get things wants disambiguation to some single thing but get all things still works. It works out okay with people 'cause the only actions taking multiple things – dropping, taking, putting it on, removing it from, inserting it into – won’t involve people.
Oh, this looks a lot better than my own approach, which would have been to add a “women” scenery object, though that would have only given me an extra description value to use for the two of them, together. It still wouldn’t proceed directly to disambiguation, and there might be other issues I haven’t anticipated.
Unfortunately, Inform’s handling of plural names of kinds is deeply-ingrained into the compiler and very difficult to modify. This is especially unfortunate because its default handling is often not what you want! For example, if you make a “women” scenery object, that won’t fix the problem—the word itself is set to always be plural, so it will try to match as many objects as it can instead of just the one.
The easiest solution is to hack out Inform’s handling of this word entirely.
The plural of woman is asdfasdf.
Understand "women" as a woman.
Don’t worry, this doesn’t affect your code. You can still say “repeat with the chosen one running through women”. The only place it’ll cause a problem is if you have multiple unnamed, indistinguishable women in the same place.
Now it’s no longer considered innately plural, so EXAMINE WOMEN will match both women individually and disambiguate. The only downside is that an action that accepts multiple objects will also disambiguate instead of trying to affect all of them at once…but I believe the only default verbs that accept multiple objects are ones like TAKE and DROP that don’t work on people anyway.
(I always do this for the “door”, “container”, and “supporter” kinds, which are also unlikely to be taken and dropped. Inform’s default parser also can’t tell the difference between “container” and “containers”, or “supporter” and “supporters”, and it makes more sense for TAKE CONTAINER to disambiguate than to say you can’t use multiple objects with that verb.)
lab is a room.
The plural of woman is asdfasdf.
Understand "women" as a woman.
alice is a woman in lab.
consuela is a woman in lab.
still results in:
> x women
You can’t use multiple objects with that verb.
I7’s okay with things having multiple plurals (c.f., people, persons). The plural of woman is asdfasdf. doesn’t undo the parser considering women still meaning the plural of woman, it just adds asdfasdf as another plural. Barring replacing a section of the Standard Rules to rename the kind altogether, the privately-named strategy is the only way I know to avoid the creation of kinds’ expected plural names being understood as the plural of the kind.
Ah, you’re right. I forgot that the Standard Rules specifically lay out the irregular plurals for “man”, “woman”, and “person”:
The plural of man is men. The plural of woman is women.
While we can override a default plural generated by the compiler, we cannot override a plural that’s explicitly specified by the rules.
So we’ll need to replace that part of the SR.
Section - Replacing Plurals (in place of Section 12 - Animals, men and women in Standard Rules by Graham Nelson)
A man is a kind of person.
The specification of man is "Represents a man or boy."
A man is always male. A man is never neuter.
A woman is a kind of person.
The specification of woman is "Represents a woman or girl."
A woman is always female. A woman is never neuter.
An animal is a kind of person.
The specification of animal is "Represents an animal, or at any rate a non-human living creature reasonably large and possible to interact with: a giant Venus fly-trap might qualify, but not a patch of lichen."
WI is a bit vague on this point, as it implies that if you define multiple plural forms for a kind they will all be interchangeably recognised.
This is in fact only true as far as the compiler is concerned- you can talk about women or asdfasdf (or any other plurals you have defined) in assertions setting up the initial state of the world (or other source) and the compiler will recognise them all.
However, when objects of that kind are created, in place of a compiler-generated plural they will have just the first plural you have defined in source included in their I6 ‘name’ property (and therefore recognised by the parser as referring to that object), and the same word as their I6 ‘plural’ property (== I7 printed plural name).
So the parser will by default recognise just this one plural form in commands (unless you include additional Understand .... as the plural of woman phrases) and the same plural form will be the default printed plural name for all things of that kind.
If you want to stop ‘women’ in a command being recognised as referring to any female adult humans in your story, you have to either:
(i) as Daniel has suggested, remove the declaration ‘the plural of woman is women’ from the Standard Rules (and hope this doesn’t break any reference to ‘women’ somewhere else in the Standard Rules) so that this won’t be the first definition of the plural of woman the compiler comes across.
Then remember to provide your own (possibly ‘untypable’) declaration- The plural of woman is asdfasdf- otherwise the compiler’s auto-generated plural version of ‘woman’ will be automatically used instead.
EDIT: if you take this route and need to avoid the possibility of the parser printing ’ two asdfasdf’ instead of ‘two women’, add The printed plural name of a woman is usually "women", which restores this as the default plural for printed output while leaving ‘asdfasdf’ as the plural name the parser recognises
OR
(ii) remove ‘women’ from the I6 ‘name’ properties of the female adult human objects in your story- something only easily achieved, especially in I7, by removing the I6 ‘name’ property from those objects altogether. This is what making an object privately-named does (as Zed has suggested).
Then provide Understand "Letitia" as Letitia. etc. phrases to allow commands to refer to each of the otherwise nameless (to the parser) female adult human objects in your story.
Also possibly an Understand "women" or "woman" as a woman. (rather than ‘…plural of woman’) phrase so that either of these terms in a command refers to any single adult human.
Note that by default, the singular form of a kind is not understood by the parser as referring to any object of that kind, singular or plural, so examine woman as a command won’t be understood by the parser unless you have primed it with Understand "woman" as a woman.- thereby injecting the name ‘woman’ into the recognised names of every woman object created. This is obviously in contrast to plurals of kinds, which are understood by the parser by default, because (for example) by default ‘women’ is injected into the recognised names of every woman object created.
EDIT The exception to the last paragraph is if you create so-called ‘unnamed’ identical objects, such as with ‘There are six women in the Lab.’ This creates six ‘indistinguishable’ woman objects (so-called because nothing the player types can distinguish one from another) each of which has the name of the kind as its I6 name property- in this case ‘woman’. So in this case, without the need for a separate Understand... phrase, the player can type ‘examine woman’ and it be recognised- the parser will pick one of the ‘indistinguishable’ women present for you to examine.
When I saw Zed say ‘Make them privately-named,’ I internally screamed ‘OF COURSE!’. That solution was probably too close to home for me to think of.
As the number of things in the game is now > 600, I make everything privately-named, to the extent I was recently tempted to set all things to be privately-named by default. I only haven’t done this because then I’d have to revamp the publicly-named things that are early in the game, and I feel like why bother when they’re working and have been tested a lot already? EDIT - Plus Zed pointed out a broader danger in doing this.
I was thinking of something like that, too. Because these women, when you first see them, you don’t know their names. So you can only examine them by ‘women’. Doing so tells you both their names, at which point I will make it so that ‘women’ goes to disambiguation. But initially, they present as one thing.
@Zed Actually, can you clarify this? When you say ‘get things’ do you mean something like ‘get coins’? versus ‘get all coins’? Despite what I just said, I am still thinking of making things privately-named by default. I realised how much time I spend doing it explicitly, and fixing bugs when I forget to do it.
I meant straight up get things per se. And I found a reason why it’s problematic to make even people privately-named by default, let alone things. This code:
Lab is a room.
A person is usually privately-named.
Cerberus is an animal in the lab.
Alice is a woman in the lab.
Bob is a man in the lab.
(iv) they are considered identical by the parser, in that they respond to the same syntaxes of name: so that it is impossible to find a TAKE X command such that X matches one and not the other.
seems to think that privately-named things can safely be lumped togther under the banner of the plural of the kind of the first one it encountered, or at least that’s my best guess so far.
Yeah, but this particular issue is not specifically a result of writing A person is usually privately-named.
It’s a consequence of having three unnamed (as far as the parser is concerned) things in the Lab. It can’t list them by name, so has to do so by kind. It’s a bug in the list-writer that it then chooses to group them together despite being of different kinds- it should say ‘You can see an animal, a woman and a man here.’ Or at worst, ‘You can see three people here’ or ‘You can see three things here.’
These both demonstrate exactly the same bug:
Lab is a room.
Cerberus is a privately-named animal in the lab.
Alice is a privately-named woman in the lab.
Bob is a privately-named man in the lab.
Lab is a room.
An animal is usually privately-named.
A woman is usually privately-named.
A man is usually privately-named.
Cerberus is an animal in the lab.
Alice is a woman in the lab.
Bob is a man in the lab.
Or try this, and you get four devices…
Lab is a room.
An animal is usually privately-named.
A woman is usually privately-named.
A man is usually privately-named.
The box is a privately-named device in the lab.
Cerberus is an animal in the lab.
Alice is a woman in the lab.
Bob is a man in the lab.
Of course, give them names through Understand... as... and the bug isn’t triggered- they’ll be listed by name.
…that seems to be shaving a point excessive fine: if there hadn’t been a privately-named assertion affecting them, they would have had names.
But why can’t it list them by name? They all have perfectly good printed names that the game could use if it wanted to. I’m not seeing why it’s a feature to involve what grammar lines do or don’t exist in a decision about how to generate output regarding the things, i.e., I’m opining that the bug here is looking to the grammar at all.
The issue here is also not with having things privately-named and then naming them through Understand.... as... phrases. It’s that after Understand "things" or "thing" as a thing every object of thing kind or any of its subkinds is created with the word ‘things’ and the word ‘thing’ as one of their singular names.
When trying to match a noun token (or multi-token) the parser has no regard for kinds per se. It is just looking for a match in an object’s name property. The command ‘take all devices’ to the parser doesn’t mean ‘take all objects of kind device’ it means ‘take all objects for which you can match the word ‘devices’ in their name property’. The only reason it appears to recognise the plural names of kinds in commands such as ‘take all devices’ is that the compiler-generated plural of an object’s ‘lowest-ranking’ kind in the kind hierarchy is by default automatically listed by the compiler (flagged as a plural form) in the name property of each object created of that kind- in this case, for any device, ‘devices’. Note that ‘take all things’ won’t work on devices- ‘things’ is only listed in the name properties of plain things which are not a sub-kind like people, devices, containers, etc. etc.
As mentioned elsewhere in this thread, the singular form of the kind name is not automatically listed by the compiler in an object’s name property. So, by default, ‘take every device’ won’t work (nor the ungrammatical ‘take all device’) while ‘take every devices’ will. Again, ‘take every device’ means to the parser ‘take every object for which you can match the word ‘device’ in its name property’.
‘Take devices’ is a slightly different situation- the parser starts out trying to match any one object’s name property against ‘devices’- but if it finds a match flagged as being a plural form, it will then assume the command is trying to match against multiple objects with ‘devices’ in their name property- and reject the command if the action (such as examine) doesn’t allow that.
Returning to our example, after:
Lab is a room.
Understand "things" or "thing" as a thing.
The sonic screwdriver is a device in the lab.
The transmaterialiser is a device in the lab.
The deioniser is a device in the lab.
after the command ‘take things’, the parser sets out initially to match ‘things’ against any one object with ‘things’ in its name (it has no idea at the outset that ‘things’ is necessarily a plural word)- makes multiple matches none of which are flagged as plural forms, so asks a disambiguation question in order to pick just one of them:
Which do you mean, yourself, the sonic screwdriver, the transmaterialiser or the deioniser?
after the commands ‘take every thing’ or ‘take all thing’ or ‘take every things’ or ‘take all things’, the parser sets out to make multiple matches, matches every object and tries to take each of them:
sonic screwdriver: Taken.
transmaterialiser: Taken.
deioniser: Taken.
(it also matches the name of the player object , but rejects taking that)
The point I was making (badly) is that it’s been suggested that using phrases such as ‘a person is usually privately-named’ leads to problems. That isn’t necessarily true. It’s having multiple unnamed things in one room that leads to this problem. Those things can be equally well declared individually as privately-named, the same problem arises. And if they aren’t in the same room or are given names through Understand... as .. there is no problem.
You’re right- that is true. It shouldn’t be trying to list them by kind at all.
I’m not certain why you have concluded this is bug is something to do with grammar lines?
'cause that what the bit of ListWriter I quoted said it was doing. PartitionList calls ListEqual which calls Identical in Parser.i6t
|Identical| decides whether or not two objects can be distinguished from each
other by anything the player can type. If not, it returns |true|. (This
routine is critical to the handling of plurals, and the list-writer
requires it to be an equivalence relation between objects: but it is,
because it is equivalent to $O_1\sim O_2$ if and only if $f(O_1) = f(O_2)$
for some function $f$.)
OK, but two or more objects being indistinguishable to the parser isn’t to do with grammar lines, it’s to do with those objects having indistinguishable name/parse_name properties.
But the list-writer clearly has the misapprehension that if objects are indistinguishable to the parser they are indistinguishable for listing- which as you point out makes no sense if they have different printed names. Or kinds, come to that- although I guess it would be the case if they weren’t privately-named, objects with different kinds would always have distinguishable name properties.
So anyway I agree, it’s a function call not fit for purpose.