shift/reduce conflict in Happy

Question

How can I make correct rules for parsing if-then[-else] case? Here is some grammar:

{
 module TestGram (tparse) where
}

%tokentype    { String  }
%token one    { "1"     } 
       if     { "if"    }
       then   { "then"  }
       else   { "else"  }

%name tparse  

%%

statement : if one then statement else statement {"if 1 then ("++$4++") else ("++$6++")"}
          | if one then statement                {"if 1 then ("++$4++")"}
          | one                                  {"1"}


{
 happyError = error "parse error"
}

This grammar parses the following expression correctly:

> tparse ["if","1","then","if","1","then","1","else","1"]
"if 1 then (if 1 then (1) else (1))"

But compiling raises a warning about shift/reduce conflict. The documentation to the happy contains an example of such conflict: http://www.haskell.org/happy/doc/html/sec-conflict-tips.html

There are two solutions shown, the first is to change the recursion type (not clear how to do it in this case). And the second is not to change anything. This option is ok for me, but I need a consultation.

Don't know much about happy, but this is a [well-known example of an ambiguous grammar](http://en.wikipedia.org/wiki/Dangling_else). (Like, _the_ example everyone starts with when teaching about parser generators and the like.) The usual fix for these things is to choose a default parenthesization, and require parentheses for the other one; this can be achieved by having two kinds of "statement"s: one which allows both if/then/else clauses and if/then clauses, and one that doesn't. — Daniel Wagner, May 17 '12 at 17:07
It's OK to leave the conflict in place. It's traditionally present in LALR grammars for languages with the optional `else`. The parsers do The Right Thing by default, so there's nothing to worry about. — n. m. could be an AI, May 17 '12 at 17:08

score 5 · Accepted Answer · answered May 26 '12 at 11:59

Note that it is possible to resolve this with a grammar in LALR(1) without an S/R conflict:

stmt: open
    | closed

open: if one then stmt             {"if 1 then ("++$4++")"}
    | if one then closed else open {"if 1 then ("++$4++") else ("++$6++")"}

closed: one                            {"1"}
      | if one then closed else closed {"if 1 then ("++$4++") else ("++$6++")"}

The idea comes from this page on resolving the dangling else/if-else ambiguity.

The basic notion is that we class statements as "open" or "closed": open statements are those which have at least one if that isn't paired with a following else; closed are those which have no if at all, or which do have them, but they're all paired with else.

Parsing if one then if one then one else one thus parses:

. if — shift
if . one — shift
if one . then — shift
if one then . if — shift
if one then if . one — shift
if one then if one . then — shift
if one then if one then . one — shift
if one then if one then (one) . else — reduce by closed rule 1
if one then if one then closed . else — shift
if one then if one then closed else . one — shift
if one then if one then closed else (one) . — reduce by closed rule 1
if one then (if one then closed else closed) . — reduce by closed rule 2
if one then (closed) . — reduce by stmt rule 2
(if one then stmt) . — reduce by open rule 1
(open) . — reduce by stmt rule 1
stmt . — stop

(When a reduce occurs, I've stated which reduction rule occurs, and have put parentheses around the tokens being reduced.)

We can see that the parser has no ambiguity in LALR(1) (or rather, Happy or bison will tell us ;-)), and that following the rules produces the correct interpretation, with the inner if being reduced together with the else.

shift/reduce conflict in Happy

1 Answers1