Dangling else

The dangling else is a problem in computer programming in which an optional else clause in an if–then(–else) statement results in nested conditionals being ambiguous. Formally, the reference context-free grammar of the language is ambiguous, meaning there is more than one correct parse tree.
In many programming languages one may write conditionally executed code in two forms: the if-then form, and the if-then-else form – the else clause is optional:
 if a then s
 if b then s1 else s2
This gives rise to an ambiguity in interpretation when there are nested statements, specifically whenever an if-then form appears as codice_1 in an if-then-else form:
 if a then if b then s else s2
In this example, codice_2 is unambiguously executed when codice_3 is true and codice_4 is true, but one may interpret codice_5 as being executed when codice_3 is false (thus attaching the else to the first if) or when codice_3 is true and codice_4 is false (thus attaching the else to the second if). In other words, one may see the previous statement as either of the following expressions:
 if a then (if b then s) else s2
 if a then (if b then s else s2)
The dangling else problem dates to ALGOL 60, and has been resolved in various ways in subsequent languages. In LR parsers, the dangling else is the archetypal example of a shift-reduce conflict.
Avoiding ambiguity while keeping the syntax.
This is a problem that often comes up in compiler construction, especially scannerless parsing. The convention when dealing with the dangling else is to attach the else to the nearby if statement, allowing for unambiguous context-free grammars, in particular. Programming languages like Pascal, C and Java follow this convention, so there is no ambiguity in the semantics of the "language", though the use of a parser generator may lead to ambiguous "grammars". In these cases alternative grouping is accomplished by explicit blocks, such as codice_9 in Pascal and codice_10 in C.
Depending on the compiler construction approach, one may take different corrective actions to avoid ambiguity:
Avoiding ambiguity by changing the syntax.
The problem can also be solved by making explicit the link between an else and its if, within the syntax. This usually helps avoid human errors.
Possible solutions are:
Examples.
Concrete examples follow.
C.
In C, the grammar reads, in part:
Thus, without further rules, the statement
if (a) if (b) s; else s2;
could ambiguously be parsed as if it were either:
if (a)
 if (b)
 s;
 else
 s2;
or:
if (a)
 if (b)
 s;
else
 s2;
In practice in C the first tree is chosen, by associating the codice_17 with the nearest codice_11.
Avoiding the conflict in LR parsers.
The above example could be rewritten in the following way to remove the ambiguity :
Any other statement-related grammar rules may also have to be duplicated in this way if they may directly or indirectly end with a codice_19 or codice_20 non-terminal.
However, we give grammar that includes both of if and while statements.
Finally, we give the grammar that forbids ambiguous IF statements.
With this grammar parsing of "if (a) if (b) c else d" fails:
and then the parsing fails trying to match codice_21 to "if (b) c". An attempt with codice_21 fails in the same way.