At the moment, generate_parse_tree is returning a parse tree if it matches a valid command, or None if not. One way of getting more informative error messages (a la Zork) could be to make some new language rules which allow for common compositions of invalid text inputs. generate_parse_tree, then, would just return the parse-tree for the error message. For instance, we could match this rule:

directed_prep_verb (preposition)?

and handle the parse tree by generating a readable message for the user:

"{directed_prep_verb} {preposition} what?".format(verb, prep)


look at what?

Some default Parsimonious behaviour will probably come in handy here: if we use a rule that looks like (preposition)? to match 0 or 1 prepositions, it will create a preposition node in the parse tree, which may contain either a preposition or the empty string. When printing the message above, this means that we won't have to test whether preposition matched - all we'll be doing is iterating through the nodes, and printing the empty string is hardly a harmful side effect.

One thing to think about is how easy it'll be for IF programmers to actually add their own verbs. At the least, they'll have to add the verb to one dictionary of verb types, read by generate_parse_tree or something similar; then, create a new hook in; then write their own callback for when handle_interaction gets called with that hook. I still haven't worked out how to actually translate from verb to hook (the '' file just hardcodes it, which definitely isn't the solution I'm after). One possible solution is to have a hooks object based on a dictionary mapping hook names (in caps) to hook values (numbers, just like an Enum). It probably wouldn't even need to override __getitem__ if it inherited from dict (in Python 2.x it'd be BaseDict, but to the best of my knowledge that's been removed - or at least moved into a module somewhere in the standard library).