|Can shift/reduce problems be eliminated? firstname.lastname@example.org (Ashwin) (2002-12-30)|
|Re: Can shift/reduce problems be eliminated? email@example.com (Clint Olsen) (2002-12-31)|
|Re: Can shift/reduce problems be eliminated? firstname.lastname@example.org (2002-12-31)|
|Re: Can shift/reduce problems be eliminated? email@example.com (Carl Cerecke) (2002-12-31)|
|Re: Can shift/reduce problems be eliminated? firstname.lastname@example.org (glen herrmannsfeldt) (2003-01-04)|
|Re: Can shift/reduce problems be eliminated? email@example.com (2003-01-04)|
|Re: Can shift/reduce problems be eliminated? firstname.lastname@example.org (2003-01-04)|
|[2 later articles]|
|Date:||30 Dec 2002 23:55:14 -0500|
|Organization:||Posted via Supernews, http://www.supernews.com|
|Posted-Date:||30 Dec 2002 23:55:14 EST|
I am working on an application that requires parsing C# code using the
standard lex and yacc tools. In my code, I have defined the grammar as per
the ECMA specs for C# language. For what I have implemented so far, parsing
seems to be working the way I expect. However, I do get a few shift/reduce
conflicts during the compilation of grammar. I am wondering if this is a
cause for alarm. Perhaps I have not implemented the grammar properly.
Also, I get quite a few reduce/reduce conflicts. I guess this is
unavoidable. Is there a way to completely eliminate reduce/reduce conflicts
by rearranging the grammar (while adhering to the original specs)?
Thank you in advance for your help.
[Shift/reduce conflicts in expressions usually are just precedence
issues that can be resolved with %left and %right, as are if-then-else
complaints. Anything else usually means your grammar is too ambiguous
for yacc to handle. Reduce/reduce conflicts mean your grammar is
ambiguous and two rules match the same input. Unless you are 110%
sure you know what the ambiguity is and that yacc is resolving it the
way you want, you should rewrite the grammar to get rid of them. As
to whether that's possible, I'd hope that ECMA wrote an unambiguous
spec for C# but I haven't looked at it closely enough to be sure.
Return to the
Search the comp.compilers archives again.