CS 415: Lecture 10

T LR Parsing (backtrack)

Review: LR(k) Grammars

T Informally, we say that a grammar G is LR(k) if, given a

rightmost derivation

S ⇒ γ 0 ⇒ γ1 ⇒ γ 2 ⇒ L ⇒ γ n ⇒ w
we can, for each right-sentential form in the derivation

1. isolate the handle of each right-sentential form, and

2. determine the production by which to reduce

by scanning γ from left to right, going at most k symbols

i

beyond the right end of the handle of γ i

Rutgers University, DCS 2 CS 415: Compilers

1
 LR(1) Parsing

Input: a1 a2 a3 a4...
stack with sn j n
(symbol, state) sn-1 j n-1
pairs sn-2 j n-2 actions

gotos

Rutgers University, DCS 3 CS 415: Compilers

LR(1) Parsing

T Four operations: shift, reduce, accept, and error

T Maintain a stack of (symbol, state) pairs
T Given state s on top of stack and next token j
S Parser does action [s, j] in transition table, which may be shift or
reduce
S Shift
R Entry contains a new state r
R Push (j, r) onto stack
S Reduce
R Entry contains production that should be use for reduction: X → α
R Pop |α| pairs off the stack; a new pair (t, Y) will now be on top of the stack
R Push (X, goto[t,X]) onto stack

Rutgers University, DCS 4 CS 415: Compilers

2
 LR(1) Parsing

token = next_token()
repeat
s = state from top of stack
if action[s,token] = “shift r” then
push (token, r)
token = next_token()
else if action[s,token] = “reduce A ::= B” then
pop |B| pairs off of the stack
s = state from top of stack
push (A, goto[s,A])
else if action[s,token] = “accept” then
return
else error()
endrepeat

Rutgers University, DCS 5 CS 415: Compilers

LR(1) Parsing

❚ Three commonly used algorithms to build parsing

tables for an “LR(1)” parser
S SLR(1)
S LALR(1)
S LR(1)
❚ Increasing generality at cost of larger tables or
slower construction or both

Rutgers University, DCS 6 CS 415: Compilers

3
 SLR(1)

❚ Uses a DFA to recognize viable prefixes of grammar

G
❚ Each state in the DFA is the set of valid LR(0) items
for a viable prefix
❚ Uses FOLLOW to disambiguate actions

❚ Intuitively, keep track of all productions that may

have been used to derive what we have seen so far

Rutgers University, DCS 7 CS 415: Compilers

Viable Prefix

❚ A handle of a right-sentential form γ is a production

A ::= β and a position in γ where β may be found.
❚ A viable prefix is
S A prefix of a right-sentential form that does not continue
past the right end of the handle of that sentential form, or
S A prefix of a right-sentential form that can appear on the
stack of a shift-reduce parser
❚ As long as the prefix represented by the stack is
viable, the parser has not seen a detectable error

Rutgers University, DCS 8 CS 415: Compilers

4
 LR(0) Items

❚ An LR(0) item of a grammar G is some production in

G with a • at some position in the rhs
❚ We say that an LR(0) item is valid for a viable prefix
if the part of the rhs to the left of the • matches
what’s on top of the stack – that is, we have “seen”
the part to the left of the •

❚ What we want is something to:

1. Recognize whether what we have on the stack is a viable
prefix
2. Recognize when we have an entire handle on the stack so we
can do the reduction

Rutgers University, DCS 9 CS 415: Compilers

Example

❚ How do we recognize/generate the viable prefixes of

the following very simple grammar?

S→B
B → aB | b
❚ How about the following?
S′ → S
S → aSb | ab

Rutgers University, DCS 10 CS 415: Compilers

5
 DFA States

I0 : S’ → . S I2 : S → a S . b
S → . aSb
S → . ab I3 : S’ → S .

I1 : S → a . S b I4 : S → a b.
S →a.b
S → . aSb I5 : S → a S b .
S → . ab

Rutgers University, DCS 11 CS 415: Compilers

DFA

a
S b
I0 I1 I2 I5
b
S

I3 I4

Rutgers University, DCS 12 CS 415: Compilers

6
 Encoding the Parser

If A → α . a β in Ik and
actions gotos goto(Ik , a) = Ij table entry
a b $ S for (k,a) is sj for terminal a.
0 s1 _ _ 3
1 s1 s4 _ 2
2 _ s5 _ If A → α . in Ik then table
3 _ _ accept entry for (k,b) is r-rule#
4 r3 r3 r3 where b is any input symbol.
5 r2 r2 r2
If S’ → S. in Ik then table
entry for (k,$) is accept.

Rutgers University, DCS 13 CS 415: Compilers

Example

states/inputs actions gotos

a b $ S
0 s1 _ _ 3
1 s1 s4 _ 2
2 _ s5 _
3 _ _ accept
4 r3 r3 r3
5 r2 r2 r2

stack input action

$0 aabb$ s1
$0a1 abb$ s1
$0a1a1 bb$ s4
$0a1a1b4 b$ r3, goto(1,b) = 2
$0a1S2 b$ s5
$0a1S2b5 $ r2, goto(0,$)=3
$0S3 $ accept
Rutgers University, DCS 14 CS 415: Compilers

7
 SLR(1)

❚ Previous parser is called LR(0) because we used no

knowledge of the input
❚ SLR(1) is a somewhat stronger parser that adds
knowledge about next input symbol
S Sometimes needed to break shift-reduce conflicts
S Use FOLLOW set

Rutgers University, DCS 15 CS 415: Compilers

SLR(1)

❚ Follow set: the set of terminals which can follow a

specific non-terminal in a rightmost derivation
S New rule for reduce: only reduce when next input symbol is
an element of Follow set of the resulting nonterminal
S In the previous example, we would eliminate reductions in
states 4,5 on a because this can’t be followed by a

Rutgers University, DCS 16 CS 415: Compilers

8
 Shift/Reduce Conflict

S’ → S
S →Ab|dc|bAc
A →d
A very simple language = {db, dc, bdc}
Follow(S) = {$}, Follow(A) = {b,c}
Form part of the SLR(1) parser:
I0 : S’ → . S I1 : S → d . c
S → .A b A → d.
S → .dc But since c is in Follow(A), we don’t
S → .b A c know whether to reduce or shift in state
A → .d I if c is next input symbol!
1

Deriv1: S’ → S → dc; Deriv2; S’ → S → bAc → bdc

Rutgers University, DCS 17 CS 415: Compilers

Reduce/Reduce Conflict

S’ → S Deriv1: S’ → S →Ac → dc
S→bAe|bBd|Ac Deriv2: S’ → S → bBd →bEcd →bdcd
A→d Deriv3: S’ → S → bAe → bde
B→Ec
E→d

I0 : S’ →. S I1 : S → b . A e I2 : A → d.
S→.bAe S→b.Bd E → d.
S→.bBd A→.d
S→.Ac B→.Ec Which reduction to take?
A → .d E→.d Follow set too imprecise
here to decide.

Rutgers University, DCS 18 CS 415: Compilers

9
 LR(k)

❚ Solution: keep more information about what next

input symbol can be on any parse
S Idea: keep an input lookahead as part of each item
S More precise than Follow sets which essentially union these
lookaheads for non-terminal A over all sentential forms in
which the A appears
S Potentially gives rise to much bigger parsers than SLR(1)
(more states)

Rutgers University, DCS 19 CS 415: Compilers

LR(k)

❚ LR(k) looks k symbols ahead into the input

❚ There are some grammars which are not parsable
with only k look-ahead symbols
❚ Most computer programming languages are LR(k)

Rutgers University, DCS 20 CS 415: Compilers

10