The white rose, the pink rose and the vodka rose are in the garden.
test me with “x rose/x a rose”[/code]
The result is:
[code]garden
Someone planted it.
You can see a white rose, a pink rose and a vodka rose here.
x rose
Which do you mean, the white rose, the pink rose or the vodka rose?
x a rose
(the white rose)
You see nothing special about the white rose.[/code]
In the second situation, the parser assumes I’m talking about the rose which comes first in the source, but I want him to behave just as he would in the first case.
I have no idea what’s going on here, but using the debug command ‘trace 3’ reveals that NounDomain is operating differently in the two cases. Unfortunately, NounDomain is buried in the I6 layer – it’s not in the Standard Rules at all.
You can open the files in the Reserved folder using a text editor and search for NounDomain. That might give you a clue. I strongly recommend against editing those files, however.
As far as I6 is concerned, I confess myself clueless, so I guess I’ll take your advice against messing with it, for the time being.
But this is bugging me. In this case, the differences between the two are of little to no consequence, but in my WIP, if the player writes “burn a note”, the parser burns “the wrong note” without asking twice.
Inform regards X ROSE as short for EXAMINE THE ROSE. Because “the” is English’s definite article, X THE ROSE implies that the player has a particular rose in mind. So, Inform enter disambiguation mode to find out exactly which rose you are interested in.
In contrast, X A ROSE specifies the indefinite article “a”, which implies that the player doesn’t care which rose he examines; any rose will do. So, since the player has already indicated that he isn’t interested in any particular rose, Inform avoids the intrusive disambiguation process.
I think that’s pretty much how the system should act, but it is a productive question to ask whether X ROSE should default to X A ROSE instead of X THE ROSE. I’m not sure how to change that default; it may require hacking the parser or it may not. Someone else might have more insight into the technicalities.
The bits of interest here are the I6 routine Descriptors and the flag indef_mode. One could certainly hack the parser to change their meanings, but I would recommend a does-the-player-mean rule instead:
Does the player mean examining the pink rose: it is likely.
You won’t get the disambiguation prompt, but you do keep the parser from choosing the wrong noun without any mucking in I6.
That’s a good, easy solution to the burning of the wrong note, although honestly I’m not convinced that there really is much of a problem, at least for native English speakers. I can’t imagine that too many native speakers would write BURN A NOTE in the situation originally described; far more likely would be BURN THE NOTE (i.e., the particular note I’m thinking of, which will result in disambiguation), or just plain BURN NOTE.
Well, I’m assuming that if this has never been a problem before, then I shouldn’t be worried.
I’ve added a “does the player mean…” rule, and also a new “rule for clarifying the parser’s choice”, so that I get a (I don’t think there will be a problem in burning this one, but I better stop torching things at random) kind of answer, instead of (the dark note)
X ROSE is pretty much the standard thing for an experienced IF player to type, isn’t it, going back to Adventure? And it takes less typing than either of the alternatives. It should definitely be parsed as the safest alternative – it would be unimaginably obnoxious if X ROSE picked a random rose for you rather than asking you which you wanted. Especially, as sometimes happens, when the player doesn’t know that there’s an ambiguity in the area, and so takes the response to X ROSE to apply to the wrong object.
This is interesting. I’m filing indef_mode away with my far-off plans for a parser rewrite. It would be useful to be able to switch it on for manual parsing. (e.g. “if the player’s command includes…”)
