[DGD] Working with parse_string()

Shentino shentino at gmail.com
Mon Jul 20 01:06:04 CEST 2009


My gosh, I had a nightmare that I was in college again, but had classes 50
minutes long with 10 minute interlude.

I failed english because I got lost on the first day, and the homework piled
up so much I never caught up.

Oddly though, I never did find the math department either.

Relevance to list?

Dealing with the english language is my least favorite part of parsing.

On Sun, Jul 19, 2009 at 3:46 PM, Felix A. Croes <felix at dworkin.nl> wrote:

> Kamil N <kamiln at gmail.com> wrote:
>
> First off, let me say that we don't often see parse_string questions
> on this list as interesting as yours.
>
>
> >[...]
> > I don't really know if such thing is possible, but that would allow
> > parsing to be more "stateful" because right now all LPC functions that
> > are called don't know anything except for array of tokens that have
> > been parsed. Other workaround (simpler and not requiring any
> > modifications) would be just putting alot more grammar, and using rule
> > names as indication which case should be used to find objects:
> >
> > VERB: give OBJI_ACC LIV_DAT
> >
> > OBJI_ACC: OBJ         ? find_object_in_inventory_accusative
> > OBJI_DAT: OBJ         ? find_object_in_inventory_dative
> > [ and so on for all cases ]
> >
> > LIV_ACC: OBJ           ? find_living_accusative
> > LIV_DAT: OBJ           ? find_living_dative
> > [ and so on for all cases ]
>
> That's the easiest way to do it.  But you don't need <all> 7 cases for
> each object class, do you?
>
> To simplify the functions, just let find_living_dative() call
> find_living(obj, "dative").
>
> It's also possible to use fewer functions, at the cost of some extra
> complexity in the grammar, with empty rules:
>
>    LIV_DAT: OBJ DATIVE         ? find_living
>    DATIVE:                     ? dative
>
>    string *dative() { return ({ "dative" }); }
>
>
> >[...]
> > I know main problem here is lack of any separator that would make
> > whole thing less ambigous, but its just not possible with this
> > language, so all I can do is finding exact objects if parser allows
> > some "trial and error" methodology. And it does if I return nil, but
> > then I run into this problem with parser failing all over if parser
> > can't find any object matching one of required arguments. I know it
> > may be not even a parser problem, because its probably not supposed to
> > work in such trial mode, but if its allowed, is there any chance to
> > have some way to force it to try few rules but if it goes down to one
> > word and still can't find anything it should just make it empty array,
> > not discard whole parsing. The only way to parse something so crazy
> > like OBJI LIV being next to each other is just trial&error while
> > trying to resolve object on the fly while parsing. It would be
> > impossible without trying to find objects while parsing, because there
> > can be way too many combinations of adjectives & nouns and parser will
> > never be able to distinct them.
>
> It seems to me that this becomes much simpler once you've solved the
> first problem, assuming that noun cases like accusative and dative
> can always be unambiguously determined, because then you'd have a
> lot more certainty about which word belongs to which part?  The
> problem is a lot harder in "English without separators" than "Polish
> with proper noun cases."
>
> Regards,
> Felix Croes
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list