[MUD-Dev] string parsing

[Felix A. Croes]

cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray) wrote:
> [Felix C:]
>
> :What follows is a description of something I am currently implementing
> :for my server.  I am providing it here for others to comment on.  Also,
> :I'd like to hear of other approaches to the same problem.
>
> In general, I think such a facility is a very good idea. That's why I have
> one in my system! I've found it to be useful in a couple of places, such
> as "sublanguages" for my online building commands, etc.
>
> One of my main concerns, however, is efficiency. LPC isn't as fast as
> native code for string handling, so anything you do on a per-character
> basis is going to be expensive. In my system, I did a number of builtin
> (native) functions to perform most of the core of the work. You can
> probably do that too.

I am writing the entire function as a server builtin, using lazy DFA
construction, lazy DPDA construction, with the appropriate amount of
caching between calls, etc.


>[...]
> Some other issues I've bumped into relating to this kind of parsing:
>[...]
> - the resolution of a noun-phrase string to a MUD-world object can be
>     context dependent on the verb in the command. E.g. 'pick up the rock'
>     can resolve to a different rock than 'take the rock from the sack'.
>     I handle this by not doing the resolution until I am inside the code
>     for the specific verb. Perhaps you could pass the verb to your
>     'find_obj' and 'find_liv' routines, but that doesn't result in very
>     modular verbs.

In this case, `find_obj' should not just deal with "the rock", but with
"the rock from the sack" as a single object.  I.e. it's a matter of
adjusting the grammar.


> My current system is less like your proposal than an earlier one I did.
> I don't quite remember why I changed! I do recall, however, that I ended
> up with a *lot* of rules in the grammar, to handle the various ways that
> the player could give a command. I didn't do the lexical stuff, just the
> syntactic level. The lexical stuff was hard-coded.

Even if you don't remember <why> you changed, do you remember <what> you
changed? :)


> In your last "give sword to dwarf" example, what would parse_string return
> if find_obj couldn't find a sword? An array containing the words of the
> noun-phrase, so that higher-level code could properly complain about not
> being able to find a sword?

My example does not really deal with this possibility at all.  It could
be extended in several ways:
- the function could return such an array, if the object was not found.
- the function could return 0 indicating that this parsing is invalid;
  this could be combined with an additional grammar rule that functions
  as a catch-all for errors in the input.
- assuming that the grammar is unambiguous, the function could deliver
  feedback to the user at parsing time.

Felix Croes