Confusion about WWI 17.19 Does the player mean examples

WWI 17.19 Does the player mean… includes the following:

Notice that we can also make rules about actions that apply to two objects, so for instance:

Does the player mean throwing the can of shoe polish at the shoe polish vending machine: it is likely.

which nicely clarifies THROW POLISH AT POLISH, but does not comment on the likelihood of throwing the can at other things or of throwing other things at the vending machine.

But there is a caveat. There are some cases where this mechanism will not in fact help Inform to choose its way out of an ambiguous command, because of the way it parses one noun at a time. It usually needs to understand the first noun before it will even try to make sense of the second. So a rule like:

Does the player mean throwing the can of shoe polish at the tree: it is likely.

may not work if the player types THROW POLISH AT TREE and POLISH is ambiguous, because when the parser is trying to understand POLISH, it hasn’t yet seen to the end of the command and realised that the second noun will be the tree; so the second noun is unset and the rule won’t match.

I don’t think I’m alone in being confused by the fact that these two examples seem to be identical except that in the first case the word “polish” applies to both the noun and second noun and yet the note for the second example indicates that the prospective identity of the second noun is not determined when the noun is being considered (and so implicitly cannot affect the outcome for the noun).

Testing in 6M62 shows that the shoe polish/tree example seems to work just fine for disambiguation (when that’s necessary; note that the grammar line for the throwing it at action uses the [something preferably held] token, which also influences disambiguation).

What gives? Is this text just outdated, or a typo of some kind? Or is there some aspect that I’m missing?

For reference, the test scenario I have been using:

Place is a room.

A fixed in place thing called a shoe polish vending machine is in Place.

A fixed in place thing called a tree is in Place.

A can of shoe polish is in Place.

Does the player mean throwing the can of shoe polish at the shoe polish vending machine: it is likely. [when absent, prompts for disambiguation; when present, works as expected]

Does the player mean throwing the can of shoe polish at the tree: it is likely. [when absent, prompts for disambiguation; when present, works as expected]

It does not seem to matter whether the vending machine is fixed in place or not.

As a side note, the CheckDPMR() routine is not in a template file but is found in an I6 inclusion in the Standard Rules. There’s a line

	rv = FollowRulebook( (+does the player mean rules+) );

that I think should be

	rv = FollowRulebook( (+does the player mean rules+), 0, true); ! MODIFIED

… otherwise you can get some line breaks when the DTPM rules are checked.

3 Likes

I was confused by this too, and had my own sample. I thought perhaps it need extra ambiguity on the second noun, but that didn’t change anything.

The does the player mean rule works perfectly in this example, even though the parser (according to the docs) won’t know which tree is being used until later.


"Test"

The Great Outdoors is a room.

A tin of Shoe polish is a thing in the Great Outdoors.

Shoe polish vending machine is a thing in the Great Outdoors.

A thick tree is a thing in the Great Outdoors. It is fixed in place.

A tall tree is a thing in the Great Outdoors. It is fixed in place.

Does the player mean throwing the tin of shoe polish at the thick tree: It is very likely.

Like most of the parser the code is somewhat obscure, but it is the case that when the parser is trying to disambiguate the first noun (here ‘polish’) part way through parsing it does try to look ahead to identify the second noun clause in the typed command (here ‘tree’) and match it to an object in scope (here ‘the tree’) also matching the relevant second noun token in the grammar line it’s working with (here NOUN_TOKEN), before invoking DTPM rules.

The relevant DTPM rule in your example DOES therefore fire when the command ‘Throw polish at tree’ is typed.

Perhaps this look-head manouevre may not work under absolutely all circumstances, but WI as it is written is clearly overly pessimistic.

1 Like

You’re talking about the code in the ChooseObjects() routine? I’ve wandered through that section before but didn’t analyze what’s really going on in detail.

Fun fact for interested observers: There is some debugging code around disambiguation, which can be activated by specifying the constant COBJ_DEBUG and which produces output to show how disambiguation scoring is being applied. (EDIT: Note that this debugging constant may be applicable to 6M62 only.) Some sample output from a scenario modified from the above:

>THROW POLISH AT TREE
[choosing a cobj strategy: 2 possible second nouns]
[scoring the shoe polish vending machine (first) in 2 combinations]
[the shoe polish vending machine / the apple tree => 2]
[the shoe polish vending machine / the lemon tree => 2]
[scoring the can of shoe polish (first) in 2 combinations]
[the can of shoe polish / the apple tree => 4]
[scored 4 - best possible]
[scoring the apple tree (second)]
[the can of shoe polish / the apple tree => 4]
[scoring the lemon tree (second)]
[the can of shoe polish / the lemon tree => 3]
(the can of shoe polish at the apple tree)
(first taking the can of shoe polish)
Futile.

It looks like for a two-thing action:

  1. An abbreviated parsing routine is executed to look for the presence of words in the player’s command that might designate the “other” thing.
  2. A separate “alt” match list is developed for that other thing.
  3. The current match list and the alt match list are combinatorially examined via the DTPM rules, and…
    3a. if one combination emerges the victor because the choice for each item was clear, then the things matching that combination are chosen.
    3b. if one noun is clear and the other is not, it will ask for disambiguation only for the unclear one
    3c. if both are unclear but after disambiguation of one the other becomes clear, then the correctly-matched other noun is chosen.
5 Likes

Yes, exactly that.
I hadn’t spotted the COBJ_DEBUG thing- nice tip!

I waded through the code and added some of my own debugging commentary (invoked by the ‘trace’ debug command) to a customised ChooseObjects routine.

There are a bunch of these. TEXT_TY_RE_Trace in RegExp.i6t, BLKVALUE_TRACE in BlockValues.i6t; DBLW in ListWriter.i6t. TRACE_I7_SPACING in Printing.i6t (6M62) / Paragraphing.i6t (10.1).

TEXT_TY_RE_Trace is still straightforward to use in 10.1, 'cause it’s a global. The others still exist, but they’re constants and the related output only exists if the constant is defined at the time of compilation, and the kits are precompiled. So setting them in user code does no good. One would have to replace the kit locally to turn them on.

3 Likes

These just got new names in the current development version.

  • LKTRACE_LIST_WRITER for DBLW
  • LKTRACE_HEAP for BLKVALUE_TRACE
  • LKTRACE_SPACING for TRACE_I7_SPACING
  • LKTRACE_CHOOSE_OBJECTS for COBJ_DEBUG