Bison: Bad if structure - c++

Question

I've made a complete parser in bison ( and of course complete lexer in flex ), and I noticed only yesterday that I've a problem in my parser. In If structure in fact.
Here are my rules in my parser: http://pastebin.com/TneESwUx
Here the single IF is not recognized, and if I replace "%prec IFX" with "END", by adding a new token "END" ("end" return END; in flex), it works. But I don't want to have a new "end" keyword, that's why I don't use this solution.
Please help me.

Answer 1

'The correct way to handle this kind of rule is not precedence, it is refactoring to use an optional else-part so that the parser can use token lookahead to decide how to parse. I would design it something like this:
stmt : IF '(' expression ')' stmts else_part
| /* other statement productions here */
else_part : /* optional */
| ELSE stmts
stmts : stmt
| '{' stmt_list '}'
| '{' '}'
stmt_list : stmt
| stmt_list ';' stmt
(This method of special-casing stmts instead of allowing stmt to include a block may not be optimal in terms of productions, and may introduce oddities in your language, but without more details it's hard to say for certain. bison can produce a report showing you how the parser it generated works; you may want to study it. Also beware of unexpected shift/reduce conflicts and especially of any reduce/reduce conflicts.)
Note that shift/reduce conflicts are entirely normal in this kind of grammar; the point of an LALR(1) parser is to use these conflicts as a feature, looking ahead by a single token to resolve the conflict. They are reported specifically so that you can more easily detect the ones you don't want, that you introduce by incorrectly factoring your grammar.
Your IfExpression also needs to be refactored to match; the trick is that else_part should produce a conditional expression of some kind to $$, and in the production for IF you test $6 (corresponding to else_part) and invoke the appropriate IfExpression constructor.

Answer 2

Your grammar is ambiguous, so you have to live with the shift/reduce conflict. The END token eliminates the ambiguity by ensuring that an IF statement is always properly closed, like a pair of parentheses.
Parentheses make a good analogy here. Suppose you had a grammar like this:
maybe_closed_parens : '(' stuff
| '(' stuff ')'
;
stuff itself generates some grammar symbols, and one of them is maybe_closed_parens.
So if you have input like ((((((whatever, it is correct. The parentheses do not have to be closed. But what if you add )? Which ( is it closing?
This is very much like not being able to tell which IF matches an ELSE.
If you add END to the syntax of the IF (whether or not there is an ELSE), then that is like having a closing parentheses. IF and END are like ( and ).
Of course, you are stylistically right not to want the word END in your language, because you already have curly braced blocks, which are basically an alternate spelling for Pascal's BEGIN and END. Your } is already an END keyword.
So what you can do is impose the rule that an IF accepts only compound statements (i.e. fully braced):
if_statement : IF condition compound_statement
| IF condition compound_statement ELSE compound_statement
Now it is impossible to have an ambiguity like if x if y w else z because braces must be present: if x { if y { w } else { z } } or if x { if y { w } } else { z }.
I seem to recall that Perl is an example of a language which has made this choice. It's not a bad idea because not only does it eliminate your ambiguity, more importantly it eliminates ambiguities from programs.
I see that you don't have a compound_statement phrase structure rule in your grammar because your statement generates a phrase enclosed in { and } directly. You will have to hack that in if you take this approach.