Parsing VI The LR(1) Table Construction. LR(k) items The LR(1) table construction algorithm uses LR(1) items to represent valid configurations of an LR(1)

Slides:



Advertisements
Similar presentations
A question from last class: construct the predictive parsing table for this grammar: S->i E t S e S | i E t S | a E -> B.
Advertisements

Compiler Theory – 08/10(ppt) By Anindhya Sankhla 11CS30004 Group : G 29.
Compiler Designs and Constructions
Compiler Construction Sohail Aslam Lecture Finite Automaton of Items Then for every item A →  X  we must add an  -transition for every production.
Parsing Wrap Up Comp 412 Copyright 2010, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at Rice University have explicit.
Cse321, Programming Languages and Compilers 1 6/12/2015 Lecture #10, Feb. 14, 2007 Modified sets of item construction Rules for building LR parse tables.
6/12/2015Prof. Hilfinger CS164 Lecture 111 Bottom-Up Parsing Lecture (From slides by G. Necula & R. Bodik)
1 CMPSC 160 Translation of Programming Languages Fall 2002 slides derived from Tevfik Bultan, Keith Cooper, and Linda Torczon Lecture-Module #10 Parsing.
Parsing III (Eliminating left recursion, recursive descent parsing)
COS 320 Compilers David Walker. last time context free grammars (Appel 3.1) –terminals, non-terminals, rules –derivations & parse trees –ambiguous grammars.
Parsing VII The Last Parsing Lecture Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at.
Lecture #8, Feb. 7, 2007 Shift-reduce parsing,
Parsing V Introduction to LR(1) Parsers. from Cooper & Torczon2 LR(1) Parsers LR(1) parsers are table-driven, shift-reduce parsers that use a limited.
Parsing — Part II (Ambiguity, Top-down parsing, Left-recursion Removal)
Prof. Fateman CS 164 Lecture 91 Bottom-Up Parsing Lecture 9.
1 LR parsing techniques SLR (not in the book) –Simple LR parsing –Easy to implement, not strong enough –Uses LR(0) items Canonical LR –Larger parser but.
COS 320 Compilers David Walker. last time context free grammars (Appel 3.1) –terminals, non-terminals, rules –derivations & parse trees –ambiguous grammars.
Table-driven parsing Parsing performed by a finite state machine. Parsing algorithm is language-independent. FSM driven by table (s) generated automatically.
1 CIS 461 Compiler Design & Construction Fall 2012 slides derived from Tevfik Bultan, Keith Cooper, and Linda Torczon Lecture-Module #12 Parsing 4.
Parsing Wrap-up. from Cooper and Torczon2 Filling in the A CTION and G OTO Tables The algorithm Many items generate no table entry  Closure( ) instantiates.
Shift/Reduce and LR(1) Professor Yihjia Tsai Tamkang University.
Bottom-up parsing Goal of parser : build a derivation
Lexical and syntax analysis
Parsing IV Bottom-up Parsing Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at Rice University.
Parsing IV Bottom-up Parsing. Parsing Techniques Top-down parsers (LL(1), recursive descent) Start at the root of the parse tree and grow toward leaves.
LR(1) Parsers Comp 412 Copyright 2010, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at Rice University have explicit.
LESSON 24.
Top-Down Parsing - recursive descent - predictive parsing
Lexical Analysis — Part II: Constructing a Scanner from Regular Expressions.
Parsing III (Top-down parsing: recursive descent & LL(1) )
Profs. Necula CS 164 Lecture Top-Down Parsing ICOM 4036 Lecture 5.
Review 1.Lexical Analysis 2.Syntax Analysis 3.Semantic Analysis 4.Code Generation 5.Code Optimization.
Prof. Necula CS 164 Lecture 8-91 Bottom-Up Parsing LR Parsing. Parser Generators. Lecture 6.
Syntax Analysis - LR(0) Parsing Compiler Design Lecture (02/04/98) Computer Science Rensselaer Polytechnic.
Top-down Parsing lecture slides from C OMP 412 Rice University Houston, Texas, Fall 2001.
Parsing — Part II (Top-down parsing, left-recursion removal) Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students.
1 Syntax Analysis Part II Chapter 4 COP5621 Compiler Construction Copyright Robert van Engelen, Florida State University, 2005.
Parsing V LR(1) Parsers C OMP 412 Rice University Houston, Texas Fall 2001 Copyright 2000, Keith D. Cooper, Ken Kennedy, & Linda Torczon, all rights reserved.
Top-down Parsing Recursive Descent & LL(1) Comp 412 Copyright 2010, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp 412.
Top-Down Parsing CS 671 January 29, CS 671 – Spring Where Are We? Source code: if (b==0) a = “Hi”; Token Stream: if (b == 0) a = “Hi”; Abstract.
Top-down Parsing. 2 Parsing Techniques Top-down parsers (LL(1), recursive descent) Start at the root of the parse tree and grow toward leaves Pick a production.
Top-Down Parsing.
CS 330 Programming Languages 09 / 25 / 2007 Instructor: Michael Eckmann.
Parsing VII The Last Parsing Lecture. High-level overview  Build the canonical collection of sets of LR(1) Items, I aBegin in an appropriate state, s.
Parsing V LR(1) Parsers N.B.: This lecture uses a left-recursive version of the SheepNoise grammar. The book uses a right-recursive version. The derivations.
Parsing III (Top-down parsing: recursive descent & LL(1) )
Bottom Up Parsing CS 671 January 31, CS 671 – Spring Where Are We? Finished Top-Down Parsing Starting Bottom-Up Parsing Lexical Analysis.
Parsing V LR(1) Parsers. LR(1) Parsers LR(1) parsers are table-driven, shift-reduce parsers that use a limited right context (1 token) for handle recognition.
1 Syntax Analysis Part II Chapter 4 COP5621 Compiler Construction Copyright Robert van Engelen, Florida State University, 2007.
Compilers: Bottom-up/6 1 Compiler Structures Objective – –describe bottom-up (LR) parsing using shift- reduce and parse tables – –explain how LR.
Chapter 8. LR Syntactic Analysis Sung-Dong Kim, Dept. of Computer Engineering, Hansung University.
Announcements/Reading
Lexical and Syntax Analysis
LR(1) Parsers Comp 412 COMP 412 FALL 2010
Table-driven parsing Parsing performed by a finite state machine.
Parsing VI The LR(1) Table Construction
LALR Parsing Canonical sets of LR(1) items
Syntax Analysis Part II
Implementing a LR parser engine
N.B.: This lecture uses a left-recursive version of the SheepNoise grammar. The book uses a right-recursive version. The derivations (& the tables) are.
Lexical and Syntax Analysis
Top-Down Parsing CS 671 January 29, 2008.
Parsing VII The Last Parsing Lecture
Lecture 8 Bottom Up Parsing
Automating Scanner Construction
Kanat Bolazar February 16, 2010
Compiler Construction
Chap. 3 BOTTOM-UP PARSING
Lecture 11 LR Parse Table Construction
Lecture 11 LR Parse Table Construction
Presentation transcript:

