|Help with Yacc reduce/reduce conflict email@example.com (Warren) (2010-06-21)|
|Re: Help with Yacc reduce/reduce conflict firstname.lastname@example.org (glen herrmannsfeldt) (2010-06-23)|
|Re: Help with Yacc reduce/reduce conflict email@example.com (russell kym horsell) (2010-06-24)|
|Re: Help with Yacc reduce/reduce conflict firstname.lastname@example.org (Paul Mann) (2010-07-01)|
|From:||russell kym horsell <email@example.com>|
|Date:||Thu, 24 Jun 2010 05:13:56 +0000 (UTC)|
|Posted-Date:||25 Jun 2010 16:25:56 EDT|
Warren <firstname.lastname@example.org> wrote:
> I'm writing a tool for novice Java students to submit their programs
> on-line and get back warnings about common mistakes, e.g. if (x = y),
> and assignments where the == operator is used instead of =.
> I've started with the Yacc-based Java grammar at
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y and pruned
> it down to this: http://minnie.tuhs.org/Z/java.y
> I'm modifying the grammar to accept illegal Java constructs, so that
> they can be identified as mistakes. Right now I am trying to add the
> '==' operator to assignments, but I am getting 4 reduce/reduce
> conflicts. The specific added rule causing the problem is:
> left_hand_side assignment_operator assignment_expression
> | left_hand_side '==' assignment_expression /* This one!*/
> | left_hand_side assignment_operator error
So you've made an expression and an assignment look the same and still
want to tell the diff between them? :)
This may not be too difficult to fix if you can arrange to get some
comms going back and forth between the lexer and parser. E.g.
signal lexer in some contexts you don't want '==' (that would indicate
to parser we are inside an expression) but to turn '==' into some
completely new symbol for the parser's benefit.
Ugly? You bet. This is yacc & lex.
Return to the
Search the comp.compilers archives again.