Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000280Core InformUnderstandingpublic2010-09-06 18:562010-10-28 00:31
Assigned Tograham 
Platformx86OSMac OS XOS Version10.6
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000280: Using multiple synonym words not parsed when they're slash-separated in Understand rule
DescriptionUnless something's gone wrong on my end, it seems as if using multiple synonym words in a command causes the command to no longer be recognized. "examine magnifying glass" is no longer parsed correctly if those two words are both defined in Understand rules, separated by a slash.
Minimal Source Text To Reproduce
Stage is a room. The disc is in Stage. Understand "magnifying/glass" as the disc.

test me with "x disc / x magnifying / x glass / x magnifying glass / x glass magnifying / x magnifying 
glass disc / take magnifying glass".
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
related to 0000162closedgraham names that should be understood sometimes aren't, especially in disambiguation requests 

-  Notes
AaronReed (reporter)
2010-09-06 19:07

For what it's worth, on my system at least this happens in released games, as well. (Under Gargoyle on a Mac.)
Juhana (reporter)
2010-09-07 02:19

I thought this was the intended behavior? Manual chapter 16.12: "When the alternatives are in any way complicated, "or" should always be used, but a shorthand form is allowed for simple cases where it is only a matter of a single word having several possibilities: Understand "reach underneath/under/beneath [something]" as looking under."
Ron Newcomb (reporter)
2010-09-07 12:38

I thought this was intended behavior? As in,

    Understand "magnifying/looking glass" as the disc.

will catch "magnifying glass" and "looking glass" but not "magnifying looking glass".
AaronReed (reporter)
2010-09-07 13:28

