[DGD] Working with parse_string()

[Shentino]

More to the point however, I have often seen prepositions used to delimit
subjects objects and all sorts of things like that.

I have also never seen a noun or adjective that was also a preposition.

Should we discuss how prepositions fit into this problem?  I would be
interested in hearing what other folks have to say about it.

On Thu, Jul 23, 2009 at 5:35 PM, Shentino <shentino at gmail.com> wrote:

> 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
>>
>
>