CSX-lite Example. LL(1) Parse Tables. LL(1) Parser Driver. Example of LL(1) Parsing. An LL(1) parse table, T, is a twodimensional

Similar documents
Table-Driven Top-Down Parsers

How do LL(1) Parsers Build Syntax Trees?

Building A Recursive Descent Parser. Example: CSX-Lite. match terminals, and calling parsing procedures to match nonterminals.

LL(1) Grammars. Example. Recursive Descent Parsers. S A a {b,d,a} A B D {b, d, a} B b { b } B λ {d, a} D d { d } D λ { a }

Configuration Sets for CSX- Lite. Parser Action Table

Action Table for CSX-Lite. LALR Parser Driver. Example of LALR(1) Parsing. GoTo Table for CSX-Lite

Error Detection in LALR Parsers. LALR is More Powerful. { b + c = a; } Eof. Expr Expr + id Expr id we can first match an id:

A programming language requires two major definitions A simple one pass compiler

CSCI312 Principles of Programming Languages

CS 314 Principles of Programming Languages

Building Compilers with Phoenix

Syntax Analysis Part I

Section A. A grammar that produces more than one parse tree for some sentences is said to be ambiguous.

Sometimes an ambiguous grammar can be rewritten to eliminate the ambiguity.

Syntax Analysis Check syntax and construct abstract syntax tree

Syntax Analysis. Martin Sulzmann. Martin Sulzmann Syntax Analysis 1 / 38

Types of parsing. CMSC 430 Lecture 4, Page 1

CS1622. Today. A Recursive Descent Parser. Preliminaries. Lecture 9 Parsing (4)

Top down vs. bottom up parsing

CS 4120 Introduction to Compilers

Context-free grammars

Compilerconstructie. najaar Rudy van Vliet kamer 140 Snellius, tel rvvliet(at)liacs(dot)nl. college 3, vrijdag 22 september 2017

Monday, September 13, Parsers

CA Compiler Construction

Compiler Construction: Parsing

Parsing Techniques. CS152. Chris Pollett. Sep. 24, 2008.

Wednesday, September 9, 15. Parsers

Parsers. What is a parser. Languages. Agenda. Terminology. Languages. A parser has two jobs:

Defining syntax using CFGs

Parsing III. (Top-down parsing: recursive descent & LL(1) )

Chapter 4: Syntax Analyzer

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

3. Syntax Analysis. Andrea Polini. Formal Languages and Compilers Master in Computer Science University of Camerino

Parsers. Xiaokang Qiu Purdue University. August 31, 2018 ECE 468

Compiler Construction 2016/2017 Syntax Analysis

Abstract Syntax Trees & Top-Down Parsing

Abstract Syntax Trees & Top-Down Parsing

Syntactic Analysis. Top-Down Parsing

PART 3 - SYNTAX ANALYSIS. F. Wotawa TU Graz) Compiler Construction Summer term / 309

Wednesday, August 31, Parsers

8 Parsing. Parsing. Top Down Parsing Methods. Parsing complexity. Top down vs. bottom up parsing. Top down vs. bottom up parsing

Chapter 3. Parsing #1

Bottom Up Parsing. Shift and Reduce. Sentential Form. Handle. Parse Tree. Bottom Up Parsing 9/26/2012. Also known as Shift-Reduce parsing

Parser Generation. Bottom-Up Parsing. Constructing LR Parser. LR Parsing. Construct parse tree bottom-up --- from leaves to the root

Parsing. Roadmap. > Context-free grammars > Derivations and precedence > Top-down parsing > Left-recursion > Look-ahead > Table-driven parsing

LL(k) Parsing. Predictive Parsers. LL(k) Parser Structure. Sample Parse Table. LL(1) Parsing Algorithm. Push RHS in Reverse Order 10/17/2012

CS 406/534 Compiler Construction Parsing Part I

Chapter 4: LR Parsing

