1. CH4.1 CSE244 Introduction to LR Parsing Aggelos Kiayias Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-1155 Storrs, CT 06269 aggelos@cse.uconn.edu http://www.cse.uconn.edu/~akiayias

2. CH4.2 CSE244Example Consider: S  aABe A  Abc | b B  d Rightmost Derivation of the string abbcde: S  aABe  aAde  aAbcde  abbcde The (unique) handle is underlined for each step. A viable prefix is (1) a string that equals a prefix of a right-sentential form up to (and including) its unique handle. (2) any prefix of a string that satisfies (1) Examples: a, aA, aAd, aAbc, ab, aAb,… Not viable prefixes: aAde, Abc, aAA,…

3. CH4.3 CSE244 Shift/Reduce Parser $abbcde$SHIFT $ab bcde$REDUCE $aA bcde$SHIFT $aAb cde$SHIFT (?) $aAbc de$REDUCE $aA de$SHIFT $aAd e$REDUCE $aAB e$SHIFT $aABe $REDUCE $S $ACCEPT STACKINPUTRemark Observe: all Strings in the stack are viable prefixes

4. CH4.4 CSE244 When to shift? When to Reduce?  Sometimes on top of the stack something appears to be a handle (i.e., matches the RHS of a production).  But: maybe we have not shifted enough elements to identify the handle.  Observe the correct sequence of Shift and Reduce steps preserves the property that the stack IS a viable prefix. Example Shift or Reduce? $aAb cde$ Shift or Reduce?  If we shift we obtain in the stack.  If we shift we obtain aAbc in the stack.  Recall that Abc is a handle.  Instead if we reduce we obtain in the stack.  Instead if we reduce we obtain aAA in the stack. (this is NOT a viable prefix!!!)

5. CH4.5 CSE244 When to Shift? When to Reduce? II  In order to make shift/reduce decisions:  We need to look to perhaps a few elements inside the stack.  We need to make sure that the way we modify the stack preserves the “viable prefix condition.”  For our previous example:  Any b appearing to the right of “A” should not be reduced.  In fact we can come up with heuristic decisions based on the grammar structure:  A “b” is reduced only if it is to the right of “a”  PROBLEM: what kind of information do we need to store inside the stack so that we can make decisions as above just by looking at the top element?

6. CH4.6 CSE244 LR Parsing  LR (left-to-right, rightmost derivation).  LR(1) = 1 lookahead symbol.  Use stack  Stack contains “more information” (in a compressed form) compared to a Top-Down Table- driven parser.  LR(1):  Decisions are taken looking at the top of the stack + 1 input element.

7. CH4.7 CSE244 Anatomy of an LR parser a+b$ X s X s Input LR Parsing Program Stack Output Parsing Table action[.,.] goto[.,.] (String + terminator) NT + T symbols of CFG What actions parser should take based on stack / input General parser behavior: s : top of stack a : current input 1. If action[s,a]=“accept” halt, accept, success 2.If action[s,a]=“reduce by production A  ” do the following: 2a. Pop 2*|  | elements from the stack. 2b. Push A 2c. Push goto[s*,A] 3.If action[s,a]=“shift and goto state s*” Shift; push s* “States”

8. CH4.8 CSE244Example 1. S  aABe 2. A  Abc 3. A  b 4. B  d abcde$SAB 0 s1 s19 1 s3 s32 2 s4 s4 s8 s85 3 r3 r3 4 s6 s6 5 s7 s7 6 r2 r2 7 r1 r1 8 r4 r4 9acc actiongoto

9. CH4.9 CSE244 Example, II $0 abbcde $ STACKINPUTRemark

10. CH4.10 CSE244 Interesting Fact + LR Parsing Table Construction Methods HOW TO CONSTRUCT SUCH TABLES?  The set of all viable prefixes is Regular.  It is possible to write a DFA that recognizes it!  Use the DFA as an aid to construction of the table. Design Methodologies:  SLR (simple LR) “short table but limited methodology.”  Canonical LR “general methodology but big table.”  LALR (lookahead LR) “in between”