Re: [MUD-Dev] string parsing

["Felix A. Croes" <felix#xs1,simplex.nl>]

cg#ami-cg,GraySage.Edmonton.AB.CA (Chris Gray) wrote:
> [Felix C:]
>
> :    object find_obj_in_obj(mixed *parsetree)
> :    {
> :	/*
> :	 * parsetree = ({ obj1name, preposition, obj2name })
> :	 *
> :	 * find obj1 in obj2 (the code below has been simplified)
> :	 */
> :	return present(parsetree[0], present(parsetree[2]));
> :    }
> :
> :Not actually very hackish, is it?  Finding an object in another object
> :is a fairly common operation.
>
> Well, are you going to have find_obj_on_obj, find_obj_beside_obj,
> find_obj_under_obj, etc.?

If the mud has such object relations as `next to', `on top of' etc,
then it makes sense to have syntax rules, and functions to give them
meaning, for all of them.


> Wouldn't you also want 'present' to be able
> to properly parse a noun phrase? That's where I was thinking you might
> end up recursively calling parse_string. Nothing really bad here, I
> guess - there probably aren't any truly tidy alternatives that work better.

I made nouns single words to keep the example simple, but that can be
changed (replacing Noun with NounPhrase):

    NounPhrase: ( OptArticle ) ( Adjectives ) word
    OptArticle: 'the'
    OptArticle: 'a'
    OptArticle: 'an'
    OptArticle:
    Adjectives: word Adjectives
    Adjectives:

In this case, the parse tree in the above function would be

    ({
      ({ optart }), ({ adjectives }), word,
      preposition,
      ({ optart }), ({ adjectives }), word
    })

All the parsing for present() would already be done, and there is no
need for recursively calling the parser.

Felix Croes