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

[Chris Gray]

: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.

Well, mine is. It was one of the first things that I needed. In the
mail room, there are added commands which are used to send email to people
outside the MUD and read your email. In the newsroom there are added
commands which allow you to read and post news on the local machine,
which, if the machine has a regular newsfeed like mine, will actually
go out over the internet. I *didn't* want such commands available
everywhere on the MUD! If I remember, I'll send some email out from there
the next time I have it up for that kind of testing (I'm doing client
fiddling at the moment).

[I won't quote much of Carter's material, but will just make a rambling
reply.]

Another example is the way my online building commands work. The system
has a verb-type called "VerbTail", where everything in the command after
the verb is just passed to the verb as a string. I use that with verb
@/build/construct/b, so that that command can then parse the remaining
input according to another, completely different, grammar. In fact, if
the first word of *that* tail is object/o or room/r, then yet more grammars
are invoked on further tails. So:

    build room new north indoors in the Solarium

invokes the 'build' verb. It sees the rest of the input and passes it to
the build grammar. The verb is then 'room'. It takes the rest of the input
and passes it to the room-building grammar. The room building grammar has
a verb 'new' which requires a direction, a room-type and a room-name, all
of which are handled as "rest-of-input" processing. It's kinda tough to
do this with yacc! (Well, maybe not, but doing it this way keeps all
mention of the verbs/etc. for building out of the main grammar - modularity
in all things!)

How about simple things like "whisper" or "say"? Sure, we all have " or
something as a special-cased shortcut for "say", but what about whisper,
where you are whispering *to* someone in particular:

    whisper to Fred Let's attack Sam!

Doesn't fit in a yacc grammar very well.

I also have a 'with' verb, although I don't currently have any real uses
for it in the current scenario. It takes an object, identifies it in your
inventory/location, and then looks for a grammar attached to that object
to parse the rest of the input with. I intend it for powerful magical
objects, eg: "with staff zap the frog".

Right now, I have a 'cast' verb for wizards. It takes the next word in
the input, and looks it up as a procedure in the player's "spell table",
which is just another table of whatever's that can be attached to the
player or other things. If it finds a procedure by that name, it invokes
it, and that procedure has access to the rest of the input command. So,
I can do "cast heal Fred", or "cast teleport Fred here", etc. Sure, you
can put this in some main, overall grammar, but with this technique,
wizards, who can write new code in the running system, can easily add
new spell commands to their own spell tables.

: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)

Well, in my 'build' example above, if you enter "build twiddle", the build
command can't find the verb 'twiddle' in the build grammar, so it reports
"Unknown build command 'twiddle'." Similar for "build room twiddle".

: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 :)

Well, my grammars are already database objects that I can retrieve from
wherever I want. I currently don't do what you are saying (other than the
bit mentioned above), however.

Another issue: do you even want to lexically scan all input the same? By
making it context sensitive, you have some greater flexibility.

I guess my viewpoint on this is a little different than most. I've written,
er, six compilers, and never once used either lex or yacc, or any other
compiler tools! I think I did the lexer/parser for my AmigaMUD in-MUD
language in about a week. It has a pretty standard Algol-68 style syntax,
with 'if', 'while', 'for', 'case', full functions, some special MUD
operators, etc.


Ack! Enough blithering - sorry - I do run on at times.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA