Progress of the Parser

Well, to be honest this is the easy part in my humble opinion. It’s just that it requires time and effort.

It’s literally a case of working through each action that you’ve programmed, adding synonyms to the command syntax code or if required creating new V-XXXX syntax strings.

I’m referring to ZIL now, I’m assuming it’s similar in Inform.

I’m terms of coding, dead easy. In terms of time and completeness, quite demanding.


Now what I want to get to is …

pick up the <small | tiny | puny | miniature | quite big | great big | etc… > statue


@JoshGrams @Greyelf

Actually I’m up for a bit of a challenge here! Give me some examples and/or scenarios that you think pose problems and I’ll try to code up the solution in ZIL?

Adam :grin:

1 Like

Sounds a bit like the Inform 7 language, actually, or maybe that old Stephen King story “Word Processor of the Gods”. It wouldn’t surprise me one bit if you were to announce that you were working on a game where this was the central mechanic. :slight_smile:

After the Infocom source code was made public, I started working my way through the games, checking for bugs etc. I’m still in the first third of them, but you can tell that they were experimenting with what the parser should respond to as well. Some games respond to the question “IS object IN object”, some treat “GIVE ME THE object” as another way of saying “TAKE object”, etc.

Of course, that’s more a matter of vocabulary than parsing.

1 Like

Yes, and to me it’s the time and completeness that are important here. What can the tools do to help? What if your development environment included a thesaurus with grammatical info about how the words are used, and could suggest alternate constructions, or even just build them automatically and show you the code for your approval or rejection? That sort of thing.

A bunch of things that I dislike about current parsers seem to be a direct consequence of the archaic VM technology used to run them. Like the whole thing about words or names being these immutable tokens that have no internal structure and maybe only even represent the first X characters of a word. I feel like we see a fair amount of problems like this Dialog thread. If you look for questions about trying to make dynamically-named objects in Inform I think you’ll find more similar problems.

You could do other interesting things if you removed that limitation, like letting users rename things. It’s very easy for authors to make things that are extremely hard to type. What if every game let the player work around that?

Other Inform limitations that seem crazy to me (even though as a programmer I can certainly understand how they might have come to be): I believe you can’t have an object that is both a container and a supporter. And you can’t do multiple identical items at all? And support for doing things with multiple items seems patchy and ad hoc? You can generally take all, but doing other things with multiple objects seems to work or not work based on whether the author decided to support it, rather than being built into the engine.

If you have the time to spare, I’d recommend trying out the Discworld MUD for an hour or two. It was started around the same time as Inform (I think it opened to the public in 1992?), but comes from a different background: constantly being worked on by a substantial group of people while other people are playing it. And they have a very serious system for getting new authors up to speed, and rules for how to make good content, and such. It’s far more dense than any other MUD I’ve ever seen. To me it makes most of them look like sparse half-finished prototypes. It’s more CRPG than IF, but also has lots of one-off set-piece puzzles (though many of them do use the stat system as well as just being puzzles) and hand-written interactions.

It has an alias system which allows you to not only rename objects but is essentially a tiny scripting language. It handles disambiguation and duplicate objects extremely well (there are maybe twelve different currencies in the game, and you can say things like “get Ankh coins from satchel” or “give three rhinu to Fred” or “sell 7 torches”). It does containers and liquids fairly well. And there are a whole bunch of different in-world languages which your character has to learn by practicing, which is super grindy but also hilarious.

I dunno. I think the differences are interesting and instructive. And the game is fun too, if you’re into that sort of thing. It gets grindy pretty quickly, but there’s probably a good 10 hours worth of walking around looking at and talking to and just messing with the world, even if you mostly ignore the RPG bits.

Inform has always supported multiple identical items and commands like TAKE FIVE GOLD COINS. (For small multiples – you don’t want to model 69105 leaves this way.)

You are correct about the other limitations. I could fuss about details but it’s a serious tangent. :)

Those are both very tricky roads from the view of playability, of course. No input is verbatim once real players show up.

My experience with keyword matching is that it’s only sufficient for recognizing simple noun phrases. (If you had a game where you entered “LAMP”, “ELVISH SWORD”, … then keyword matching would work well.)

Once you get into nouns and verbs, like the classic PLANT POT PLANT IN POT, you need to deal with structure or you’re going to be forever confusing nouns for verbs for adjectives. Or imagine dealing with TAKE GOLD COIN AND SILVER KEY, for example, in a room where there’s also a silver coin and a gold key.

