Differentiate preposition from partial word in ParseNoun?

Has anyone ever implemented a ParseNoun routine that implements partial word matches yet avoids matching on prepositions expected later in the grammar?

If so, how was that accomplished without the ParseNoun routine having access to the entire set of tokens for the current grammar line?

Not sure what you mean by “partial word” here. One word from the object’s word list?

Parse_name routines (we’re talking I6 here) are traditionally greedy – matching as much as possible – and you avoid verb prepositions by not putting “in” or “on” into the object’s word list.

If you’re trying to have the object respond to (e.g.) “the coin in the wallet”, that is indeed tricky, but the best plan is to eat words and backtrack if the relationship doesn’t match correctly. So the command “put coin in slot”, the parse_name routine should stop after “coin” because the object is not currently in the slot. For the command “take coin in wallet”, it will stop after “wallet”. This rule enables the parser to correctly handle “put coin in wallet in slot”, although it’s going to choke on “put coin in wallet in wallet”.

Thank you very much for your feedback, zarf! :slight_smile:

I have a custom ParseNoun routine that allows a player to refer to a noun by only a portion of its word. So a word like “thief” would match “thi” or even “t”.

I am aware of the drawbacks to this, but I have decided that it is crucially important for my players to be allowed to use such abbreviations.

Disambiguation still works properly.

However, what does not work is when the ParseNoun routine is given text such as “top to the thief” in the phrase “give top to the thief”. This is because the ParseNoun routine is greedy and is unaware that we are expecting a preposition in the grammar.

This, to me, is extremely unfortunate, and makes no sense. In my opinion, prepositions ought to be simply punctuation or syntax, and to have a ParseNoun routine which is incapable of being syntax aware is a significant problem.

I think that I may have to somehow modify the grammar line loop to place all anticipated prepositions for a grammar line into a global variable, which is then checked in the ParseNoun routine to ensure that the word currently being parsed does not exactly match an expected preposition.

This makes me a little sad, though. Zarf, or others, might you suggest an improvement or alternative to such an approach?

Thank you,
-Nels

It will be easiest to special-case “to”, “in”, and “on”, and not worry about the current grammar.