6M62 no.verb oddness

Authoring Inform 7
1

I just noticed that my WIP never says ‘That’s not a verb I recognise’. In those circumstances, it always says ‘I didn’t understand that sentence.’ So it’s producing a different parser error. (note when I say ‘always’, I don’t really know if it’s always, but it looks like it.)

This doesn’t bother me a ton in itself, but I still felt like I’d like to work out why, or if it’s always, to avoid missing potential problems.

I experimented with adding and subtracting a ton of the big–change extensions used in this game (e.g. Unified Glulx Input et al) in a vanilla project. They seemed to make no difference. The vanilla project still said ‘I don’t understand that verb.’

I turned on trace 2 and could see that in the vanilla project, typing J gives this:

[ "j" ? ]
That's not a verb I recognise

In my WIP, typing J gives this:

[ "j" ? ]

[Parsing for the verb 'no.verb' (1 lines)]
[line 0 * Routine(793591) noun=Routine(1161199) -> A149_noun_naming]
[line 0 token 1 word 1 : Routine(793591)]
I didn't understand that sentence.

So that keyed me in to this no.verb thing.

Then I dug on this site and found this topic which describes a bug with a similar quality, but probably for Inform 10.whatever.

I wonder if a similar mechanism is going on in my WIP - the mere presence of a certain type of grammar line in my game means I will always get the sentence error (didn’t understand that sentence) instead of the verb error (didn’t understand that noun)?

-Wade

1 Like
2

Yep, this is unfortunately a deep-seated problem in the Inform parser. If there are any no.verb grammar lines—that is, grammar lines where the first token is not a literal word—then a command starting with an unknown word will always produce the “didn’t understand that sentence” error instead of the “not a verb I recognize” error.

The underlying problem is extremely difficult to fix, since it comes down to the fundamental way parser errors are reported. But you can hack around it by just changing the reporting of the “didn’t understand that sentence” error.

2 Likes
3

(Arguably it’s not a bug. The “didn’t understand that sentence” error happens when a special grammar token is unable to match. If you have an Understand line starting with a special grammar token, then an unknown verb is failing to match that token. So it’s not an inappropriate error. It’s just not the ideal one for the circumstance.)

4

Thanks. It’s good to understand the cause.

-Wade

5

Hmm, actually…there might in fact be an easy fix, now that I go back and look at the parser with fresh eyes. Would you mind adding this to your project for a moment?

To decide whether no verb has been identified: (- (verb_wordnum == 0) -).
Before printing a parser error:
    if no verb has been identified:
        say "No verb identified!".

There’s a bit in “Parser Letter I” that updates the error before showing it to the player, and it’s possible that logic will save us here. It sets the error message to “not a verb I recognize” if and only if verb_wordnum is zero and the current error type is “can’t see any such thing”.

If this code says “No verb identified!” when you give commands starting with invalid verbs, and not at other times, then there’s an easy fix! We just need to update that logic to set the error message to “not a verb I recognize” if verb_wordnum is 0 and the current error type is “can’t see any such thing” or “didn’t understand that sentence”.

6

Reporting parser errors is actually more complicated than it sounds at first, since often a command will have failed at more than one possible interpretation, and the parser has to decide which was the “most interesting” failure. In this case, it’s failing at only one interpretation, using a no.verb grammar that fails with the most basic (i.e. “least interesting”) parser error.

Given the output from >TRACE, I’m a little curious about the nature of the grammar for your “noun naming” action. Can you share the Understand lines for it?

7

Heh, I added the test code, and if I type J it says ‘No verb identified!’. But I now realise I don’t know what to type to provoke a ‘didn’t understand that sentence’ error.

Looks like I have two. One is for a particular entity (money) and the other is used as part of a process.

A monetary value is a kind of value.
$999 specifies a monetary value.
999$ specifies a monetary value.
999 dollar specifies a monetary value.
999 dollars specifies a monetary value.
999 buck specifies a monetary value.
999 bucks specifies a monetary value.
999 money specifies a monetary value.
999 cash specifies a monetary value.

Understand "[monetary value]" as the money.

[]

noun-naming is an action applying to one thing.
Understand "[thing]" as noun-naming when implicit-action is not the waiting action.

-Wade

1 Like
8

It’s the parser’s fallback “I have no better error message for this case” message. If the parser fails to match a literal word (verb[1] or preposition[2]), or an object[3], or a number[4], there are special error messages for that; to get this fallback message, you need a grammar line with something that’s not a literal word, object, or number in it, and you need to put the wrong thing in that slot.

A quick test case (the grammar is awful but it doesn’t matter):

Color is a kind of value. Red, blue, and green are colors.
Painting it to is an action applying to one thing and one color.
Understand "paint [something] to [color]" as painting it to.

Now PAINT ME TO XYZZY will get a “didn’t understand that sentence” error, since the parser doesn’t know what to say about [color] not matching.

  1. “That’s not a verb I recognize.” ↩︎

  2. “I only understood you as far as wanting to…” ↩︎

  3. “You can’t see any such thing.” ↩︎

  4. “I didn’t understand that number.” ↩︎

9

Ah, OK.

The first Understand line that you shared is not the kind that creates a grammar line. The second one is, though.

The reason that the most generic error message is resulting is because the condition

implicit-action is not the waiting action

is evaluating false in this, the only grammar line being checked. That makes the grammar line fail before it can get started on trying to parse an object name, which (as Draconis notes) prevents the typical last-minute conversion of a can't see any such thing error to a not a verb I recognise error.

Depending on what the point of that condition is, you might be able to change it to get rid of this issue. Otherwise, as Draconis says, you can just try to override the error message.

10

Okay. I did the PAINT ME TO XYZZY test and it did produce ‘didn’t understand that sentence’ in my WIP, so if I read both your posts right, I could possibly fix my situation with this:

I think I see the line in parser letter i:

if (verb_wordnum == 0 && etype == CANTSEE_PE) etype = VERB_PE;

but I don’t do I6 as a native. I could guess-hack it and maybe get it right, but it seems smarter to ask what it should be as I could waste a lot of time on syntax or something.

-Wade

11

So PAINT ME TO XYZZY doesn’t say “No verb identified”? Then this issue can be fixed once and for all!

That is indeed the right line, and it’ll need to change to:

if (verb_wordnum == 0 && etype == CANTSEE_PE or STUCK_PE) etype = VERB_PE;

(STUCK_PE is the internal code for “didn’t understand that sentence”.)

Unfortunately, modifying any part of the parser is extremely difficult in version 10. Are you on 10 or an earlier version? Ideally this could be incorporated as a bugfix into the official distributions, but that might very well be the better part of a decade before it makes its way to users…

12

Everyone knows how much I love hacking the parser, but I’m not sure that I’d say that particular line is the root cause here.

Since the main cause is a no.verb grammar line, you can limit the impact of your workaround (and stay mostly out of I6) with:

To decide whether verbless parsing is occurring:
	(- (verb_word == 'no.verb') -).

Rule for printing a parser error when the latest parser error is the didn't understand error and verbless parsing is occurring:
	[say "*";] [uncomment for override telltale]
	say text of parser error internal rule response (N); ["That's not a verb I recognise/recognize."]
	say line break.

That should prevent any unwanted side effects. For example, it won’t change the output for the >PAINT verb in Draconis’s example.

EDIT: Out of curiosity, how are you defining implicit-action?

13

I think @Zed put this together for me. Normally I note these things in the source but I haven’t in this case.

The implicit-action is usually ‘waiting’ as a placeholder, and gets reset to waiting every turn.

During a turn it’s very infrequently set to something else (e.g. attacking - and not necessarily every time you attack something) which other rules are watching for. When this happens, it can change error messages or convert to the implicit-action on the thing named by noun-naming.

The point is if you ATTACK TARGET, and you could use one of several things, and it will make a difference, the game can say WITH WHAT? And you can then type a one-word answer, and not have to type ATTACK TARGET WITH SPANNER. Because being interrupted by the parser again in this moment would really screw the tension.

-Wade

14

I think this is working as intended. I test it and in my WIP, it gives ‘Not a verb I recognise’ (plus the * alert) for a command like J. And it lets what I’ll call Draconis’s PAINT example – if I enter PAINT ME TO J – through to ‘…didn’t understand that sentence.’

I still say ‘I think’, as it revealed another weirdness in my WIP, but not one that has consequence (AS FAR AS I CAN TELL!) Nevertheless I present it here for the ongoing puzzle.

In a vanilla project, if I just type PAINT (with Draconis’s paint code) I get ‘I didn’t understand that sentence.’ In my WIP, I get ‘I didn’t understand that number.’

Now as to why this probably isn’t of consequence in my WIP… I rarely leave half-successful commands to be handled by Inform’s own error messages. So anywhere in the game that has a command like PAINT A WITH B, it’s already got a ton of alt grammar constructions that would stop this raw error from appearing.

Also, Numbered Disambiguation Choices, which I’m using, has a history of being able to produce errors like this in odd places.

Back to ‘Why might this be happening in my WIP?’. Well, I’ve tried adding noun-naming, my money entity, and Numbered Disambiguation Choices to the vanilla project, and I still can’t make it say ‘I didn’t understand that number’ in response to PAINT.