I could be wrong, I suppose, but I'm reasonably certain this is not correct behavior. The example Juhana cites is about understanding new grammar lines, not synonyms for nouns. I disagree with Ron that his example shouldn't understand "magnifying looking glass"; the parser should see two tokens, "magnifying" and "looking glass," both of which match the disc, and therefore the command should be understood. (I believe, however, that this version would be correct in rejecting "magnifying looking" or "magnifying glass," since the space indicates those words are only understood in combination.

Barring interventions by other code, the parser should be able to understand any word in a thing's name, as well as any single words defined as synonyms, as referring to that thing, no matter what order or combination they're used in.
jmcgrew (administrator)
2010-09-07 15:19

I agree with Ron's example: the slash only combines individual words, not phrases, so "magnifying/looking glass" does not match "magnifying", and therefore "magnifying looking glass" won't match.

However, I think Aaron's report is still valid because he's using single words. My understanding is that "magnifying/glass" should match either "magnifying" or "glass", the same as "Understand 'magnifying' or 'glass' as the disc". AFAIK there's no indication that only one of the alternatives may be used in a given noun phrase.
Ron Newcomb (reporter)
2010-09-07 15:49

I just know that the slash and the Or (incl. comma) work differently. It was done that way on purpose, for when a noun is being used as an adjective. Ex: "car/Honda key" allows car/Honda as an adjective, but "key" is required, and the key cannot be referred to as simply "car" nor "Honda".
jmcgrew (administrator)
2010-09-07 15:58

I'd expect the slash and "or" to work identically when single words are involved. They're implemented differently, which would be fine except that the current implementation results in some unintuitive, undocumented restrictions on what sort of noun phrases are allowed. The first example under Additional Information at 0000162 demonstrates this too, where "brown stetson hat" fails to match when the hat is understood as "chapeau/hat", but works correctly when it's "'chapeau' or 'hat'".

"car/honda key" should, as I understand it, be identical to "'car key' or 'honda key'". The space is what makes "key" required, not the slash.
Juhana (reporter)
2010-09-07 22:58

I've always thought the use of slash quite logical in that it means "exactly one of these", where "or" means "one or more of these". I'd find it unintuitive if "magnifying/looking" would catch "magnifying looking" but "magnifying/looking glass" would not catch "magnifying looking glass". It would be yet another exception to remember and there wouldn't be a syntax for "exactly one of these" for single words anymore. What if I didn't want "key/keys" to catch "key keys"?
Ron Newcomb (reporter)
2010-09-08 10:04

Yeah, what Juhana said. The explicit or is always an inclusive or. The slash is always an exclusive or.

So this is a feature request, not a bug?
jmcgrew (administrator)
2010-09-08 10:27

At the very least, it's a documentation bug, because the difference between slash and "or" is not documented. In fact, section 16.12 of the manual ("This/that") implies there is no difference:

Understand "reach underneath/under/beneath [something]" as looking under.

This is shorthand for:

Understand "reach underneath [something]" or "reach under [something]" or "reach beneath [something]" as looking under.

I remain convinced that this is a compiler bug, though. Here's a similar test case:

Home is a room.
A key is here. It is privately-named.
Understand "house/car" as the key.
Understand "key/kee" as the key.

The key can be referred to as:

house, car, key, kee, house key, house kee, car key, car kee

But not:

house car, car house, key kee, kee key, key house, key car, kee house, kee car

If you swap the two Understand statements, "house key" becomes invalid and "key house" becomes valid (etc.). The generated parse_name routine only matches a subset of the names that the code implies: it expects all the slashed parts to appear zero or one times, in the order they were defined in the source code. (Also, it seems "name property words" -- defined by simpler Understand statements and the object name -- can appear before or after the slashed parts, but not intermingled with them.)
AaronReed (reporter)
2010-09-08 10:34

I really don't think this is a feature request. 16.22 says:

>1. Understanding the names of things. As we've seen since the earliest chapters, we may
>add to the vocabulary used to refer to an object in the game, or to an entire class:
>Understand "fish" as the trout.
>Understand "fish" or "dinner" as the trout.
>Understand "fish/dinner" as the trout.
>Understand "gentleman" as a man.
>If we use an entire phrase, as here
>Understand "red bird" as the robin.
>Inform will match only the full phrase and not its components; so EXAMINE RED BIRD
>would work, but not EXAMINE RED or EXAMINE BIRD.

I certainly read this as implying that the second case (Understand "red bird") is an exception to the default behavior, not the normal behavior, and that the middle two lines in the first block of Understand rules should have the same effect.

General parsing philosophy also seems to be in favor of this interpretation. The DM4 says that the parser "tries to be generous in what it accepts from the player, understanding the broadest possible range of commands and making no effort to be strict in rejecting ungrammatical requests," and gives the example that "'green green tomato green fried green' is considered a very good match indeed" for fried green tomatoes. With this in mind, making the player type 'Understand "fried" and "green" and "tomatoes"' seems like a lot more work for the default behavior than 'Understand "fried/green/tomatoes".'

A separate issue is whether it's confusing that the slash is an Exclusive Or in Understand rules for verbs, and an inclusive one in Understand rules for nouns. Also separate is whether allowing spaces and slashes together in an Understand rule for nouns causes unnecessary confusion. But I think what's going on here is incorrect behavior.
emshort (administrator)
2010-09-09 05:32

The documentation may be explaining it poorly, but the slash is consistently an exclusive or, and this is intentional.

The issue that Jesse brings up about the ordering of the source text does sound like a compiler bug, however.
AaronReed (reporter)
2010-09-09 11:32


This ought to be made much more explicit in the docs, then. I always thought that 'Understand "magnifying/glass" as the disc.' would let "magnifying glass" be understood. Lots of code to fix...
graham (administrator)
2010-10-10 12:53

This is a complicated issue, but I have improved matters by following a maximalist strategy (as in the DM4): one can now use any sequence of Understand lines to refer to an object, so that the sequence of Understand sentences is no longer relevant. (Jesse's examples work as he expected, with house car, car house, key kee, kee key, key house, key car, kee house, kee car all working.)

- Issue History
Date Modified Username Field Change
2010-09-06 18:56 AaronReed New Issue
2010-09-06 19:07 AaronReed Note Added: 0000519
2010-09-06 23:27 jmcgrew Relationship added related to 0000162
2010-09-06 23:27 jmcgrew Status new => acknowledged
2010-09-06 23:35 jmcgrew Status acknowledged => confirmed
2010-09-06 23:35 jmcgrew Steps to Reproduce Updated View Revisions
2010-09-06 23:35 jmcgrew Severity serious => mild
2010-09-07 02:19 Juhana Note Added: 0000521
2010-09-07 12:38 Ron Newcomb Note Added: 0000525
2010-09-07 13:02 Ron Newcomb Issue Monitored: Ron Newcomb
2010-09-07 13:28 AaronReed Note Added: 0000527
2010-09-07 15:19 jmcgrew Note Added: 0000528
2010-09-07 15:49 Ron Newcomb Note Added: 0000531
2010-09-07 15:58 jmcgrew Note Added: 0000532
2010-09-07 22:58 Juhana Note Added: 0000538
2010-09-08 10:04 Ron Newcomb Note Added: 0000541
2010-09-08 10:27 jmcgrew Note Added: 0000542
2010-09-08 10:34 AaronReed Note Added: 0000543
2010-09-09 05:32 emshort Note Added: 0000544
2010-09-09 11:32 AaronReed Note Added: 0000545
2010-10-10 12:53 graham Note Added: 0000686
2010-10-10 12:53 graham Status confirmed => resolved
2010-10-10 12:53 graham Resolution open => fixed
2010-10-10 12:53 graham Assigned To => graham
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:31 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker