23 Feb, 2010, donky wrote in the 1st comment:
Votes: 0
My current project is to add a simple room-based model to my codebase and one part of this is writing a parser. I thought what I might do, was describe what I have already done, and hopefully others might have suggestions or thoughts.

I define a command like so:

class Take(GameCommand):
def syntax_SUBJECT(self, info, matches):
for ob in matches:
if ob.container is info.room:
ob.MoveTo(info.body)
info.user.Tell("Done.")
break

class Look(GameCommand):
def syntax_(self, info):
info.user.Tell(info.room.LookString(info.body))

class Say(GameCommand):
def syntax_STRING(self, info, string):
for ob in info.room.contents:
if isinstance(ob, Body):
if ob is info.body:
ob.user.Tell("You say: %s." % string)
else:
ob.user.Tell("%s says: %s." % (body.shortDescription.capitalize(), string)
Here are the commands in use to give you an idea of how the parser behaves.

> l
Room description.
You see: brown pants and yourself.
> take
Usage: take <subject>
> take red pants
You cannot find any red pants.
> take pants
Done.
> say
Usage: say <string>
> say test
You say: test.
What the parser does is:
  • Detects valid syntax for a given command based on the defined method names on the command.
  • If the given arguments do not match any of the syntaxes handled, it generates a usage string.
  • Matches against objects in the room or that the actor is carrying.

  • While it has been probably eight years since I read about it, it is inspired in terms of the function naming by the MudOS parser. I am avoiding rereading about the MudOS parser, in order to just see where my own efforts take me.

    For now, it just handles the no argument and one argument cases, as that is my current milestone. Once prepositions factor in with the usage an object and a subject, I will be able to infer the locations that should be looked in for matches. One problem with the one argument case, is that while a command may know what location its matches should come from, it is not possible to assert this in the function name and therefore the parser just matches all objects of the given description in any of the default locations.
    23 Feb, 2010, David Haley wrote in the 2nd comment:
    Votes: 0
    donky said:
    One problem with the one argument case, is that while a command may know what location its matches should come from, it is not possible to assert this in the function name and therefore the parser just matches all objects of the given description in any of the default locations.

    I'm not sure if this was a question, but this doesn't sound too hard to fix. You would need to define a scope for each syntax's components.

    By the way, personally I would not do introspection on method names, but have an explicit mapping from syntax to function to handle that syntax, and any other information you might need such as the scope in which to look up items. If you started encoding this in function names, things would get kind of silly pretty quickly.


    By the way, the Python syntax coloring looks like rainbow unicorn spew, with some things having different colors for no apparent reason. :sad:
    23 Feb, 2010, donky wrote in the 3rd comment:
    Votes: 0
    David Haley said:
    I'm not sure if this was a question, but this doesn't sound too hard to fix. You would need to define a scope for each syntax's components.

    By the way, personally I would not do introspection on method names, but have an explicit mapping from syntax to function to handle that syntax, and any other information you might need such as the scope in which to look up items. If you started encoding this in function names, things would get kind of silly pretty quickly.

    In the past, I would have agreed, but in practice this has worked out well. The coupling of function naming to the syntax handled by the function is less cumbersome and more readable than an explicit mapping. I am certain that any additional scoping information required can easily be encoded long before things get silly.
    Random Picks
    0.0/3