Trace 3 in my WIP ends with:

 [line 0 token 3 word 2 : Routine(662369)]
  [Outside parsing routine returned -1]
  [token resulted in failure with error type 3]
I didn't understand that number.

Trace 3 in the vanilla project ends with:

 [line 0 token 3 word 2 : Routine(202691)]
  [Outside parsing routine returned -1]
  [token resulted in failure with error type 1]
I didn't understand that sentence

So there’s a different error type for the token.

-Wade

1 Like
15

Now that’s a fascinating error! It looks like Inform is producing different GPRs (the I6 equivalent to something like [color]) depending on…well, I don’t even know what.

Just to check: you’re sure the two projects are using exactly the same compiler version?

16

A quick (and somewhat simplified) overview of the way that parser error handling works.

  • All parser errors have a numeric identifier at the I6 level. These are implicitly ordered such that a higher ID value is treated as having greater priority (by virtue of being “more interesting”).
  • There is a global variable to track the current error state. Every turn it is reset to STUCK_PE, the lowest possible ID.
  • As the parser cycles through grammar lines that might match player input, it records the reason (in the form of a parser error ID) that each one has failed. Each time there is a failure, the value in the global is checked, and if the current failure is “more interesting” then it is copied into the global.
  • If no grammar lines match, the parser error ID in the global variable (exposed at the I7 level as the latest parser error) is used as the basis of the error message displayed.

If you look at the whole >TRACE output for your WIP (instead of just the last lines), it will show which grammar lines have been tried and give the ID of the error type generated by each. Your excerpt shows the last one tried failing with error type 3 (NUMBER_PE). So long as that’s the highest error code generated, you’ll get the didn't understand that number error parser error.

From what you say about implicit-action, I’m guessing that an Understand "[number]" as... line from Numbered Disambiguation Choices (which would create another no.verb grammar) is taking precedence in cases where implicit-action is not the waiting action evaluates as false. The can't see any such thing error (aka CANTSEE_PE, id value 5) – which is what will be produced by your noun-naming grammar when implicit-action is not the waiting action – has precedence over the didn't understand that number error (NUMBER_PE, id value 3), but when implicit-action is the waiting action the grammar line for noun-naming instead fails with the didn't understand error (STUCK_PE, id value 1), so the NUMBER_PE failure controls the error message.

1 Like
17

Yes. They are both on 6M62.

Hm, the extension (the version I’m using - which is post-Counterfeit-Monkey improved) doesn’t use "Understand “[number]”, maybe even because of me reporting a bug about ‘I didn’t understand that number’. It uses:

Understand the disambiguation id property as describing a thing. Understand the disambiguation id property as describing a room.

That said, when I take a vanilla 6M62 project, add Numbered Disambiguation Choices first thing, and the money, and the noun-naming, and type PAINT, it gives

(a) ‘What do you want to paint?’ if the money is in the room
(b) ‘I didn’t understand that sentence’ if there’s nothing in the room but the player.

whereas my WIP gives ‘I didn’t understand that number.’ In my WIP, there is always something in the room other than the player, without exception.

But I’m using a ton of extensions -


Alternatives 3 by Eric Eve

Approaches 7 by Emily Short

Automap 4/140513 by Mark Tilford

Before Processing a Command 1/250416 by Daniel Stelzer

Custom Banner and Version 1/220215 by Zed Lopez

Djikstra Pathing 1/230626 by Daniel Stelzer

Epistemology 9 by Eric Eve

Exit Lister 11 by Eric Eve

Extended Grammar 8/140501 by Aaron Reed

Glimmr Automap 3/111022 by Erik Temple

Glimmr Automap Tileset 1/111022 by Erik Temple

Glimmr Canvas-Based Drawing 4/160626 by Erik Temple

Glimmr Drawing Commands 3/160626 by Erik Temple

Numbered Disambiguation Choices 8/161029 by Aaron Reed

Object Response Tests 7 by Juhana Leinonen

Postures 3 by Emily Short

Simple Spelling 2/160807 by Alice Grove

Small Kindnesses 13/140501 by Aaron Reed

Standard Rules 3/120430 by Graham Nelson

Undo Output Control 5/170902 by Erik Temple

Unified Glulx Input 3/160213 by Andrew Plotkin

Variable Time Control 4 by Eric Eve

Xorshift 1/140818 by Dannii Willis

and there are then numerous tweaks applied learned from these forums.

-Wade

18

Heh. I think it was actually @otistdog who put that together for you.

1 Like
19

Oh, man – that guy!

I would just mumble something about trying rilepb’s solution instead, but unfortunately I think it would have the same basic side effect, since it also creates a conditional no.verb grammar.

1 Like