Editing Dangling else (section)

===Avoiding ambiguity while keeping the syntax===

This problem often comes up in [[compiler design|compiler construction]], especially [[scannerless parsing]]. The convention when dealing with the dangling else is to attach the else to the nearby if statement,<ref name="Bison Manual">{{cite book |title=Bison 3.8.1 |section=5.2 Shift/Reduce Conflicts |publisher=GNU |section-url=https://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html#Shift_002fReduce |url=https://www.gnu.org/software/bison/manual/html_node/ |access-date=2021-08-07}}</ref> allowing for unambiguous context-free grammars, in particular. Programming languages like Pascal,<ref>ISO 7185:1990 (Pascal) 6.8.3.4: ''An if-statement without an else-part shall not be immediately followed by the token else.''</ref> C,<ref name="c-standard">[https://www.open-std.org/jtc1/sc22/wg14/www/standards ISO 9899]:1999 (C): 6.8.4.1(3): "An else is associated with the lexically nearest preceding if that is allowed by the syntax.", available at [https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf WG14 N1256], p. 134</ref> and Java<ref>{{cite web |title=The Java Language Specification, Java SE 9 Edition, 14.5. Statements |ref=jls-14.5 |url=https://docs.oracle.com/javase/specs/jls/se9/html/jls-14.html}}</ref> 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 <code>begin...end</code> in Pascal<ref>{{cite book |last1=Dale |first1=Nell B. |last2=Weems |first2=Chip |title=Introduction to Pascal and Structured Design | section=Dangling Else |pages=160–161 |date=November 1996 |publisher=Jones & Bartlett Learning |isbn=9780763703974 |url=https://books.google.com/books?id=5x2k4vWwn1wC&pg=PA160}}</ref> and <code>{...}</code> in C.

Depending on the compiler construction approach, one may take different corrective actions to avoid ambiguity:

*If the parser is produced by an SLR, LR(1), or LALR [[LR parser]] generator, the programmer will often rely on the generated parser feature of preferring shift over reduce whenever there is a conflict.<ref name="Bison Manual"/> Alternatively, the grammar can be rewritten to remove the conflict, at the expense of an increase in grammar size (see [[#Avoiding the conflict in LR parsers|below]]).
*If the parser is hand-written, the programmer may use a ''non-ambiguous'' context-free grammar. Alternatively, one may rely on a non-context-free grammar or a [[parsing expression grammar]].