Rewriting the multiple-command part of the parser

The parser machinery for multiple commands has caused quite a lot of headaches over time, since it’s very difficult to tap into it from the I7 level, and any preprocessing code has to happen before the commands are split up.

I’d like to make an extension to change this. But I’m curious if there are any potential pitfalls I need to look out for: it would basically split “reading a command” into two activities, “reading an input” and “extracting a command”, then flow something like this:

  • Call “reading an input”, which should fill in buffer1
  • Reset doneflag
  • While doneflag is not set:
    • Call “extracting a command”, which should fill in buffer2 and optionally set doneflag
    • Call the actual parser on buffer2

Now input modifications like Punctuation Removal would happen in “after reading an input”, while input modifications like adverb recognition would happen in “after extracting a command”.

Are there any major flaws in this design?


This would also help deal with this:

Inform parses a command like “ALICE, JUMP. BOB, JUMP.” as “asking alice to try jumping” followed by “answering alice that ‘bob, jump’”

Which “precedence” to give to commas versus periods could be handled by the “extracting a command” activity.

I’m not sure that extracting a command can be separated from the parser while preserving the current behavior, because of the ambiguity of the comma. In order to figure out whether “bow, go north” is a request or a chained command to bow and go north, the extractor will need to know whether “bow” is a verb or a name (in case Clara Bow is around).

OTOH that behavior is pretty erratic anyway–it only works if the command before the comma is a single word. “north, jump” or “i, jump” will be processed as chained commands, “go north, jump” and “take inventory, jump” won’t. So it’s probably not too high a cost to mess up chained commands with commas in some cases.

I mean who chains commands with commas anyway.


I assume this ability to chain (some) commands with commas was an effort by Graham Nelson to replicate the behaviour of the Infocom parser in that respect? I wonder if this is an archaism worth the headache of preserving. As Matt asks, does anybody do this? I’ve played text adventures since the 1980s and didn’t know (or had forgotten) it was even a thing.

I guess if you are going to try to replicate the current parser’s interpretation of periods and commas you would need to start by digging into and building a flowchart of the relevant parser logic and entry points… Good Luck!

`With a bit of preliminary digging I have so far come to the following conclusions:
1. The parser starts by substituting 'then' tokens (THEN1__WD) for any periods in the command line and  'comma' tokens (comma_word) for any commas.
2. If it doesn't recognise the first word in a command as a verb:
     2.1.	It looks for some special cases (again, undo, directions- which it reinterprets as 'go direction'
     2.2.	Otherwise, it looks to match [text] comma against a talkable or animate object in scope.
          2.2.1.	If it can do this, it changes the actor to said object and reparses the command, starting from the first word after the comma, as a command (or sequence of commands) to said object.
          2.2.2.	Parsing of this command (or sequence of commands) will succeed or fail according to the usual parsing rules.
          2.2.3.	If parsing of the command (or sequence of commands) fails, the parser reinterprets the entire command line as ‘Answer object [topic]’ topic being all the text after the comma
3. If the first word is recognised as a verb acting on something, the parser interprets further words after a comma as multiple further objects to be acted on by the same verb, as in:
take pot, kettle, skillet
pot: taken
kettle: taken
skillet: taken
    3.1.	If the word(s) after the comma cannot be interpreted as additional object(s) to be successfully acted on, the command is rejected and suitable errors generated. This might be for example ‘You can’t use multiple objects with that verb’ as in ‘examine pot, kettle’ or ‘You can’t see any such thing’ as in ‘drop yeti, sasquatch’
    3.2.	This is why ‘drop pot, go east’ fails with ‘You can’t see any such thing’, as the parser is trying to interpret ‘go east’ as something else to drop.
4. However, should the parser successfully match a grammar line without encountering the possibility of the comma indicating a talkable/animate object to be spoken to or a list of multiple objects to be handled, it treats ‘then words’ (‘then’ or period) and commas the same- as indicating the start of a further command.
4.1.	In practice, on account of its preference for interpreting commas as indicating lists of objects, this only ever happens when the comma follows a verb which acts on nothing (usually a single word command such as ‘e’ or ‘jump’) so only commands of this sort can be chained together with commas
5.	Multiple commands are handled by moving the word parsing marker to the beginning of the command after the demarcating ‘then word’/’comma’, blanking out the command line up to the ‘then word’/’comma’, then re-tokenising the command line (stripping away these leading blanks in the process) and starting the parsing process anew.
1 Like