[DGD] Working with parse_string()

[Shentino]

Perhaps this is why one needs prepositions like to and in...

And maybe we need them just as badly in english IRL :)

On Thu, Jul 23, 2009 at 3:38 PM, Kamil N <kamiln at gmail.com> wrote:

> 2009/7/24 Dread Quixadhal <quixadhal at chartermi.net>:
> > Parsing without a way to clearly delimit parts is always going to be a
> bit
> > dicey.
> >
> > Consider:
> > If I remember correctly, parse_string() can return all matches as an
> > array(?)  If so, you could then walk each result to see if it's an actual
> > functional match for the context in which it's being applied.
>
> Yeah, thats another problem :) I started to play with more than one
> parsing trees returned by parse_string, and it seems that with 3-5
> parsing trees allowed it finds the right match among failures. But
> sometimes there is even more ambiguous result. Consider this:
>
> ({ ({ "give", ({ (object) heavy steel axe }), (object) man }),
>     /* case #1 */
>   ({ "give", ({ }), ({ }) }),
>                     /* case #2 */
>   ({ "give", ({ (object)"heavy steel axe" }), (object) tall man })
> })    /* case #3 */
>
> So I got 2 results that are matching all required objects, but there
> is a problem you can already see - one found "man" object, second one
> found proper "tall man". Both are correct, but the one thats is really
> correct is most detailed one, so it creates a problem - how parser /
> code should be able to recognize which one is correct?
>
> I have only one idea at this moment - instead of returning just
> (object), I could return array: ({ object, detail_level }), object
> being of course the object that was found, and detail level could be
> just simple integer telling the parser how many details were involved
> in finding this object - in case #1 it would be 1 (just noun), in case
> #3 it would be 3 (adjective noun). Then I could sort them by
> detail_level and decide to take one with highest detail used to find
> it. Can't see at this moment how this solution would work in reality,
> gonna check it soon. Whole code to process such multiple results from
> parse_string will be tricky if its supposed to work for all verbs and
> possible sentences.
>
> KN
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>