Parsing VI The LR(1) Table Construction

LR(k) items The LR(1) table construction algorithm uses LR(1) items to represent valid configurations of an LR(1) parser An LR(k) item is a pair [ P,  ], where P is a production A  with a at some position in the rhs  is a lookahead string of length ≤ k (words or EOF ) The in an item indicates the position of the top of the stack [ A  ,a] means that the input seen so far is consistent with the use of A  immediately after the symbol on top of the stack [A  ,a] means that the input seen so far is consistent with the use of A  at this point in the parse, and that the parser has already recognized . [A ,a] means that the parser has seen , and that a lookahead symbol of a is consistent with reducing to A.

High-level overview  Build the canonical collection of sets of LR(1) Items, I aBegin in an appropriate state, s 0  [S’  S, EOF ], along with any equivalent items  Derive equivalent items as closure( s 0 ) bRepeatedly compute, for each s k, goto(s k,X), where X is all NT and T  If the set is not already in the collection, add it  Record all the transitions created by goto( ) This eventually reaches a fixed point 2Fill in the table from the collection of sets of LR(1) items The canonical collection completely encodes the transition diagram for the handle-finding DFA (see Figure 3.18 in EaC) LR(1) Table Construction

The SheepNoise Grammar ( revisited ) We will use this grammar extensively in today’s lecture 1. Goal  SheepNoise 2. SheepNoise  baa SheepNoise 3. | baa

