mud grammar (was Re: Just a bit of musing)

[Carter T Shock]

> From: coder at ibm.net
> A good MUD grammar is incredibly context sensitive.  A simple example is
> the case where the presence or proximity of an object adds verbs to the
> players.  There is no need for this crap to wander thru the global
> namespace, or even warp the general grammar.
> 
> >As such, one should be able to whip up a command interpreter with
> >lex/yacc. I've started on it at least a dozen times but never managed to
> >quite finish. Is this worthwhile? Thoughts?
> 
> Nope.  That approach tends to preclude having a dynamic language where
> users or objects can add, redefine, mutate or delete verbs and nouns
> freely at runtime.  A Very Bad Idea.
> 

I think we have a misunderstanding here. There's grammar (the structure of
a language) and then there's vocabulary (all of the individual words that
make up the language). I agree that the vocabulary is dynamic. I don't
think the grammar is.
I'll go one step more and suggest that how you implement the various
entities (people, critters, and objects) in your mud can influence the
success of such an approach. 

Lessee... in most mud worlds, the "nouns" are dynamic, but the verbs are
not. I put nouns in quotes because often a noun/adjective pairing is
required to uniquely identify an object (the long sword, the black sword,
etc.). The verbs in the system are your commands. cast, throw, hit, etc. If
we want to allow dynamic or generic verbs, now you're getting into natural
language processing and I definitely don't want to go there. So there are
some distinct sentence structures that emerge:

<verb> <object>  "hit foo"
<verb> <object> <object> "give gold foo" "cast fireball foo"

So the first trick is to define your grammar... establish a mapping of
verbs to appropriate objects. We'll start with "hit". In most codes if you
"hit foo" the code first sees what the allowable targets are for foo, then
tries to locate a foo somewhere in the world that satisfies the target
rules (get_person_room_vis(), get_obj_room_vis() whatever). The basic flow
doesn't change a whole lot. We still have classes of objects... people,
things, places, etc. One solution is to write our lexical analyzer so it
enforces target rules. Another is to write objects so they can respond to
any command (I've done sort of a mix here. Done in C++, the base generic
object has a handler for all available commands, all of which respond "You
can't do that" or somesuch. Real objects are derived from the base. For
commands that make sense on the derived object, overload the virtual
default handler, multiple levels of inheritence work nicely here).

An example of where this works very nicely is with magic. Identify the verb
"cast" as special in your lexical analyzer. Rather than
<verb> <object> <object>
it becomes
<verb> <spell> <object>

Now the question, why bother?
Well, first off, it can make the mud more user-friendly. Rather than simply
reporting "huh?" on bad commands, a true parser should be able to:
	1) report the exact location of the error in the command
	2) offer up suggestions (tab completion of commands)
Now, we could do all of this without learning lex/yacc, but doing it in
lex/yacc gives you a standard interface.. not to mention someone else has
written most of the ugly code for you already. Btw, the newer flavors of
the GNU lexer/parser software (glex and bison I think) offer up a C++
version that encapsulates the parser as an object. Nifty side effect is
that you can have more than one. So, if you really want to screw with the
user's minds you could conceivably have different command sets in different
parts of your world. (something along Zelazny's Amber... the physics are
different in the place you've warped to so the commands, spells, etc are
different). Wait, it gets better... if we want to link up muds, there are
ways that one mud could export its parser object to another so, if you
wanted, you could process commands for a user in the remote mud locally
(not sure why you'd want to, but hey.... explore the possibiliteis :)