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.

Answer 1

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.