I’m sorry, but i just can’t agree with you here. Perhaps i can with the idea of making things easier, but it seems your argument is broadly;
Lets not worry the parser’s pretty little head on these things and instead make this an authoring problem and let them work around it.
Personally, i prefer making authoring easier.
That’s because you’re not the one fixing parser bugs.
EDIT-ADD: To be clear, my perspective is off to the side; I’ve followed a lot of parser bug discussion but I’m not the one responsible for fixing them.
My point is: it’s very easy to come up with a “perverse” example and then propose a parser change that fixes it. It’s much much harder to propose a change that fixes that case and all the more complicated variations that come up in real life and doesn’t break another dozen cases which you didn’t realize would be affected.
Making one author’s life easier often makes another author’s life harder.
No, it’s more a case of you’ll probably find in most instances the game is not worth the candle (for those not familiar with this English idiom, referring to the burning down of a candle in order to complete a game of, say, chess, it means any benefit may be worth less than what you need to expend to achieve it).
In this instance, although we can all wish for a perfect parser that always accurately discerns the player’s intent (though we all may have a different idea of how that perfect parser would behave), for an individual author it is unlikely to be preferable to try to (even partially) rewrite the parser rather than when possible prevent situations arising that it doesn’t deal with as one would wish.
That, I would suggest, is the easy approach to authoring.
To rewrite the parser to behave as you would like (and you really would have to accept that wouldn’t necessarily produce something that everyone would like) is not a trivial undertaking. But it could be done, and published as an extension, if you wished.
I doubt we’re ever going to agree here, but I think you’re perhaps making the perfect the enemy of the good.
Almost all objects described as ‘X of Y’ can be happily parsed without considering the ‘of’ as being anything other than a ‘name word’ like any other. Many could never be transformed into something different (Hound of the Baskervilles, piece of eight, sheet of paper) and most that in theory could (cup of coffee) will not in practice become so in most games.
So rather than construct complicated general systems of grammatical parsing to deal with uncommon exceptions, and require authors to engage with them (for example, by always specifying what a word like ‘of’ actually signifies in context) it’s much better to keep the parser in general dealing with the simple case, while allowing an author to deal with the complex exception if needed (as demonstrated by @otistdog, for example, by Understanding cup of x by a relation).
Does it restrict synonyms? It’s not intended to do so, or to penalize anything – it just gives a bonus for player input exactly matching the printed name.
I’m not sure that I’m correctly understanding what you mean, though. In your example, wouldn’t the words “volume” or “tome” only apply to the coffee table book, so that if they were used then the parser would correctly be choosing the book before it ever even needs to run the DTPM rules?
The general description of the problem (as I understood it) is that there is a set of words W that map to a set of at least two in-scope objects A and B, and there is no superset of words W’ that can apply only to object A. The logic of exactly-matched is that, in such a situation, object A is given preference, because if the player wants B then a non-A word can be used.
Oh, I didn’t know this was an English phrase! A couple of my law school professors used it frequently and I always assumed it was one of those things lawyers like to say to confuse lay-people. I always understood it to be about a game where you’re gambling for money, though – like, the stakes are so low that you’re unlikely to win back enough to pay for the candles you burned for light during the game. Though could just be that’s drift from using the phrase specifically in the legal context, where someone’s typically trying to get money out of someone else…
Er, anyway, on topic, I’d agree that there’s an argument that making authors work harder to compensate for parser weaknesses can be annoying, here I’d think the issue is more about the player’s experience – if I was playing a game where I walked into a room and was greeted with a cup of coffee, a coffee table, and a coffee table book, I know I’d emit a long-suffering grimace in anticipation of the disambiguation challenges to come. That sparing the player also means sparing the author is a fortunate coincidence.
Is it kosher to say screw it and misspell each instance slightly?
I walked into a room and was greeted with a cup of cofee, a coffey table, and a coffie table book.
Or is that too much of a blantant language crime?
Oh no no no that’s not a typo, that’s a feature!
The return of covfefe…
A lot to unpack here.
First:
I have a confession to make: I asked this merely out of intellectual curiosity. I’ve never tried to write anything that actually had some coffee, a coffee table, and a coffee table book in it: I was just using it as an example. Having said that, I have tried coding games that had a car and a car key, or a piano and a piano bench, and have felt frustration with some of the Inform parser’s limitations in that regard.
I haven’t tested this, but wouldn’t that mean it’s impossible for the player to use “coffee” on its own to refer to the table, even if the cup of coffee was no longer in scope?
Agreed.
If I were seriously writing a game that had all three objects in it, then depending on the circumstances, the printed name of the coffee table book would be its title, at least after the player examines it for the first time. But I still think it’s best to provide objects with as many synonyms that the player might reasonably type as possible, and it’s not out of the realm of possiblity for the player to call a coffee table book a coffee table book. An art form may be constrained by the limitations of its medium, but is it really out of Inform’s capabilities to give authors more control over how to match names to objects?
[…]
Absolutely. That’s why I’d settle for a simpler “adjective” versus “noun” parsing system. READ COFFEE should simply assume that “coffee” refers to the coffee in the cup, not the other two objects, because noun matches should take precedence over adjective matches. When there are two noun matches or two adjective matches, these should be equal in precedence, and the parser should then ask for clarification.
That’s fair. However, isn’t this partly caused by your familiarity with Inform? I know that when I was new to parser IF, with no knowledge at all of Inform, I expected “coffee” to refer to the coffee in the cup, and “table” to refer to the coffee table. I expected disambiguation to come into play only when the coffee is no longer visible; then X COFFEE would ask whether you mean the table or the book.
I seem to recall that TADS does give authors more control over parsing names, and provides a way to distinguish “coffee” from “coffee table” out of the box. I could be wrong, though.
Anyway, I don’t want to give anyone the wrong impression. I don’t think Inform’s parser should be completely rewritten to accommodate me. I simply wanted to know if there was a relatively painless way to accomplish what I wanted: a way to indicate “strong” versus “weak” matches, or a “noun” versus “adjective” system, and to distinguish between a “light light” and a “heavy light”, or an “apple” and an “apple tree”. I appreciate all the input everyone has provided here.
Finally, thanks also to otistdog for taking the time to write an explanation for the inner workings of the parser and some possible solutions. I find some of Inform’s default assumptions to be strange.
For example, in the scenario I provided, if you simply type TAKE COFFEE as the very first move, the parser assumes you mean the coffee table. Does this make any sense to anyone? Wouldn’t it be better to assume that the player wants to take something portable, or at the very least not make assumptions and ask the player to clarify? The response to DRINK COFFEE is even worse (“There’s nothing suitable to drink here.”)
Which is fine, and easy to arrange, but a player shouldn’t expect to be able to type just ‘read coffee’ when the object isn’t referred to in the game using that word.
To be fair, Inform does make that easy to achieve:
Does the player mean doing something with the coffee cup: it is likely.
Or add in Disambiguation Control, and you can say “does the player mean the cup of coffee when also considering the coffee table” (i.e. apply a weighting only when these two objects are under consideration).
Fair enough. I was thinking of a situation where the printed name of the book starts as “coffee table book” and then changes to its actual title when the player examines it. Or the book’s description is something like, “A coffee table book…” I take your point that it’s best to avoid these name clashes in the first place, but sometimes you just don’t want the limitations of the parser to determine what you call an object.
That’s the way I would have done it, too, except that testing it produces some side effects. If you have a coffee table and a coffee cup in the same location, without that DTPM rule, typing TAKE on its own produces:
>take
What do you want to take?
With the DTPM rule in place, it no longer asks what you want to take: it just assumes you mean the coffee cup. It does the same for all verbs in which the player fails to mention an object. This isn’t the behaviour I want. Maybe there’s a way to phrase a DTPM rule so this doesn’t happen, I don’t know.
Disambiguation Control would neatly solve all these issues… except it breaks chained commands, and it’s incompatible with other extensions that replace parts of the parser. Anyway, I’ve accepted there isn’t a perfect solution to what I’m asking for, and that it’s not really a big deal, all things considered.
Well, you could tweak it so that the rule only operates when the parser is not inferring an absent noun, but also my personal feeling is that a player who types simply ‘take’ in the presence of a number of takeable objects can’t expect or be surprised by any particular outcome. Do players really do this?
EDIT: e.g.
Does the player mean doing something with the coffee cup when not inferring a noun: it is likely.
To decide whether inferring a noun: (- (match_from > num_words) -).
Interestingly, the plain ‘take’ type of command is one of the few situations where the parser will ordinarily not make a guess as to the object(s) intended.
The parser doesn’t attempt to guess when:
(i) no noun-matching words are supplied at all, but more than one object could equally-plausibly (according to the parser’s disambiguation rules) make sense in context
→ e.g. ‘take’, ‘take the bead from’, leading to ‘what do you want to take?’ or ‘what do you want to take the bead from?’
(ii) one or more noun-matching words are supplied, but more than one matching object could equally-plausibly (according to the parser’s disambiguation rules) make sense in context
→ e.g. ‘take bean’, leading to ‘which do you mean, the red bean or the green bean?’
These are situations where the parser assumes the player is referring to a single, specific object but it can’t find a single best match.
Conversely, if the parser is able to assume that any one or more of a number of objects would do, (what it calls ‘indefinite mode’) it prefers to make a choice- even if there are other unchosen objects which could equally plausibly (according to its disambiguation rules) make sense in context.
E.g. (in the presence of a red bean, a green bean, a yellow bean, a red marble and a red coin, all in a cup):
Lab
You can see a cup (in which are a red bean, a green bean, a yellow bean, a red marble and a red coin) here.>take red
Which do you mean, the red bean, the red marble or the red coin?
but
>take a red
(the red bean)
Taken
Here, the use of ‘a red’ signals to the parser the same as ‘one red’, i.e. ‘choose any one thing matching the following word(s)’. The red bean is chosen over the other red objects for the same reason it is listed first in descriptions- in the I6 object tree it is the eldest child of the cup. After taking the red marble then reinserting it in the cup, the red marble is now the eldest child of the cup and will be chosen instead:
Lab
You can see a cup (in which are a red bean, a green bean, a yellow bean, a red marble and a red coin) here.>take marble
Taken.>put it in cup
You put the red marble into the cup.>look
Lab
You can see a cup (in which are a red marble, a red bean, a green bean, a yellow bean and a red coin) here.>take a red
(the red marble)
Taken.
Similarly:
Lab
You can see a cup (in which are a red bean, a green bean, a yellow bean, a red marble and a red coin) here.>take two bean
red bean: Taken.
green bean: Taken.
However, this ‘object tree’ method for choosing from among matching objects is only the last resort, used only if they score equally in disambiguation: if we make one bean score more highly than the others, it will be chosen first:
Does the player mean taking the yellow bean: it is likely.
Lab
You can see a cup (in which are a red bean, a green bean, a yellow bean, a red marble and a red coin) here.>take two bean
yellow bean: Taken.
red bean: Taken.
The way this works under the hood is that the parser makes a list (the match list) of every object that matches the command, then goes through the match list in descending score order, excluding any object that makes no sense in context (e.g. it will exclude something fixed in place from a Take action) building a second list (the multiple object list) until that contains the number of objects asked for (in this case two).
Yes. I’ve seen beginner IF players do this. I’ve also inadvertently done it myself from hitting ENTER too soon. Regardless, maybe TAKE was a poor example. If the player types DROP while not carrying the coffee, the DTPM rule causes the parser to assume the player wants to drop the coffee every time. Your tweak does work; I’d tweak it even further so it only takes effect if the player typed “coffee”.
The ideal parser, in my opinion, would:
Anyway, your posts have certainly been very useful. I know I’ve been excessively nit-picky in this thread, but I really appreciate your help.
From what you’re saying, Inform treats TAKE RED the same as TAKE THE RED, but not TAKE A RED. Interesting. Now I’m wondering what would happen if you wanted to have a violin with an “A string”.