|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:||Paul Mann <email@example.com>|
|Date:||Thu, 1 Jul 2010 17:51:26 -0700 (PDT)|
|Posted-Date:||01 Jul 2010 23:37:38 EDT|
I found this in your yacc grammar:
: left_hand_side assignment_operator assignment_expression
| left_hand_side EQEQ assignment_expression
/* XXX: The above rule causes 4 reduce/reduce conflicts */
/* Code here to warn about == in assignments */
| left_hand_side assignment_operator error
I would remove the line with the EQEQ in it. While the C language
allows the statement:
a == b;
It is really a conditional-statement and not an assignment statement.
Outside of an if-statement it does nothing, unless you have something
a == b++;
I would not allow EQEQ to be used as an assignment operator (it's not
one). Also I would not allow conditional-expressions like this one to
exist outside of if-statements.
If you do as I suggest, then the assignment statement:
a == b;
would cause a syntax error at the '=='
To handle the other problem:
if (a = b) ...
I would not allow an expression inside of an if-statement unless it
were a conditional-expression (which would have to contain a
This would cause a syntax error at the ')' and force the student to
if ((a=b) == c) ...
if (a == b) ...
Whatever the student was attempting to express. I think it can be
done in the grammar, as long as you make a distinction between
expressions and conditional-expressions, and where they can be used.
Paul B Mann
Return to the
Search the comp.compilers archives again.