Verbless grammar interfering with TAKE ALL (and other things)

Authoring Inform 7
1

I have some verbless grammars in my WIP. In response to TAKE ALL in a room with nothing to take I get parser error internal rule response (R) instead of “There are none at all available!”. You can see the trace below. I can understand what’s going on – the no.verb grammars are being tried last – but I wonder if there’s a way to at least print something nicer. I’m open to ideas. There are a number of places this problem crops up, but TAKE ALL is probably the most jarring of them, so I’m focusing on that first.

Thanks!

> take all
[ “take” take / “all” all ]
[Parsing for the verb ’take’ (10 lines)]

[line 0 * ’inventory’ -> Inv]
[line rejected for not ending with correct preposition]

[line 1 * multi -> Take]
 [line 1 token 1 word 2 : multi]
  [Object list from word 2]
  [Calling NounDomain on location and actor]
<SNIP!>
   Revising multiple object list of size 7 with 2nd nothing
   Token 2 plural case: number with actor 0
   Done: new size 0
[Parsing for the verb ’no.verb’ (2 lines)]

[line 0 * scope=Routine(1007386) -> A98_discussing]
 [line 0 token 1 word 1 : scope=Routine(1007386)]
  [Scope routine called at stage 1]
  [Scope routine returned multiple-flag of 0]
  [Object list from word 1]
  [Calling NounDomain on location and actor]
   [NounDomain called at word 1
   seeking definite object
  [Scope routine called at stage 2]
   [ND made 0 matches]
  [token resulted in failure with error type 18]

[line 1 * Routine(647371) noun -> A95_supplying_an_answer_with]
 [line 1 token 1 word 1 : Routine(647371)]
  [Outside parsing routine returned -1]
  [token resulted in failure with error type 1]
I’m not sure what you’re trying to say. I might just not recognize the words 
you’re using.
1 Like
2

I’m not saying this is a good idea, because I never really figured out what unwanted side effects this might have, but when I was dealing with some annoying parser error messages, I ended up handling some situations with “Understand as a mistake” lines with conditions attached. So, for example, if the person typed “take all” when there’s nothing portable available to take, you could write “There are none at all available” or some other message.

To decide if nothing's available to take:
	repeat with T running through touchable things:
		if (T is not the player) and (T is not enclosed by the player) and (T is portable):
			decide no;
	decide yes.
	
Understand "take all" as a mistake ("Custom response goes here.") when nothing's available to take.

Lab is a room.

A prop is here.

Test me with "take all / take all".
1 Like
4

The “most interesting” parser error is being set by the grammar line for the discussing action. What do the I7 grammar lines for that action look like?

5 
Understand "ask about/-- [any q-available questioning quip]", "say [any q-available informative quip]", "say [any q-available performative quip]", "a [any q-available questioning quip]" as discussing.
Understand "[any q-available quip]" as discussing.

where q-available is a computed truth value.

Edit: I don’t know if it matters, but there is also:

Understand "[something related by mentioning]" as a quip.
1 Like
6

I’m having trouble reproducing the behavior that you’re seeing. The parser has special logic for >TAKE ALL that seems designed to take precedence. Do you have a minimal example? (Also, what version of Inform are you using?)

7

6M62. So far my minimal example is my IFComp entry :slight_smile: but I’ll keep looking.

8

In the >TRACE output that you provided, the lines

Revising multiple object list of size 7 with 2nd nothing
Token 2 plural case: number with actor 0
Done: new size 0

should indicate activation of the special >TAKE ALL case in the parser that would halt grammar line processing.

For this not to be happening, either you or an extension would have to be modifying one or more of the following sections of Parser.i6t:

  • Parser Letter F
  • Parser Letter G
  • Parsing Descriptors
  • ReviseMulti

Can you find anything like that anywhere?

1 Like
9

Found the culprit. I was using Dr Peter Bates’s code here:

I don’t know if there’s inherently a bug in PB’s code, or if his code just doesn’t work in 6M62.

Fortunately, I can’t seem to reproduce the bug I originally brought that code in to fix, so it seems safe to remove it.

Thanks! I used your suggestion to search for Parser.i6t modifications to find the offending extension.

1 Like