Computing F IRST Sets Define F IRST as If   * a , a  T,   (T  NT)*, then a  F IRST (  ) If   * , then   F IRST (  ) Note: if  = X , F IRST (  ) = F IRST ( X) To compute F IRST Use a fixed-point method F IRST (A)  2 (T   ) Loop is monotonic  Algorithm halts

Computing F IRST Sets for each x  T, FIRST(x)  { x } for each A  NT, FIRST(A)  Ø while (FIRST sets are still changing) for each p  P, of the form A , if  is B 1 B 2 …B k where B i  T  NT then begin FIRST(A)  FIRST(A)  ( FIRST(B 1 ) – {  } ) for i  1 to k–1 by 1 while   FIRST(B i ) FIRST(A)  FIRST(A)  ( FIRST(B i +1 ) – {  } ) if i = k and   FIRST(B k ) then FIRST(A)  FIRST(A)  {  }

Computing Closures Closure(s) adds all the items implied by items already in s Any item [A   B ,a] implies [B  ,x] for each production with B on the lhs, and each x  F IRST (  a) Since  B  is valid, any way to derive  B  is valid, too The algorithm Closure( s ) while ( s is still changing )  items [A  B ,a]  s  productions B    P  b  F IRST (  a) //  might be  if [B  ,b]  s then add [B  ,b] to s  Classic fixed-point method  Halts because s  LR I TEMS  Closure “fills out” state s

Example From SheepNoise Initial step builds the item [Goal  SheepNoise, EOF ] and takes its closure( ) Closure( [Goal  SheepNoise, EOF ] ) So, S 0 is { [Goal  SheepNoise,EOF], [SheepNoise  baa SheepNoise,EOF], [SheepNoise  baa,EOF] }

Computing Gotos Goto(s,x) computes the state that the parser would reach if it recognized an x while in state s Goto( { [A   X ,a] }, X ) produces [A   X ,a] (easy part) Also computes closure( [A   X ,a] ) ( fill out the state ) The algorithm Goto( s, X ) new  Ø  items [A X ,a]  s new  new  [A  X ,a] return closure(new)  Not a fixed-point method!  Straightforward computation  Uses closure ( ) Goto() moves forward

Example from SheepNoise S 0 is { [Goal  SheepNoise, EOF ], [SheepNoise  baa SheepNoise, EOF ], [SheepNoise  baa, EOF ] } Goto( S 0, baa ) Loop produces Closure adds two items since is before SheepNoise in first

Example from SheepNoise S 0 : { [Goal  SheepNoise, EOF ], [SheepNoise  baa SheepNoise, EOF ], [SheepNoise  baa, EOF ]} S 1 = Goto(S 0, SheepNoise ) = { [Goal  SheepNoise, EOF ] } S 2 = Goto(S 0, baa ) = { [SheepNoise  baa, EOF ], [SheepNoise  baa SheepNoise, EOF], [SheepNoise  baa, EOF ], [SheepNoise  baa SheepNoise, EOF], } S 3 = Goto(S 1, SheepNoise) = { [SheepNoise  baa SheepNoise, EOF ] }

