[MUD-Dev] string parsing

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

"Felix A. Croes" <felix at xs1.simplex.nl> wrote:
>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.

Hi Felix, I salute your effort in trying to introduce more intelligent
grammarbased parsing to LPC. (hopefully you take advantage of the
freely available libraries for regexp's etc)

I am currently sketching ways of using grammars for *generating*
output, as opposed to the more traditional parsing of input. Have you
considered to include this in your work?  As you are working with a
textbased system I think this could be useful for programming NPC
behaviour or at the very least to aid the simulation meaningful
talking.

>    Thing: Noun
>    Thing: ( Adjs ) Noun
>    Noun: word
>    Adjs: word Adjs
>    Adjs: word
>
>parse_string(grammar, "bottle") will return
>
>    ({ "bottle" }),

Uhm, shouldn't it return that "bottle" is a *Thing* ?  Isn't that the point
with parsing? Sortof?  I guess I missed you somewhere...


>breadth-first LR(k) parsing algorithm.  Next, any LPC functions specified
>for rules are called (bottom-up), and the intermediate parse trees for
>those rules are replaced by the return values of those functions.  As
>a special case, if the LPC function returns zero, the entire parse tree
>that this intermediate parse tree is part of is discarded.  Finally,
>the resulting parse tree(s) are returned.

So your functioncalls are a mixture of a "generating rule" and a
"production rule"?  Won't you "loose" some information in the process
in the case of user errors, or is that the responsibility of the
function being called?  I'm probably misinterpreting you, parserdesign
is not my primary interst although I have some interests in the field.

I suppose you could do the following if your functioncalls accept
"empty" as input. I am thinking along the lines of doing matching
against the results of NPC functioncalls, making programming of
default values easier.  I think you would make the parser a lot more
powerful by adding some kind of context sensitivity .  (I have not
checked to see if the grammar is correct (probably needs some
rewriting or additions) or parsable and think more of usage than
implementation :-)

KILLACTION = 'kill' KILLOBJECT KILLWEAPON
KILLOBJECT = &assert_killable(&find_closest_object(OBJECT))   //1. pri
KILLOBJECT = &assert_killable(&find_reachable_object(OBJECT)) // 2nd
KILLOBJECT = &assert(&find_any_killable_in_room())   
KILLOBJECT = &raise_no_killable_exception(OBJECT)
KILLOBJECT = &raise_no_killable_in_room_exception()
KILLWEAPON = 'with' WEAPON
KILLWEAPON = &assert(&find_weapon($player)) //assert flags empty as nonmatch
KILLWEAPON = &raise_no_weapon_exception(ANYTHING)

Or even

DOACTION = 'do something with' OBJECT
OBJECT = KILLOBJECT
OBJECT = KISSOBJECT
OBJECT = OTHEROBJECT
KILLOBJECT = &assert_killable(&find_object(OBJECT))      // 1st priority
KISSOBJECT = &assert_is_pretty_girl(&find_living(PERSON))// 2nd

The input 'do something with Lisa' would then yield:
({ 'DOACTION', ({ 'KISSOBJECT', OBJ('Lisa') }) })

Then apply some rewriterules and hopefully you'll end up with
({ 'KISS', ({ KISSOBJECT, OBJ('Lisa') }) })

or maybe
({ 'KISS', OBJ('Lisa') })

of course, on a playerkiller Mud Lisa would become a KILLOBJECT :-)
Therefore the priority of productions should be probably be context
sensitive in a globale sense (kill if unhappy, kiss if happy ;-) and
put on a separate layer. Maybe one should add stuff for measuring
distance between two valid interpretation.  What I mean by this is to
add some functionality that would flag the difference between KISS and
KILL as unacceptable but the difference between HUG and KISS as
acceptable..

I guess the rewrite stuff could be included in the parserlanguage
design... The assert_* functions are additional context rules, should
probably have a different syntax. The raise_ functions should probably
be related to the failed asserts on a separate layer... Ugh...
	
>the player should probably be notified about the ambiguity.

Or even better, but much more advanced, give the user feedback of the
parsing during entering of input:

types:  kill<tab>
output: 'kill' (myself|green troll|blue troll) with (fist|knife|hammer)

types:  kill gre<tab>
output: 'kill green troll with' (fist|knife|hammer)

etc.  

By adding contextsensitivity it should also be able to narrow down the
choices of weapons by considering the monster at hand.

Please read this message as a 'what if...' or 'maybe you could...'
reply.  Don't tell me you can't implement this, I' not going to help
you (heeh), but I'm sure somebody on this list has done something
similar.  Besides you didn't ask for _useful_ comments :^)

Ola.