LanguageVerbMayBeName - why not use dictionary data?

There is an I6 routine used in evaluating the player response to an asking which do you mean prompt:

[ LanguageVerbMayBeName w;
	if (w == 'long' or 'short' or 'normal' or 'brief' or 'full' or 'verbose')
	    rtrue;
	rfalse;
];

Instead of a pre-defined list of words, would it not be preferable to do something like

! MODIFIED
[ LanguageVerbMayBeName w;
	return (w->#dict_par1 & 128);	! 128 is DICT_NOUN
];

instead? That way the parser will be automatically aware of any implemented objects’ name words.

The I6 compiler seems to mark every word it finds outside of a Verb declaration as nouns in the dictionary. This means that even words appearing in generated parse_name routines will be noticed.

The idea is to prevent interaction such as

>SHOVEL
What do you want to shovel?

>SNOW
Which do you mean, the snow itself or the snow shovel?

>SNOW ITSELF
What do you want to shovel the snow with?

>SHOVEL
What do you want to shovel?

in which the parser assumes that the second >SHOVEL is the start of a new command because 'shovel' is marked as a verb in the dictionary.

Nearly every word in the game has bit 128. If we used that criterion, then the function would essentially always return true, and we would mostly lose the feature that a new complete command aborts a disambig question.

The function lists only verbs that are commonly object words and almost never intended as standalone commands.

…I guess it’s not true that nearly every verb has bit 128. But a lot of them do, including Z, I, GO, and LOOK.

(The way the Inform compiler assigns that bit isn’t very rigorous. The library shouldn’t rely on it without considering the risk of false positives.)

For those following along, this routine is used by NounDomain(), and it comes into play when the parser is either 1) asking which do you mean about some set of partially-matched nouns, or 2) asking the user to enter a missing noun and/or second noun when the parser has matched the start of a grammar line that seems to be missing noun information (and it can’t make a guess about which object should be that noun).

The code blocks using the routine look like:

if (first_word ~= 0) {
    j = first_word->#dict_par1;
    if ((0 ~= j&1) && ~~LanguageVerbMayBeName(first_word)) {
        VM_CopyBuffer(buffer, buffer2);
        jump RECONSTRUCT_INPUT;
    }
}

where first_word has already been set to the dictionary word address for the first word entered in the supplemental input. If the first word was in the dictionary, and it is marked as a verb, then the parser consults LanguageVerbMayBeName() to see whether or not it should treat the supplemental input as an entirely new command.

As zarf notes in the branched thread, for words found only in Verb directives, their dictionary entries will not be marked as nouns. However, several verb words are currently more-or-less accidentally marked as nouns because the I6 compiler assumes that any dictionary words found outside of a Verb directive should be marked that way.

What I’m ultimately after is some way to handle words marked as both verbs and nouns generically, preferably automatically in a way that makes sense to authors. Maybe it would be better to simply alter the logic of the parser’s “is this a new command?” check. Right now it’s:

“If the first word of supplemental input is a verb word and that word isn’t on this special list then assume that what the player typed is a new command instead of the requested supplemental input.”

I was considering something more like:

“If the first word of supplemental input is a verb word then assume that what the player typed is a new command unless an object in scope matches all supplemental input words.”

though that would cost substantially more in processing.