I suggested the syntax parsing would be good for throwing out extraneous phrases: I REALLY WANT TO READ THE BOOK. IT IS TIME TO KILL THE TROLL. The Google service I mentioned can handle this. But if you try to deal with it at a keyword level, you’re going to match the player (“I”) or the last-mentioned object (“IT”) or whatever object might match “TIME”.


I find this fascinating! Love working through stuff like this.

You ultimately go round in full circles because eventually you end up saying “let’s just fix the fixable problem” and summise that a simple 2-4 word system is best; going any further than that is to wind up leaving the text adventure reservation and heading off into AI country!


1 Like

To @zarf’s point, the above represents a challenge that you can well imagine McCarthy and Minsky tackling back in the heady days of 1960s AI!


1 Like

I’ve also wished before that Inform would use a more modern parsing algorithm, which would let it deal with “fake ambiguity”: if the player is carrying a “letter to Ethan”, and tries to “GIVE LETTER TO ETHAN”, the only sensible parse is “give (letter) to (Ethan)”. But Inform will instead come up with the parse “give (letter to Ethan)”, see that there aren’t enough words left to match “give [NP] to [NP]”, and complain.

1 Like

Don’t forget the “pick the ___ statute up” phrasing.

The feature you want here is to maintain a list of possible parses, explore all possibilities, and then pick the best. (In this case, a complete grammar-line match would score higher than a partial match.)

Inform does this in a limited way – when disambiguating noun phrases. It can’t do it for the complete grammar line. This is a straight-up example of “it wasn’t practical on the Z-machine and it never got added.” (In a modern language, with hash tables and arrays trivially available, it’s a lot easier.)


Oof. You might want to fix that quote. That was @zarf correcting me (thanks!): Inform does and apparently always has done duplicates. The manual says “there are four caveats” (and it’s not a feature that I’ve seen used much) so I was probably misremembering from that, but they all are perfectly sensible caveats and don’t look like they’d get in your way much.

1 Like

The ISHML parser is designed to do this.

IMO, the potential for fancy AI/ML parsers isn’t so much to actually support a broader range of typed commands, but to generate better error messages and hints, guiding players to type what they’re “supposed” to type instead of trying to translate arbitrary input into valid game commands.


Agreed. Smarter Parser by Aaron Reed has has problems in its current incarnation, but it’s got the right idea: take every command that was rejected by the standard parser, analyse it and try to work out what is wrong with it, and then print a suitable helpful message (and if possible extract a valid game command to send back to the parser.) Throw Google Natural Language API or similar in there and write ten times the number of help messages to cover every common kind of mistake, and we might be getting somewhere.


I don’t know what’s so impractical about it. Dialog does exactly that, for full phrases, on the Z-machine.

Of course: “If I have hacked deeper than them, it is because I stand in their trenches.” (Graham Nelson)

Two cute examples from the Dialog manual: “READ TO KILL A MOCKINGBIRD TO MOCKINGBIRD” and “GIVE ATTILA THE HUN A COOKIE”.


It’s sad to me that Smarter Parser didn’t kick off a movement, that it didn’t become part of the standard toolbox for Inform games.

But, in hindsight, I don’t see how it could have. New authors probably aren’t going to know about Smarter Parser, and aren’t going to reach for it even if they do know about it, and experienced IF players have no need to demand it. Worse, if you’re the sort of author who likes customizing all of the standard error messages, Smarter Parser just makes your life harder.

I think it would have required Inform to make Smarter Parser somehow part of the standard default for new Inform games, but a big messy complicated extension like that isn’t a natural fit for the standard library.

As a result, it’s hard to see a path toward big improvements in Inform’s default error messages, which, I claim, are a significant source of friction for newbies. :slightly_frowning_face:


I like this. Good approach.


I don’t want to pick on Smarter Parser here, because I think it is very useful, but its fundamental problem is that it makes heavy use of the slow regular expression implementation of Inform 7. Also, when it kicks in, the Inform parser has already spent a lot of time trying to make sense of the player’s command, which makes the total pause more noticeable.

It also uses keyword matching rather than syntactic analysis, and if it didn’t it would be even slower. TAEK THE SCREW and SCREW THIS! are both understood as the player swearing in frustration, because they include the word SCREW.

What we would need is something that is super fast, accurate and included in every new game by default, and at the same time is easy for the player to switch off.