 |
Forums |
Admin Discussion Forums: help Start New Thread
By: Mushfeq Khan
 RE: Resolving conflicts [ reply ]
2007-06-10 01:55
|
Arthur,
I'm sorry to hear that you're experiencing so many reduce-reduce conflicts, because the library is a little opinionated in this regard - reduce-reduce conflicts are evil, and the handling is actually not well-defined. The engine pretty much chooses a random rule to reduce with. I've got a task on my TODO-list for making this deterministic by choosing the reduction that appears first in the grammar spec (this is how Yacc handles it) and I will try to roll this out in the next release.
As far as this example goes, the parser has in fact seen a set of tokens corresponding to a 'simple_id' since the last reduce. It's just that one of the reductions reduces 'less' than the other one. Again, there's no heuristic right now for resolving these conflicts.
As you probably already know, Dhaka already does peek ahead exactly 1 token (this is the 1 in LALR1). The ability to do this is very much built into the kind of generator that Dhaka is. Changing this in any way that's not horrendously messy would involve changing the algorithm.
I can, however, implement the kind of summary that you wish to see in the output from generating the parser. Thanks for the suggestion!
Sincerely,
Mushfeq.
|
By: Arthur Griesser
RE: Resolving conflicts [ reply ]
2007-06-09 23:49
|
One last thing:
It would be easier to deal with conflicts if there was a single error message for each state (combining all the lookaheads). A count of states with conflicts would be nice as well.
Art
|
By: Arthur Griesser
Resolving conflicts [ reply ]
2007-06-09 22:48
|
Hello,
I find that I need to work with a complicated legacy grammar that results in lots of conflict warnings. I have eliminated thousands of them by modifying the grammar in ways that don't really affect what I am doing, but it's getting discouraging because the fixes tend to lead to other, different conflicts.
Other people who work with this messy language seem to rely on extra code associated with individual problematic productions: it peeks further ahead in the token stream to resolve ambiguites. Would it be feasable to add some such features to Dhaka?
Another question on the same topic: I fail to understand the following conflict. I expected reduce-reduce conflicts to occur only when the state contained identical completely-seen items. Shouldn't the parser be able to distinguish these?
ERROR -- : Parser Conflict at State:
entity_constructor ::= simple_id ( expression ) ->
actual_parameter_list ::= ( expression ) ->
Existing: Reduce with entity_constructor_0_1 entity_constructor ::= simple_id ( expression )
New: Reduce with actual_parameter_list_0_1 actual_parameter_list ::= ( expression )
Lookahead: <
Thank you,
Art
|
|
|
