[DGD] Working with parse_string()

[Kamil N]

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