Thereâs a trick here that may not be obvious. Well, more a point of view than a trick, really.
Inform accepts multi-word combinations by default. This means that two-word Understand combinations (like âtext bookâ) should be viewed as a way to eliminate matches!
Letâs go back to the study desk example:
Understand "lamp/chair/textbooks/textbook/book/books/text book/books/--" as the study desk.
Itâs simpler and just as effective to write:
Understand "lamp/chair/text/textbook/textbooks/book/books" as the study desk.
The parser will now accept âTEXTâ, âBOOKâ, âTEXTBOOKâ, and âTEXT BOOKâ. (It will also accept âTEXT LAMPâ and âLAMP DESK BOOK BOOK TEXTâ, but as people have already said, we donât care about that.)
Now, letâs say there was a separate object called the text
which I wanted to keep separate from this scenery. That is, I want the scenery object to be referred to as âBOOKâ, âTEXTBOOKâ, âTEXT BOOKâ, but not âTEXTâ. This is where Iâd bring in the multi-word token:
Understand "lamp/chair/textbook/textbooks/book/books" or "text book/books" as the study desk.
This would do the same thing (matter of personal taste):
Understand "lamp/chair/textbook/textbooks" or "text/-- book/books" as the study desk.
In both of these examples, the word TEXT is only matched if BOOK or BOOKS immediately follows. Again, the idea is to eliminate TEXT alone as a possible match.
Iâm keeping the multi-word tokens tight here â I avoid doing big âA/B/C/D/E/-- W/X/Y/Z/-- H/I/J/K/Lâ combos. Itâs not a question of limiting matches; theyâre just confusing! I hate having to count on my fingers to see if my own code will accept a particular combination of words. My two examples above are easy to write and easy to read.