>As already mentioned with regards to the Java grammar, I think that a
>grammar with unrolled implied rules is a maintenance nightmare. How
>should any new kind of statement be added correctly, if the reason and
>the criteria for the splitting into open and closed statements is not
>documented explicitly, but instead is only built into an existing grammar?
This grammar solution is just an exercise of theoretical
interest. Yacc and most other tools can handle the ambiguous grammar
correctly.

>That's why I would prefer an explicit syntactical termination of an
>if-statement, by e.g. an "endif" or "fi" terminal, over your solution.
>This would IM eliminate the dangling else problem, without the risk of
>collissions with other rules, in the current or any future extended
>grammar.
There is no need to modify the ambiguous grammar in any way to get a
correct parser. All that is needed is to choose one or the other of
the two possible parses. Yacc does this by preferring the shift over
the reduce. SLK does this by using the first production of the two
alternates as the parse table entry.

SLK Parsers schrieb:

There is no need to modify the ambiguous grammar in any way to get a
correct parser. All that is needed is to choose one or the other of
the two possible parses. Yacc does this by preferring the shift over
the reduce. SLK does this by using the first production of the two
alternates as the parse table entry.

Hmmm, how can you ever be sure, that the solution for the dangling else
always will be correct, also in other ambiguous situations?

DoDi

>How would I guess which one is that?

The technique is called "controlled ambiguity" in the Dragon book. You can
read about it there. I leave the LL solution as an exercise for the
interested reader, as if there are any.

Hint 1: We want to associate the ELSE with the closest IF, so use the
production that consumes the ELSE sooner.

Hint 2: There are only 2 possibilities, try them both and see which one
works.

The grammar solution is quite clever. If it were not so redundant, and
solved a problem that actually exists, it would be useful.

Forget about yacc for a minute. Assume you were creating the parse table by
hand. When you got to the shift-reduce conflict, you would say ", I
remember this one from my first year compiler course. I will use the shift
as the entry in the parse table". This is what yacc does automatically.

The SLK parser generator: http://home.earthlink.net/~slkpg/

>Hmmm, how can you ever be sure, that the solution for the dangling else
>always will be correct, also in other ambiguous situations?

It is well-known to be correct, and is explained in compiler texts. It
is a very special case. In general, ambiguity is to be avoided unless
you know what you are doing, and probably even then. That said, I used
the technique seven times in a recent translator, and am confident
that it is correct. This was verified by use on about 1000 real
programs.

The SLK parser generator: http://home.earthlink.net/~slkpg/
[My rule of thumb has been that it's K to use disambiguation for
if/then/else and operator precedence in expressions. Anywhere else
you're likely to get into trouble. -John]