Compilers. Yannis Smaragdakis, U. Athens (original slides by Sam

Parsing Part II. (Ambiguity, Top-down parsing, Left-recursion Removal)

Context-Free Grammar. Concepts Introduced in Chapter 2. Parse Trees. Example Grammar and Derivation

Alternatives for semantic processing

Abstract Syntax Trees & Top-Down Parsing

Administrativia. WA1 due on Thu PA2 in a week. Building a Parser III. Slides on the web site. CS164 3:30-5:00 TT 10 Evans.


Parsing Part II (Top-down parsing, left-recursion removal)

Chapter 4. Lexical and Syntax Analysis

Formal Languages and Compilers Lecture VII Part 3: Syntactic A

Optimizing Finite Automata

Syntax Analysis. Amitabha Sanyal. ( as) Department of Computer Science and Engineering, Indian Institute of Technology, Bombay

The procedure attempts to "match" the right hand side of some production for a nonterminal.

CS 536 Midterm Exam Spring 2013

Question Points Score

Building a Parser III. CS164 3:30-5:00 TT 10 Evans. Prof. Bodik CS 164 Lecture 6 1

LR Parsing - The Items

UNIT-III BOTTOM-UP PARSING

Properties of Regular Expressions and Finite Automata

4. Lexical and Syntax Analysis

3. Parsing. Oscar Nierstrasz

1 Introduction. 2 Recursive descent parsing. Predicative parsing. Computer Language Implementation Lecture Note 3 February 4, 2004

EDAN65: Compilers, Lecture 06 A LR parsing. Görel Hedin Revised:

Let s look at the CUP specification for CSX-lite. Recall its CFG is

4. Lexical and Syntax Analysis

Syntactic Analysis. Top-Down Parsing. Parsing Techniques. Top-Down Parsing. Remember the Expression Grammar? Example. Example

Some Basic Definitions. Some Basic Definitions. Some Basic Definitions. Language Processing Systems. Syntax Analysis (Parsing) Prof.

Ambiguity, Precedence, Associativity & Top-Down Parsing. Lecture 9-10

Lexical and Syntax Analysis

A left-sentential form is a sentential form that occurs in the leftmost derivation of some sentence.

A parser is some system capable of constructing the derivation of any sentence in some language L(G) based on a grammar G.

Syntax Analysis. Prof. James L. Frankel Harvard University. Version of 6:43 PM 6-Feb-2018 Copyright 2018, 2015 James L. Frankel. All rights reserved.

Note that for recursive descent to work, if A ::= B1 B2 is a grammar rule we need First k (B1) disjoint from First k (B2).

Compiler construction in4303 lecture 3

Outline CS412/413. Administrivia. Review. Grammars. Left vs. Right Recursion. More tips forll(1) grammars Bottom-up parsing LR(0) parser construction

Assignment 4 CSE 517: Natural Language Processing

CS415 Compilers. Syntax Analysis. These slides are based on slides copyrighted by Keith Cooper, Ken Kennedy & Linda Torczon at Rice University

Parsing III. CS434 Lecture 8 Spring 2005 Department of Computer Science University of Alabama Joel Jones

More on Syntax. Agenda for the Day. Administrative Stuff. More on Syntax In-Class Exercise Using parse trees

Defining syntax using CFGs

Midterm Exam. CSCI 3136: Principles of Programming Languages. February 20, Group 2

Compiler Design Concepts. Syntax Analysis

Review main idea syntax-directed evaluation and translation. Recall syntax-directed interpretation in recursive descent parsers

COP4020 Programming Languages. Syntax Prof. Robert van Engelen

Lexical and Syntax Analysis (2)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Introduction to Syntax Analysis

Concepts Introduced in Chapter 4

4 (c) parsing. Parsing. Top down vs. bo5om up parsing

Syntax Analysis: Context-free Grammars, Pushdown Automata and Parsing Part - 4. Y.N. Srikant

Lecture 14: Parser Conflicts, Using Ambiguity, Error Recovery. Last modified: Mon Feb 23 10:05: CS164: Lecture #14 1

CSCI312 Principles of Programming Languages!

Transcription:

LL(1) Parse Tables CSX-lite Example An LL(1) parse table, T, is a twodimensional array. Entries in T are production numbers or blank (error) entries. T is indexed by: A, a non-terminal. A is the nonterminal we want to expand. CT, the current token that is to be matched. Production Predict Set 1 Prog { { 2 Stmt if 3 λ 4 Stmt 5 Stmt if ( ) Stmt if 6 7 + + 8 - - 9 λ ) T[A][CT] A X 1...X n if CT is in Predict(A X 1...X n ) T[A][CT] error if CT predicts no production with A as its lefthand se { if ( ) + - eof Prog 1 3 2 2 Stmt 5 4 6 9 7 8 9 279 280 LL(1) Parser Driver Example of LL(1) Parsing Here is the driver we ll use with the LL(1) parse table. We ll also use a parse stack that remembers symbols we have yet to match. We ll again parse We start by placing Prog (the start symbol) on the parse stack. vo LLDriver(){ Push(StartSymbol) while(! stackempty()){ //Let XTop symbol on parse stack //Let CT current token to match if (isterminal(x)) { match(x) //CT is updated pop() //X is updated else if (T[X][CT]! Error){ //Let T[X][CT] X Y 1...Y m Replace X with Y 1...Y m on parse stack else SyntaxError(CT) Prog { Stmt a b + c a b + c 281 282

a b + c b + c b + c b + c + + c + c c c 283 284 Done! All input matched Syntax Errors in LL(1) Parsing In LL(1) parsing, syntax errors are automatically detected as soon as the first illegal token is seen. How? When an illegal token is seen by the parser, either it fetches an error entry from the LL(1) parse table or it fails to match an expected token. Let s see how the following illegal CSX-lite program is parsed: { b + c a (Where should the first syntax error be detected?) 285 286

Prog { { b + c a { b + c a b + c a Current token (+) fails to match expected token ()! + c a + c a Stmt b + c a b + c a 287 288 How do LL(1) Parsers Build Syntax Trees? whose children are the n items just popped off. So far our LL(1) parser has acted like a recognizer. It verifies that input token are syntactically correct, but it produces no output. Building complete (concrete) parse trees automatically is fairly easy. As tokens and non-terminals are matched, they are pushed onto a second stack, the semantic stack. At the end of each production, an action routine pops off n items from the semantic stack (where n is the length of the production s righthand se). It then builds a syntax tree whose root is the lefthand se, and for production Stmt the parser would include an action symbol after the whose actions are: P4 pop() // Semicolon token P3 pop(): // Syntax tree for P2 pop() // Assignment token P1 pop() // Identifier token Push(new StmtNode(P1,P2,P3,P4)) 289 290

Creating Abstract Syntax Trees How do We Make Grammars LL(1)? Recall that we prefer that parsers generate abstract syntax trees, since they are simpler and more concise. Since a parser generator can t know what tree structure we want to keep, we must allow the user to define custom action code, just as Java CUP does. We allow users to include code snippets in Java or C. We also allow labels on symbols so that we can refer to the tokens and tress we wish to access. Our production and action code will now look like this: Stmt :i :e Not all grammars are LL(1) sometimes we need to modify a grammar s productions to create the disjoint Predict sets LL1) requires. There are two common problems in grammars that make unique prediction difficult or impossible: 1. Common prefixes. Two or more productions with the same lefthand se begin with the same symbol(s). Stmt Stmt ( Args ) {: RESULT new StmtNode(i,e) : 291 292 2. Left-Recursion A production of the form A A... is sa to be left-recursive. When a left-recursive production is used, a non-terminal is immediately replaced by itself (with additional symbols following). Any grammar with a left-recursive production can never be LL(1). Why? Assume a non-terminal A reaches the top of the parse stack, with CT as the current token. The LL(1) parse table entry, T[A][CT], predicts A A... We expand A again, and T[A][CT], so we predict A A... again. We are in an infinite prediction loop! Eliminating Common Prefixes Assume we have two of more productions with the same lefthand se and a common prefix on their righthand ses: A α β α γ... α δ We create a new non-terminal, X. We then rewrite the above productions into: A αx X β γ... δ Stmt Stmt ( Args ) becomes Stmt StmtSuffix StmtSuffix StmtSuffix ( Args ) 293 294

Eliminating Left Recursion Assume we have a non-terminal that is left recursive: A Aα A β γ... δ To eliminate the left recursion, we create two new non-terminals, N and T. We then rewrite the above productions into: A N T N β γ... δ T α T λ + becomes N T N T + T λ This simplifies to: T T + T λ 295 296