Eliminating Left-Recursion Where some of a nonterminal’s productions are left-recursive, top-down parsing is not possible “Immediate” left-recursion can be easily eliminated eg from E ::= E + T | E * T | T produce E ::= T E2 E2 ::= + T E2 | * T E2 |  generally, make new productions for all the non-left-recursive old productions, using a new nonterminal make right-recursive productions for that new nonterminal, plus one  -production Non-immediate left-recursion (among several nonterminals) can be eliminated by ordering the nonterminals, cleaning them up one by one, and inlining previously cleaned productions for any leftmost nonterminals … see book p213 for detail Compiler Construction1

Perils of eliminating left recursion Any “Semantic actions” associated with productions need to be moved around so as to ensure they are still executed in the correct order Constructions which ought naturally to be parsed into a left-associative tree (such as “-”) now generate a right-associative tree, needing more care in code generation Empty productions are introduced into the grammar. –they too can if necessary be eliminated by separate technique Compiler Construction2

Ambiguous grammars If a grammar is ambiguous, it means that some sentences in the language it generates can be derived in more than one way Advantages of such grammars  the grammars are shorter and therefore simpler  the descriptions may be more natural, fewer nonterminals like Term, Factor  can allow special-case optimisations  parsing can be faster with time not wasted on “single productions|” –eg Term ::= Factor Disadvantages  Not LR, so parsing tables contain conflicts Fixes: Operator precedence; Parsing preferences – delete some parsing table entries Compiler Construction3

LR(0) automaton for ambiguous ‘Expression’ grammar E ::= E + E | E * E | ( E ) | id Compiler Construction4 I 0 E’ ::= E & E I 1 E’ ::= E E ::= E + E E ::= E * E I 4 E ::= E + E & E I 7 E ::= E + E E ::= E * E I 2 E ::= ( E ) & E I 3 E ::= id I 5 E ::= E * E & E I 6 E ::= ( E ) E ::= E + E E ::= E * E I 8 E ::= E * E E ::= E + E E ::= E * E I 9 E ::= ( E ) &E means E ::= E + E E ::= E * E E ::= ( E ::= id E ( id + * E E + + ( ( * ) Shift/Reduce conflicts arise at I 7 and I 8 + * *

Shift/Reduce conflicts, resolutions At I 7, reached after “E + E” if next is +, both shift and reduce are possible (as + is in FOLLOW(E))  shift, reduce correspond to + being right-, left-associative respectively if next is *, again both shift and reduce are possible  shift corresponds to giving * higher precedence than +  reduce corresponds to giving + higher precedence than * Similarly at I 8, reached after “E*E” if next is *,  shift, reduce correspond to * being right-, left-associative respectively if next is +,  shift corresponds to giving + higher precedence than *  reduce corresponds to giving * higher precedence than + Select just one of the possible actions to achieve the effect that is desired Compiler Construction5

Error detection and reporting in LR parsers Errors are detected when the parser reaches a state where the parsing table has no action for a combination of [next input token, top state on stack] None of SLR, LALR, or LR parsers will shift any tokens beyond the point where input has an error LR will not perform any reductions either; LALR may perform some; SLR may perform even more. It is possible to perform a panic-mode recovery, or to have recovery routines. Compiler Construction6

Panic-mode recovery in LR (& LALR & SLR) Pick one or more nonterminal corresponding to a significant program fragment, such as Statement or Block Arrange for errors to be handled by  scanning the stack for the first state s having a GOTO on such a nonterminal – say X  then skipping input tokens until finding one w that can follow X  remove all stack above s  add GOTO(X, w) to the stack  announce that an X has been inserted  continue parsing Compiler Construction7

Error routines in LR etc Routines can be written that are tailored to handling particular errors  It will be common for one routine to be appropriate for several of the blanks in the parsing table  Pointers to such routines can be inserted many times in the parsing table These routines can produce messages reflecting the diagnosis of errors programmers frequently make  eg “missing operand”, “unbalanced closing parenthesis found” Recovery often involves skipping input tokens, popping states off stack  care is needed with what may happen afterward if a particular rule does not do this  must guarantee eventual termination – input exhausted, or stack empty Compiler Construction8

Example error routines e1: push state 3 …id… onto stack, report “missing operand” e2: remove right parenthesis from input, report “unbalanced right parenthesis” e3: push state 4 …+… onto stack, report “missing operator” e4: push state 9 …)… onto stack, report “missing right parenthesis” Compiler Construction9