Compiler Design 1. LR Parsing. Goutam Biswas. Lect 7

Similar documents
LR2: LR(0) Parsing. LR Parsing. CMPT 379: Compilers Instructor: Anoop Sarkar. anoopsarkar.github.io/compilers-class

Syntax Analysis (Part 2)

I 1 : {S S } I 2 : {S X ay, Y X } I 3 : {S Y } I 4 : {X b Y, Y X, X by, X c} I 5 : {X c } I 6 : {S Xa Y, Y X, X by, X c} I 7 : {X by } I 8 : {Y X }

Shift-Reduce parser E + (E + (E) E [a-z] In each stage, we shift a symbol from the input to the stack, or reduce according to one of the rules.

Lecture 11 Sections 4.5, 4.7. Wed, Feb 18, 2009

Compiler Design Spring 2017

Administrivia. Test I during class on 10 March. Bottom-Up Parsing. Lecture An Introductory Example

Bottom up parsing. General idea LR(0) SLR LR(1) LALR To best exploit JavaCUP, should understand the theoretical basis (LR parsing);

CS 406: Bottom-Up Parsing

Parsing -3. A View During TD Parsing

Bottom-Up Parsing. Ÿ rm E + F *idÿ rm E +id*idÿ rm T +id*id. Ÿ rm F +id*id Ÿ rm id + id * id

EXAM. CS331 Compiler Design Spring Please read all instructions, including these, carefully

THEORY OF COMPILATION

CA Compiler Construction

LR(1) Parsers Part III Last Parsing Lecture. Copyright 2010, Keith D. Cooper & Linda Torczon, all rights reserved.

Compiler Construction

Bottom-up syntactic parsing. LR(k) grammars. LR(0) grammars. Bottom-up parser. Definition Properties

Computer Science 160 Translation of Programming Languages

EXAM. Please read all instructions, including these, carefully NAME : Problem Max points Points 1 10 TOTAL 100

Chapter 4: Bottom-up Analysis 106 / 338

Compiler Construction Lent Term 2015 Lectures (of 16)

Bottom-up syntactic parsing. LR(k) grammars. LR(0) grammars. Bottom-up parser. Definition Properties

Parsing VI LR(1) Parsers

Why augment the grammar?

Compiler Construction Lectures 13 16

Bottom-up syntactic parsing. LR(k) grammars. LR(0) grammars. Bottom-up parser. Definition Properties

Translator Design Lecture 16 Constructing SLR Parsing Tables

Compiler Construction Lent Term 2015 Lectures (of 16)

Bottom-Up Syntax Analysis

Creating a Recursive Descent Parse Table

Syntax Analysis, VII The Canonical LR(1) Table Construction. Comp 412

Context free languages

Bottom-Up Syntax Analysis

EXAM. CS331 Compiler Design Spring Please read all instructions, including these, carefully

Compiler Design. Spring Syntactic Analysis. Sample Exercises and Solutions. Prof. Pedro C. Diniz

Syntax Analysis Part I

TAFL 1 (ECS-403) Unit- III. 3.1 Definition of CFG (Context Free Grammar) and problems. 3.2 Derivation. 3.3 Ambiguity in Grammar

INF5110 Compiler Construction

Syntax Analysis Part I

Type 3 languages. Type 2 languages. Regular grammars Finite automata. Regular expressions. Type 2 grammars. Deterministic Nondeterministic.

ΕΠΛ323 - Θεωρία και Πρακτική Μεταγλωττιστών. Lecture 7a Syntax Analysis Elias Athanasopoulos

Compilerconstructie. najaar Rudy van Vliet kamer 124 Snellius, tel rvvliet(at)liacs.

Syntax Analysis Part I. Position of a Parser in the Compiler Model. The Parser. Chapter 4

LR(1) Parsers Part II. Copyright 2010, Keith D. Cooper & Linda Torczon, all rights reserved.

LR(1) Parsers Part II. Copyright 2010, Keith D. Cooper & Linda Torczon, all rights reserved.

Bottom-up Analysis. Theorem: Proof: Let a grammar G be reduced and left-recursive, then G is not LL(k) for any k.

Compiling Techniques

Syntax Analysis, VII The Canonical LR(1) Table Construction. Comp 412 COMP 412 FALL Chapter 3 in EaC2e. source code. IR IR target.

Lecture VII Part 2: Syntactic Analysis Bottom-up Parsing: LR Parsing. Prof. Bodik CS Berkley University 1

Announcements. H6 posted 2 days ago (due on Tue) Midterm went well: Very nice curve. Average 65% High score 74/75

Bottom-Up Syntax Analysis

Introduction to Bottom-Up Parsing

Bottom-Up Syntax Analysis

Lecture 11 Context-Free Languages

Introduction to Bottom-Up Parsing

n Top-down parsing vs. bottom-up parsing n Top-down parsing n Introduction n A top-down depth-first parser (with backtracking)

CS415 Compilers Syntax Analysis Bottom-up Parsing

Introduction to Bottom-Up Parsing

60-354, Theory of Computation Fall Asish Mukhopadhyay School of Computer Science University of Windsor

Parsing Algorithms. CS 4447/CS Stephen Watt University of Western Ontario

Introduction to Bottom-Up Parsing

Top-Down Parsing and Intro to Bottom-Up Parsing

Talen en Compilers. Johan Jeuring , period 2. October 29, Department of Information and Computing Sciences Utrecht University

Curs 8. LR(k) parsing. S.Motogna - FL&CD

1. For the following sub-problems, consider the following context-free grammar: S AA$ (1) A xa (2) A B (3) B yb (4)

AC68 FINITE AUTOMATA & FORMULA LANGUAGES DEC 2013

CSE302: Compiler Design

Syntax Analysis, VI Examples from LR Parsing. Comp 412

An automaton with a finite number of states is called a Finite Automaton (FA) or Finite State Machine (FSM).

Context-free Grammars and Languages

Syntactic Analysis. Top-Down Parsing

Lecture 12 Simplification of Context-Free Grammars and Normal Forms

Everything You Always Wanted to Know About Parsing

Parsing. Left-Corner Parsing. Laura Kallmeyer. Winter 2017/18. Heinrich-Heine-Universität Düsseldorf 1 / 17

Context-Free Grammars and Languages

Syntax Analysis - Part 1. Syntax Analysis

Einführung in die Computerlinguistik

INF5110 Compiler Construction

CFG Simplification. (simplify) 1. Eliminate useless symbols 2. Eliminate -productions 3. Eliminate unit productions

CS415 Compilers Syntax Analysis Top-down Parsing

1. For the following sub-problems, consider the following context-free grammar: S AB$ (1) A xax (2) A B (3) B yby (5) B A (6)

1. (a) Explain the procedure to convert Context Free Grammar to Push Down Automata.

CS 314 Principles of Programming Languages

CS20a: summary (Oct 24, 2002)

Compiler Principles, PS4

GEETANJALI INSTITUTE OF TECHNICAL STUDIES, UDAIPUR I

1. Draw a parse tree for the following derivation: S C A C C A b b b b A b b b b B b b b b a A a a b b b b a b a a b b 2. Show on your parse tree u,

Chapter 1. Formal Definition and View. Lecture Formal Pushdown Automata on the 28th April 2009

Foreword. Grammatical inference. Examples of sequences. Sources. Example of problems expressed by sequences Switching the light

Concordia University Department of Computer Science & Software Engineering

Generalized Bottom Up Parsers With Reduced Stack Activity

Briefly on Bottom-up

Syntactical analysis. Syntactical analysis. Syntactical analysis. Syntactical analysis

FLAC Context-Free Grammars

download instant at Assume that (w R ) R = w for all strings w Σ of length n or less.

Pushdown Automata. Reading: Chapter 6

SLR(1) and LALR(1) Parsing for Unrestricted Grammars. Lawrence A. Harris

Theory of Computation - Module 3

LL conflict resolution using the embedded left LR parser

Context Free Languages (CFL) Language Recognizer A device that accepts valid strings. The FA are formalized types of language recognizer.

Transcription:

Compiler Design 1 LR Parsing

Compiler Design 2 LR(0) Parsing An LR(0) parser can take shift-reduce decisions entirely on the basis of the states of LR(0) automaton a of the grammar. Consider the following grammar and its augmented start symbol and the production rule. a The parsing table can be filled from the automaton.

Compiler Design 3 Example The production rules are, S asa bsb c The production rules of the augmented grammar are, S S$ S asa bsb c The states of the LR(0) automaton are the following:

Compiler Design 4 States q 0 : S S$ S asa S bsb S c q 1 : S S $ q 2 : S a Sa S asa S bsb S c q 3 : S b Sb S asa S bsb S c q 4 : S c

Compiler Design 5 States q 5 : S as a q 6 : S bs b q 7 : S asa q 8 : S bsb

Compiler Design 6 Complete and Incomplete Items An LR(0) item is called complete if the is at the right end of the production, A α. This indicates that the DFA has already seen a handle and it is on the top of the stack.

Compiler Design 7 LR(0) Grammar A grammar G is called LR(0) if the DFA of its viable prefixes has the following properties: no state has both complete and incomplete items, no state has two complete items.

Compiler Design 8 Note A state with a unique complete item A α, indicates a reduction of the handle α by the rule A α. A state with incomplete items indicates shift actions. The parsing table for the given grammar is as follows.

Compiler Design 9 Parsing table

Compiler Design 10 State Action Goto a b c $ S 0 s 2 s 3 s 4 1 1 accept 2 s 2 s 3 s 4 5 3 s 2 s 3 s 4 6 4 r 3 r 3 r 3 r 3 5 s 7 6 s 8 7 r 1 r 1 r 1 r 1 8 r 2 r 2 r 2 r 2

Compiler Design 11 Note The parser does not look-ahead for any shift operation. It gets the current state from the top-of-stack and the token from the scanner. Using the parsing table it gets the next state and pushes it in the stack a. The token is consumed. a It may push the token and its attributes in the value stack for semantic action.

Compiler Design 12 Note In case of LR(0) parser it does not look-ahead even for any reduce operation a. It gets the current state from the top-of-stack and the production rule number from the parsing table (for all correct input they are same), and reduces the right sentential form by the rule b. a It may read the input to detect error. Note the column corresponding to c for the states 4, 7, 8 with unique complete items. b The Goto portion of the table is used to push a new state on the stack after a reduction.

Compiler Design 13 Parsing Example Stack Input Handle Action $q 0 aabcbaa$ nil s 2 $q 0 q 2 abcbaa$ nil s 2 a $q 0 q 2 q 2 bcbaa$ nil s 3 $q 0 q 2 q 2 q 3 cbaa$ nil s 4 $q 0 q 2 q 2 q 3 q 4 baa$ S c r 3 a The length of c = 1, so q 4 is popped out and Goto(q 3,S) = q 6 is pushed in the stack.

Compiler Design 14 Parsing Example Stack Input Handle Action $q 0 q 2 q 2 q 3 q 4 baa$ S c r 3 $q 0 q 2 q 2 q 3 q 6 baa$ nil s 8 a $q 0 q 2 q 2 q 3 q 6 q 8 aa$ S bsb r 2 $q 0 q 2 q 2 q 5 aa$ nil s 7 $q 0 q 2 q 2 q 5 q 7 a$ S asa r 1 a The length of bsb = 3, so q 3 q 6 q 8 are popped out and Goto(q 2,S) = q 5 is pushed in the stack.

Compiler Design 15 Parsing Example Stack Input Handle Action $q 0 q 2 q 2 q 5 q 7 a$ S asa r 1 $q 0 q 2 q 5 a$ nil s 7 a $q 0 q 2 q 5 q 7 $ S asa r 1 $q 0 q 1 $ S S accept a The length of asa = 3, so q 2 q 5 q 7 are popped out and Goto(q 2,S) = q 5 is pushed in the stack. Similarly, Goto(q 0,S) = q 1 is pushed in the stack.

Compiler Design 16 SLR(1) Parsing

Compiler Design 17 We consider our old grammar (augmented with S ). 0 : S P 1 : P m L s e 2 : L D L 3 : L D 4 : D T V ; 5 : V d V 6 : V d 7 : T i 8 : T f

Compiler Design 18 States q 0 : S P P m L s e q 1 : S P q 2 : P m L s e L D L L D D T V ; T i T f q 3 : P m L s e q 4 : L D L L D L D L L D D T V ; T i T f

Compiler Design 19 States q 5 : D T V ; V d V V d q 6 : T i q 7 : T f q 8 : P m L s e q 9 : L D L q 10 : D T V ; q 11 : V d V V d V d V V d

Compiler Design 20 States q 12 : P m L s e q 13 : D T V ; q 14 : V d V

Compiler Design 21 Note In the LR(0) automaton of the grammar there are two states q 4 and q 11 with both complete and incomplete items. So the grammar is not of type LR(0).

Compiler Design 22 Note Consider the state q 4. The complete item is L D and the incomplete items are T i and T f. The Follow(L) = {s} is different from i,f. So we can put Action(4,i) = s 6, Action(4,f) = s 7 and Action(4,s) = r 3 (reduce by the production rule number 3) in the parsing table.

Compiler Design 23 SLR Parsing Table: Action If A α aβ q i (a Σ) and Goto(q i,a) = q j, then Action(i,a) = s j. If A α q i (A S ) and b Follow(A), then Action(i,b) = r k, where k is the rule number of A α. If S S q i, then Action(i,$) = accept.

Compiler Design 24 Note If the process does not lead to a table with multiple entries, the grammar is SLR (simple LR).

Compiler Design 25 SLR Parsing Table: Goto If A α Bβ q i (B N) and Goto(q i,b) = q j, then in the table Goto(i,B) = j. All other entries of the table are errors.

Compiler Design 26 FOLLOW() Sets Non-terminal Follow P $ L s D i,f,s T d V ;

Compiler Design 27 SLR Parsing Table S Action Goto m s e ; d i f $ P L D V T 0 s 2 1 1 A 2 s 6 s 7 3 4 5 3 s 8 4 r 3 s 6 s 7 9 4 5 5 s 11 10

Compiler Design 28 Example S Action Goto m s e ; d i f $ P L D V T 6 r 7 7 r 8 8 s 12 9 r 2 10 s 13 11 r 6 s 11 14

Compiler Design 29 Example S Action Goto m s e ; d i f $ P L D V T 12 r 1 13 r 4 r 4 r 4 14 r 5

Compiler Design 30 Non-SLR Grammar

Compiler Design 31 Consider the following grammar G rr (augmented by the S ). 0 : S S 1 : S E + T 2 : S T 3 : T i E 4 : T i 5 : E T

Compiler Design 32 States The states of the LR(0) automaton are as follows: q 0 : S S S E + T S T E T T i E T i q 1 : S S q 2 : S E + T q 3 : S T E T q 4 : T i E T i q 5 : S E + T T i E T i

Compiler Design 33 States q 6 : T i E T i q 7 : S E + T q 8 : T i E q 9 : E T E T T i E

Compiler Design 34 Note The state q 3 has two complete items S T and E T. When the automaton is in this state, there are two possible handles on the stack. The question is how to decide about the reduction rule. If Follow(S) Follow(E) =, then the choice can be made on the basis of the look-ahead symbol. But in this case Follow(S) = {$} and Follow(E) = {$, +}. The Action part of the SLR table corresponding to the row-q 3 and the column-$ will have two entries - the grammar is non-slr.

Compiler Design 35 Note In this example Action[q 3 ][$] = {r 2,r 5 }, the frontier can be reduced by rule 2 or by rule 5. This is known as reduce/reduce conflict of SLR table. We shall see how a more powerful parsing technique can be used to resolve this conflict. The information in the Follow() set is not sufficient to resolve this conflict.

Compiler Design 36 Consider the grammar G sr (augmented by the S ). 0 : S A 1 : A B a 2 : A C b 3 : A a C a 4 : C B 5 : B c A 6 : B b

Compiler Design 37 States Some of the states of the LR(0) automaton are as follows: q 0 : S A A B a A C b A a C a B c A B b C B q 1 : S A q 2 : A B a q 3 : A C b C B q 4 : A a C a C B

Compiler Design 38 States q 5 : B c A A B a A C b A a C a B c A B b C B q 6 : B b q 7 : A B a q 8 : q 9 :

Compiler Design 39 Note The state q 2 has one complete item, C B and one incomplete item, A B a. When the automaton is in this state, the parser is to decide whether to shift the input or to reduce. Unfortunately, the SLR parsing table will have two entries for Action[q 2 ][a] = {s 7,r 4 }, as a Follow(C). The grammar is non-slr and the problem is known as shift-reduce conflict of SLR parsing table. We shall see how a more powerful technique can be used to build a parsing table.

Compiler Design 40 Note If the state of an LR(0) automaton contains a complete item A α and the next input a FOLLOW(A), the action in the SLR table will be reduction of handle by the rule A α. But the set FOLLOW(A) is the super set of what can follow a particular viable prefix. In the grammar G rr, the viable prefix E cannot be followed by a $ and similarly the the viable prefix S cannot be followed by a +. So the reduce/reduce conflict of q 3 can be resolved by explicitly carrying the look-ahead information.

Compiler Design 41 Canonical LR(1) Item An object of the form (A α β,a), where A αβ is a production rule and a Σ {$}, is called an LR(1) item. The second component a is known as the look-ahead symbol. a The 1 in LR(1) refers to the second component of the item.

Compiler Design 42 Reduction The look-ahead symbol of an LR(1) item (A α β,a) is important when the item is complete i.e. β = ε. The reduction by the rule A α can take place if the look-ahead symbol is a. The look-ahead symbol a is an element of FOLLOW(A), but we carry it explicitly with the item.

Compiler Design 43 Valid Item An LR(1) item (A α β,a) is valid for a viable prefix uα, if there is a rightmost derivation: S uax uαβx, so that a FIRST(x) or if x = ε, then a = $.

Compiler Design 44 Closure() If i is an LR(1) item, then Closure(i) is defined as follows: i Closure(i) - basis, If (A α Bβ,a) Closure(i) and B γ is a production rule, then (B γ,b) Closure(i), where b FIRST(βa).

Compiler Design 45 Closure() The closure of I, a set of LR(1) items, is defined as Closure(I) = i I Closure(i).

Compiler Design 46 Goto(I, X) Let I be a set of LR(1) items and X Σ N. The set of LR(1) items Goto(I,X) is Closure({(A α X β,a) : (A α X β,a) I}).

Compiler Design 47 LR(1) Automaton The start state of the LR(1) automaton is Closure(S S,$). Other reachable and final states can be constructed by computing GOTO() of already existing states. This is a fixed-point computation.

Compiler Design 48 Consider the grammar G rr (augmented by the S ). 0 : S S 1 : S E + T 2 : S T 3 : T i E 4 : T i 5 : E T

Compiler Design 49 States The states of the LR(1) automaton are as follows: q 0 : S S,$ S E + T,$ S T,$ E T,+ T i E,+/$ T i,+/$ q 1 : S S,$ q 2 : S E + T,$ q 3 : S T,$ E T,+ q 4 : T i E,+/$ T i,+/$ q 5 : S E + T,$ T i E,$ T i,$

Compiler Design 50 States q 6 : T i E,+/$ E T,+/$ T i E,+/$ T i,+/$ q 7 : S E + T,$ q 8 : T i E,$ T i,$ q 9 : T i E,+/$ q 10 : E T,+/$ q 11 : T i E,$ E T,$ T i E,$ T i,$

Compiler Design 51 States q 12 : T i E,$ q 13 : E T,$

Compiler Design 52 Note Number of states of the LR(1) automaton are more than that of LR(0) automaton. Several states have the same core LR(0) items, but different look-ahead symbols - (q 4,q 8 ), (q 6,q 11 ), (q 9,q 12 ).

Compiler Design 53 LR(1) Parsing Table: Action If (A α aβ,b) q i (a Σ) and Goto(q i,a) = q j, then Action(i,a) = s j. If (A α,a) q i (A S ), then Action(i,a) = r k, where k is the rule number of A α. If (S S,$) q i, then Action(i,$) = accept.

Compiler Design 54 LR(1) Parsing Table: Goto If A α Bβ q i (B N) and Goto(q i,b) = q j, then in the table Goto(i,B) = j. All other entries of the table are errors.

Compiler Design 55 Note If the process constructs a table without multiple entries, the grammar is LR(1).

Compiler Design 56 LR(1) Parsing Table S Action Goto + i $ S E T 0 s 4 1 2 3 1 A 2 s 5 3 r 5 r 2 4 r 4 s 6 r 4 5 s 8 7 6 s 4 9 10

Compiler Design 57 LR(1) Parsing Table S Action Goto + i $ S E T 7 r 1 8 s 11 r 4 9 r 3 r 3 10 r 5 r 5 11 s 8 12 13 12 r 3 13 r 5

Compiler Design 58 Non-LR(1) Grammar 0 : S A 1 : A a A a 2 : A a Aa a b 3 : A a b

Compiler Design 59 States of LR(1) Automaton q 0 : S A,$ A aaa,$ A aaaab,$ A ab,$ q 1 : S A,$ q 2 : A a Aa,$ A a Aaab,$ A a b,$ A aaa,a A aaaab,a A ab,a q 3 : A aa a,$ A aa aab,$ q 4 : A ab,$ q 5 : A a Aa,a A a Aaab,a A a b,a A aaa,a A aaaab,a A ab,a

Compiler Design 60 States of LR(1) Automaton q 6 : A aaa,$ q 7 : A aa a,a q 8 : A ab,a q 9 A aaaa b,$ q 10 : A aaa,a q 11 A aaaab,$ A aaa ab,$ A aa aab,a aaa ab,a

Compiler Design 61 Note In state q 10, the shift/reduce conflict cannot be resolved and there will be multiple entries in Action(10,a) = {s i,r 1 }, where Goto(q 10,a) = q i. This can be resolved with 2-look-aheads

Compiler Design 62 States of LR(2) Automaton q 0 : S A,$ A aaa,$ A aaaab,$ A ab,$ q 1 : S A,$ q 2 : A a Aa,$ A a Aaab,$ A a b,$ A aaa,aa/a$ A aaaab,aa/a$ A ab,aa/a$ q 3 : A aa a,$ A aa aab,$ q 4 : A ab,$ q 5 : A a Aa,aa/a$ A a Aaab,aa/a$ A a b,aa/a$ A aaa,aa A aaaab,aa A ab,aa

Compiler Design 63 States of LR(2) Automaton q 6 : A aaa,$ A aaa ab,$ q 7 : A aa a,aa/a$ A aa aab,aa/a$ q 8 : A ab,aa/a$ q 9 A aaaa b,$ q 10 : A aaa,aa/a$ aaa ab,aa/a$ q 11 A aaaab,$

Compiler Design 64 Note In state q 10, the action is r 1 if the next two symbols are either aa or a$. The action is shift if they are ab. But we shall not use LR(2) parsing.

Compiler Design 65 LALR Parser We observed in connection to the LR(1) states of the grammar G rr, that there are pairs of states with the same core LR(0) items, but with different look-ahead symbols - (q 4,q 8 ), (q 6,q 11 ), (q 9,q 12 ). If we can merge states with same core of LR(0) items, we get a parsing table of lesser number of states or rows. For some LR(1) grammar this merging will not lead to multiple entries in the parsing table and the corresponding grammar is known as LALR (lookahead LR) grammar.

Compiler Design 66 Note Merging of two LR(1) states with the same the core cannot give rise to shift/reduce conflict, if it was not present in the original automaton. If there is a pair of items of the form {A α aβ, B γ,a} in the merged state, it originally was there is one of the LR(1) states. So the LR(1) automaton was not conflict free.

Compiler Design 67 Note Two states of an LALR parser cannot have the same set of LR(0) items. So, for a given grammar, the number of states of an SLR parser is same as the number of states of an LALR parser. An LALR parser uses a better heuristic about symbols that can follow a viable prefix, than the global FOLLOW() sets of non-terminals.

Compiler Design 68 LALR States The states of the LR(1) automaton are as follows: q 0 : S S,$ S E + T,$ S T,$ E T,+ T i E,+/$ T i,+/$ q 1 : S S,$ q 2 : S E + T,$ q 3 : S T,$ E T,+ q 4 8 : T i E,+/$ T i,+/$ q 5 : S E + T,$ T i E,$ T i,$

Compiler Design 69 States q 6 11 : T i E,+/$ E T,+/$ T i E,+/$ T i,+/$ q 7 : S E + T,$ q 9 12 : T i E,+/$ q 10 : E T,+/$ q 13 : E T,$

Compiler Design 70 LALR Parsing Table S Action Goto + i $ S E T 0 s 4 8 1 2 3 1 A 2 s 5 3 r 5 r 2 4 8 r 4 s 6 11 r 4 5 s 4 8 7 6 11 s 4 8 9 12 10

Compiler Design 71 LALR Parsing Table S Action Goto + i $ S E T 7 r 1 9 12 r 3 r 3 10 r 5 r 5 13 r 5

Compiler Design 72 LR(1) but not LALR Consider the grammar 0 : S A 1 : A a B a 2 : A b B b 3 : A a D b 4 : A b D a 5 : B c 6 : D c

Compiler Design 73 States of LR(1) Automaton q 0 : S A,$ A aba,$ A bbb,$ A adb,$ A bda,$ q 1 : A a Ba,$ A a Db,$ B c,a D c,b q 2 : A b Bb,$ A b Da,$ B c,b D c,a q 3 : A ab a,$ q 4 : A ad b,$

Compiler Design 74 States of LR(1) Automaton q 5 : B c,a q 6 : A bb b,$ q 7 : A bd a,$ q 8 : B c,b D c,b D c,a The states q 5 and q 8 have the same LR(0) core, but they cannot be merged to form a LALR state as that will lead to reduce/reduce conflicts. So the grammar is LR(1) but not LALR.

Compiler Design 75 Ambiguous Grammar & LR Parsing An ambiguous grammar cannot be LR. But for some ambiguous grammars a it is possible to use LR parsing techniques efficiently with the help of some extra grammatical information such as operator associativity, precedence etc. a As an example for operator-precedence grammars: CFG with no ε production and no production rule with two non-terminals coming side by side.

Compiler Design 76 Example Consider the expression grammar G a 0 : S E 1 : E E E 2 : E E E 3 : E (E) 4 : E E 5 : E i Note that the terminal - is used both as binary as well as unary operator.

Compiler Design 77 States of LR(0) Automaton q 0 : S E E E E E E E E (E) E E E i q 1 : S E E E E E E E q 2 : E ( E) E E E E E E E (E) E E E i q 3 : E E E E E E E E E (E) E E E i q 4 : E i

Compiler Design 78 States of LR(0) Automaton q 5 : E E E E E E E E E E (E) E E E i q 6 : E E E E E E E E E E (E) E E E i q 7 : E (E ) E E E E E E q 8 : E E E E E E E E q 9 : E E E E E E E E E q 10 : E E E E E E E E E There are a few more states.

Compiler Design 79 Note The states q 8, q 9 and q 10 have complete and incomplete items. FOLLOW(E) = {$,,,)} cannot resolve the conflict. In fact no amount of look-ahead can help - the LR(1) initial state is q 0 : S E,$ E (E),$/ / E E,$/ / E E E,$/ / E E E,$/ / E i,$/ /

Compiler Design 80 q 8 : E E, E E E, E E E The higher precedence of unary over the binary and binary will help to resolve the conflict. The parser reduces the handle i.e. Action(8, ) = Action(8, ) = Action(8,)) = Action(8,$) = r 4.

Compiler Design 81 q 9 : E E E, E E E, E E E In this case if the look-ahead symbol is a (it must be binary), the parser reduces due to the left associativity of binary. But if the look-ahead symbol is a, the parser shifts i.e. Action(9, ) = Action(9,)) = Action(9,$) = r 4 but Action(9, ) = s 6.

Compiler Design 82 q 10 : E E E, E E E, E E E Actions are always reduce.