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

Example 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,…

Shift/Reduce Parser Observe: all STACK INPUT Remark $ abbcde$ SHIFT $a bbcde$ 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 Observe: all Strings in the stack are viable prefixes

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 (real) handle. Observe the correct sequence of Shift and Reduce steps preserves the property that the stack IS a viable prefix. Example $aAb cde$ Shift or Reduce? If we shift we obtain aAbc in the stack. Recall that Abc is a handle. Instead if we reduce we obtain aAA in the stack. (this is NOT a viable prefix!!!)

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?

LR Parsing LR (left-to-right, rightmost derivation). LR(1) = 1 lookahead symbol. Use stack Stack should contain “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.

Parsing Table action[.,.] goto[.,.] Anatomy of an LR parser a + b $ Input (String + terminator) “States” Stack NT + T symbols of CFG LR Parsing Program X s Output What actions parser should take based on stack / input Parsing Table action[.,.] goto[.,.] General parser behavior: s : top of stack a : current input 1. If action[s,a]=“accept” halt, accept, success 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] If action[s,a]=“shift and goto state s*” Shift; push s*

Example action goto S A B s1 9 1 s3 2 s4 s8 5 3 r3 4 s6 s7 6 r2 7 r1 8 1. S  aABe 2. A  Abc 3. A  b 4. B  d action goto a b c d e $ S A B s1 9 1 s3 2 s4 s8 5 3 r3 4 s6 s7 6 r2 7 r1 8 r4 acc

Example, II $0 abbcde$ STACK INPUT Remark

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”