Building the Canonical Collection Start from s 0 = closure( [S’  S, EOF ] ) Repeatedly construct new states, until all are found The algorithm s 0  closure ( [S’  S,EOF] ) S  { s 0 } k  1 while ( S is still changing )  s j  S and  x  ( T  NT ) s k  goto(s j,x) record s j  s k on x if s k  S then S  S  s k k  k + 1  Fixed-point computation  Loop adds to S  S  2 (LR ITEMS), so S is finite Worklist version is faster

Example from SheepNoise Starts with S 0 S 0 : { [Goal  SheepNoise, EOF ], [SheepNoise  baa SheepNoise, EOF ], [SheepNoise  baa, EOF ]}

Example from SheepNoise Starts with S 0 S 0 : { [Goal  SheepNoise, EOF ], [SheepNoise  baa SheepNoise, EOF ], [SheepNoise  baa, EOF ]} Iteration 1 computes S 1 = Goto(S 0, SheepNoise ) = { [Goal  SheepNoise, EOF ] } S 2 = Goto(S 0, baa) = { [SheepNoise  baa, EOF], [SheepNoise  baa SheepNoise, EOF], [SheepNoise  baa, EOF], [SheepNoise  baa SheepNoise, EOF]}

Example from SheepNoise Starts with S 0 S 0 : { [Goal  SheepNoise, EOF ], [SheepNoise  baa SheepNoise, EOF ], [SheepNoise  baa, EOF ]} Iteration 1 computes S 1 = Goto(S 0, SheepNoise ) = { [Goal  SheepNoise, EOF ] } S 2 = Goto(S 0, baa) = { [SheepNoise  baa, EOF], [SheepNoise  baa SheepNoise, EOF], [SheepNoise  baa, EOF], [SheepNoise  baa SheepNoise, EOF]} Iteration 2 computes Goto(S 2,baa) creates S 2 S 3 = Goto(S 2,SheepNoise) = {[SheepNoise  baa SheepNoise, EOF]}

Example from SheepNoise Starts with S 0 S 0 : { [Goal  SheepNoise, EOF ], [SheepNoise  baa SheepNoise, EOF ], [SheepNoise  baa, EOF ]} Iteration 1 computes S 1 = Goto(S 0, SheepNoise ) = { [Goal  SheepNoise, EOF ] } S 2 = Goto(S 0, baa) = { [SheepNoise  baa, EOF], [SheepNoise  baa SheepNoise, EOF], [SheepNoise  baa, EOF], [SheepNoise  baa SheepNoise, EOF]} Iteration 2 computes Goto(S 2,baa) creates S 2 S 3 = Goto(S 2,SheepNoise) = {[SheepNoise  baa SheepNoise, EOF]} Nothing more to compute, since is at the end of the item in S 3.

Example ( grammar & sets ) Simplified, right recursive expression grammar Goal  Expr Expr  Term – Expr Expr  Term Term  Factor * Term Term  Factor Factor  ident

Example ( building the collection ) Initialization Step s 0  closure( { [Goal  Expr, EOF ] } ) { [Goal  Expr, EOF ], [Expr  Term – Expr, EOF ], [Expr  Term, EOF ], [Term  Factor * Term, EOF ], [Term  Factor * Term, –], [Term  Factor, EOF ], [Term  Factor, –], [Factor  ident, EOF ], [Factor  ident, –], [Factor  ident, *] } S  {s 0 }

Example ( building the collection ) Iteration 1 s 1  goto(s 0, Expr) s 2  goto(s 0, Term) s 3  goto(s 0, Factor) s 4  goto(s 0, ident ) Iteration 2 s 5  goto(s 2, – ) s 6  goto(s 3, * ) Iteration 3 s 7  goto(s 5, Expr ) s 8  goto(s 6, Term )

