I ran into this the other day (Inform 10, the test code runs the same on Borogrove as locally): . I had a lot of alternative verbs and two ways of arranging the nouns, and thought “I’ll make a grammar token to handle all the alternatives for the verbs, and that’ll make the code more compact and I won’t forget to add the alternative noun arrangement if I add another synonym.”
So I did something like this:
"Frotzification"
The Lab is a room.
Bob is a man in the lab.
Persuasion rule for asking Bob to try doing something: Persuasion succeeds.
frotzing is an action applying to one thing.
Understand "frotz/frotzify" as "[frotzing]".
[ Understand "frotz [something]" as frotzing.]
Understand "[frotzing] [something]" as frotzing .
Report someone frotzing:
say "[Actor] ensures that the [noun] is now thoroughly frotzed, at least for now.".
Report frotzing:
say "The [noun] is now thoroughly frotzed, at least for now.".
The ball is in the lab.
But when I run it, I get:
Lab
You can see Bob and a ball here.
>Frotz ball
The ball is now thoroughly frotzed, at least for now.
>bob, Frotz ball
There is no reply.
If I use the alternative grammar line, without the “[frotzing]” token, then it works. It’s clearly triggering the “block answering rule”, but I don’t understand why.
This kind of thing (having a token rather than a single verb word as the first element of an ‘Understand [token] … as …ing’ phrase) is discouraged because although it sort of works under some circumstances, this so-called ‘verbless grammar’ isn’t fully and properly implemented- which is why the compiler doesn’t allow you to write ‘Understand “frotz/frotzify [something]” as frotzing.’
EDIT: The bug in 9.3/6M62 that led to incorrect assignment of topic snippets after commands such as ‘Darcy, hello’ when a story included any verbless grammar has been fixed in 10.1.2, but other issues persist.
This specifically is because when the parser fails to parse the command after the comma in a command of the form ‘NPC, …’ into a valid action for the NPC to perform, the action generated instead is ‘Answering NPC that …’ assuming everything after the comma is merely a topic of conversation (like ‘Nice morning’) rather than an instruction to act.
I’ve idly wondered if Inform’s traditional system for handling grammar lines (looking up the first token of the command in the dictionary, then using its “verb number” to index into a table of grammar lines) is still needed. The speed improvements of doing this rather than just checking every grammar line are pretty small, given how much processing I7 does for everything else, and it could get rid of the inconsistency between verb lines and no.verb lines.
This really only throws up an issue for no.verb grammar lines, which might potentially throw up a match as well as or instead of a match in a standard set of grammar lines. If the verb word is ‘throw’, then all the matching grammar lines will be found in the ‘throw’ group, or (potentially) in the ‘no.verb’ group, so there’s no point looking elsewhere.
The difficult and presently unresolved question is dealing with the situation where the verb word has a match in both the ‘throw’ group and the ‘no.verb.’ group. As you know, the parser’s current response is to completely ignore the ‘no.verb’ group if it can’t make a match in the ‘throw’ group.
A simple tweak to the parser can override this, so that it goes back to consider ‘no.verb’ lines if it has failed to match any ‘throw’ line (see discussion and example elsewhere)
The end result is that all possible matches are open for consideration, but that matches in the ‘throw’ group always take priority over matches in the ‘no.verb’ group.
This partly reflects a wider issue in I7 whereby the priority of grammar lines is calculated by the compiler (in a mostly good, but arcane and occult manner) and can’t as far as I know be directly enforced by an author.