[DGD] Working with parse_string()

[Kamil N]

2009/7/22 Felix A. Croes <felix at dworkin.nl>:
> Unfortunately that isn't possible, especially with ambiguous grammars.
> The parser is evaluating many parse trees in parallel and may
> simultaneously be at the bottom of one, and in the middle of another.
> It doesn't have any notion of up or down until parsing is completed.

Hm, and I suppose its impossible to somehow "skip" left->right order
of parsing rules and check another RULE at the same time? This could
greatly improve search quality for ambiguous grammar.

For example having rule "OBJI, OBJI LIV" and parsing string "give
sharp sword, nonexistant object tall sneaky man" is impossible to
parse correctly.

"sharp sword" parses fine and it finds proper object
"nonexistant object tall sneaky man" fails because it reserves way too
many tokens for OBJI without really caring about LIV. In this example
and unlimited number of adjectives it will start looking for object
with all the tokens available except for minimal requirement for LIV
(which will be "man"), and it will fail miserably. If at the same time
it could try to match LIV with ({ tall, sneaky, man }) it could be a
successful and then it will be left with ({ nonexistant, object })
tokens, I could return ({ }) and whole thing would parse to

give ({ OBJ(sword), nil }) OBJ(man) })

allowing whole command to execute but skip wrong input. Is there any
way to deal with it in parse_string or I just have to accept its
limitations and try to narrow my requirements / find different
solution not involving parsing? Sometimes it even parses but for
example it gives LIV rule way too few tokens (for example "man"
instead of "evil man") and it finds an object but possibly the wrong
one, just because previous rule "stole" tokens from rules that follow
:(

So I'm basically asking if there is any way to limit "greediness" of
parser when it tries to resolve one rule, but eats so much that
following rule that would be easy to resolve cannot be, because of
lack of tokens.

If this cannot be somehow resolved, I guess I will just stick with
general error "Give what whom?", no "fallbacks" etc. because it was
impossible to come up with 100% reliable solution (I tried many
different approaches to parsing, and whenever I solved one issue I
created another, which made it just shuffling from one error situation
to another..)

KN