Example (Summary) S 0 : { [Goal  Expr, EOF], [Expr  Term – Expr, EOF], [Expr  Term, EOF], [Term  Factor * Term, EOF], [Term  Factor * Term, –], [Term  Factor, EOF ], [Term  Factor, –], [Factor  ident, EOF ], [Factor  ident, –], [Factor  ident, *] } S 1 : { [Goal  Expr, EOF ] } S 2 : { [Expr  Term – Expr, EOF ], [Expr  Term, EOF ] } S 3 : { [Term  Factor * Term, EOF ],[Term  Factor * Term, –], [Term  Factor, EOF ], [Term  Factor, –] } S 4 : { [Factor  ident, EOF ],[Factor  ident, –], [Factor  ident, *] } S 5 : { [Expr  Term – Expr, EOF ], [Expr  Term – Expr, EOF ], [Expr  Term, EOF ], [Term  Factor * Term, –], [Term  Factor, –], [Term  Factor * Term, EOF ], [Term  Factor, EOF ], [Factor  ident, *], [Factor  ident, –], [Factor  ident, EOF ] }

Example ( Summary ) S 6 : { [Term  Factor * Term, EOF ], [Term  Factor * Term, –], [Term  Factor * Term, EOF ], [Term  Factor * Term, –], [Term  Factor, EOF ], [Term  Factor, –], [Factor  ident, EOF ], [Factor  ident, –], [Factor  ident, *] } S 7 : { [Expr  Term – Expr, EOF ] } S 8 : { [Term  Factor * Term, EOF ], [Term  Factor * Term, –] }

Example (Summary) The Goto Relationship (from the construction)

Filling in the A CTION and G OTO Tables The algorithm Many items generate no table entry  Closure( ) instantiates F IRST (X) directly for [A X ,a ]  set s x  S  item i  s x if i is [A   ad,b] and goto(s x,a) = s k, a  T then A CTION [x,a]  “shift k” else if i is [S’  S, EOF ] then A CTION [x,a]  “accept” else if i is [A  ,a] then A CTION [x,a]  “reduce A   ”  n  NT if goto(s x,n) = s k then G OTO [x,n]  k x is the state number

Example ( Filling in the tables ) The algorithm produces the following table Plugs into the skeleton LR(1) parser

What can go wrong? What if set s contains [A a ,b] and [B ,a] ? First item generates “shift”, second generates “reduce” Both define ACTION[s,a] — cannot do both actions This is a fundamental ambiguity, called a shift/reduce error Modify the grammar to eliminate it (if-then-else) Shifting will often resolve it correctly What is set s contains [A , a] and [B , a] ? Each generates “reduce”, but with a different production Both define ACTION[s,a] — cannot do both reductions This fundamental ambiguity is called a reduce/reduce error Modify the grammar to eliminate it In either case, the grammar is not LR(1) EaC includes a worked example

Shrinking the Tables Three options: Combine terminals such as number & identifier, + & -, * & /  Directly removes a column, may remove a row  For expression grammar, 198 (vs. 384) table entries Combine rows or columns  Implement identical rows once & remap states  Requires extra indirection on each lookup  Use separate mapping for A CTION & for G OTO Use another construction algorithm  Both L ALR(1) and S LR(1) produce smaller tables  Implementations are readily available

LR(k) versus LL(k) ( Top-down Recursive Descent ) Finding Reductions LR(k)  Each reduction in the parse is detectable with  the complete left context,  the reducible phrase, itself, and  the k terminal symbols to its right LL(k)  Parser must select the reduction based on  The complete left context  The next k terminals Thus, LR(k) examines more context “… in practice, programming languages do not actually seem to fall in the gap between LL(1) languages and deterministic languages” J.J. Horning, “LR Grammars and Analysers”, in Compiler Construction, An Advanced Course, Springer-Verlag, 1976

Summary Advantages Fast Good locality Simplicity Good error detection Fast Deterministic langs. Automatable Left associativity Disadvantages Hand-coded High maintenance Right associativity Large working sets Poor error messages Large table sizes Top-down recursive descent LR(1)