Administrativia. Extra credit for bugs in project assignments. Building a Scanner. CS164, Fall Recall: The Structure of a Compiler

Similar documents
Administrivia. Lexical Analysis. Lecture 2-4. Outline. The Structure of a Compiler. Informal sketch of lexical analysis. Issues in lexical analysis

Implementation of Lexical Analysis

Implementation of Lexical Analysis

Lexical Analysis. Chapter 2

Implementation of Lexical Analysis

Lexical Analysis. Lecture 2-4

Lexical Analysis. Lecture 3-4

Introduction to Lexical Analysis

Implementation of Lexical Analysis

Implementation of Lexical Analysis

CS Lecture 2. The Front End. Lecture 2 Lexical Analysis

Implementation of Lexical Analysis

Implementation of Lexical Analysis. Lecture 4

Lexical Analysis. Implementation: Finite Automata

Introduction to Lexical Analysis

CS164: Programming Assignment 2 Dlex Lexer Generator and Decaf Lexer

Compiler course. Chapter 3 Lexical Analysis

Chapter 3 Lexical Analysis

Syntactic Analysis. CS345H: Programming Languages. Lecture 3: Lexical Analysis. Outline. Lexical Analysis. What is a Token? Tokens

Lexical Analysis. Finite Automata. (Part 2 of 2)

Lexical Analysis. Lecture 3. January 10, 2018

Formal Languages and Compilers Lecture VI: Lexical Analysis

Lexical Analysis. Dragon Book Chapter 3 Formal Languages Regular Expressions Finite Automata Theory Lexical Analysis using Automata

CSE450. Translation of Programming Languages. Lecture 20: Automata and Regular Expressions

Kinder, Gentler Nation

Lexical Analysis. Finite Automata

Lexical Analysis. Finite Automata

Structure of Programming Languages Lecture 3

Compiler Construction D7011E

Announcements! P1 part 1 due next Tuesday P1 part 2 due next Friday

Compiler Construction LECTURE # 3

CSC 467 Lecture 3: Regular Expressions

CS412/413. Introduction to Compilers Tim Teitelbaum. Lecture 2: Lexical Analysis 23 Jan 08

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

Lexical Analysis. Introduction

CS321 Languages and Compiler Design I. Winter 2012 Lecture 4

CSEP 501 Compilers. Languages, Automata, Regular Expressions & Scanners Hal Perkins Winter /8/ Hal Perkins & UW CSE B-1

Cunning Plan. Informal Sketch of Lexical Analysis. Issues in Lexical Analysis. Specifying Lexers

CS164: Midterm I. Fall 2003

Lexical Analysis. Lexical analysis is the first phase of compilation: The file is converted from ASCII to tokens. It must be fast!

Compiler phases. Non-tokens

Last lecture CMSC330. This lecture. Finite Automata: States. Finite Automata. Implementing Regular Expressions. Languages. Regular expressions

Formal Languages and Compilers Lecture IV: Regular Languages and Finite. Finite Automata

CMSC 350: COMPILER DESIGN

Regular Expressions. Agenda for Today. Grammar for a Tiny Language. Programming Language Specifications

UNIT -2 LEXICAL ANALYSIS

CSCI312 Principles of Programming Languages!

Scanners. Xiaokang Qiu Purdue University. August 24, ECE 468 Adapted from Kulkarni 2012

Week 2: Syntax Specification, Grammars

CS 536 Introduction to Programming Languages and Compilers Charles N. Fischer Lecture 5

Monday, August 26, 13. Scanners

Computer Science Department Carlos III University of Madrid Leganés (Spain) David Griol Barres

Wednesday, September 3, 14. Scanners

Concepts Introduced in Chapter 3. Lexical Analysis. Lexical Analysis Terms. Attributes for Tokens

Chapter 3: Lexing and Parsing

Chapter 4. Lexical analysis. Concepts. Lexical scanning Regular expressions DFAs and FSAs Lex. Lexical analysis in perspective

CSE 413 Programming Languages & Implementation. Hal Perkins Autumn 2012 Grammars, Scanners & Regular Expressions

Lexical Error Recovery

Defining Program Syntax. Chapter Two Modern Programming Languages, 2nd ed. 1

CSE450. Translation of Programming Languages. Automata, Simple Language Design Principles

Compiler Construction

Zhizheng Zhang. Southeast University

David Griol Barres Computer Science Department Carlos III University of Madrid Leganés (Spain)

Languages, Automata, Regular Expressions & Scanners. Winter /8/ Hal Perkins & UW CSE B-1

Lexical Analyzer Scanner

Lecture 3: Lexical Analysis

Lexical Analyzer Scanner

CSE 401 Midterm Exam Sample Solution 2/11/15

Figure 2.1: Role of Lexical Analyzer

1 Lexical Considerations

The Front End. The purpose of the front end is to deal with the input language. Perform a membership test: code source language?

CS308 Compiler Principles Lexical Analyzer Li Jiang

CS415 Compilers. Lexical Analysis

for (i=1; i<=100000; i++) { x = sqrt (y); // square root function cout << x+i << endl; }

Lexical Error Recovery

Concepts. Lexical scanning Regular expressions DFAs and FSAs Lex. Lexical analysis in perspective

CSc 453 Lexical Analysis (Scanning)

Part 5 Program Analysis Principles and Techniques

Semantic Analysis. Lecture 9. February 7, 2018

Programming Languages 2nd edition Tucker and Noonan"

CSE 413 Programming Languages & Implementation. Hal Perkins Winter 2019 Grammars, Scanners & Regular Expressions

Outline. 1 Scanning Tokens. 2 Regular Expresssions. 3 Finite State Automata

Lexical and Syntax Analysis

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Compiler Design

CSc 453 Compilers and Systems Software

Lexical Analysis 1 / 52

Compiler Construction

Programming Assignment I Due Thursday, October 7, 2010 at 11:59pm

1. Lexical Analysis Phase

Architecture of Compilers, Interpreters. CMSC 330: Organization of Programming Languages. Front End Scanner and Parser. Implementing the Front End

Lecture 9 CIS 341: COMPILERS

CS 314 Principles of Programming Languages

CSE 3302 Programming Languages Lecture 2: Syntax

10/4/18. Lexical and Syntactic Analysis. Lexical and Syntax Analysis. Tokenizing Source. Scanner. Reasons to Separate Lexical and Syntactic Analysis

programming languages need to be precise a regular expression is one of the following: tokens are the building blocks of programs

Introduction to Lexing and Parsing

LECTURE 6 Scanning Part 2

CS 314 Principles of Programming Languages. Lecture 3

A simple syntax-directed

Prof. Mohamed Hamada Software Engineering Lab. The University of Aizu Japan

Transcription:

dministrativia Building a canner Extra credit for bugs in project assignments in starter kits and handouts Ts are final arbiters of what s a bug only the first student to report the bug gets credit C64, Fall 24 2 Recall: The tructure of a Compiler What does a lexer do? Decaf program (stream of characters) scanner stream of tokens parser bstract yntax Tree (T) checker code gen T with annotations (types, declarations) maybe x86 4 Recall: Lexical nalysis Continued The input is just a sequence of characters. Example: if (i == j) z = ; else z = ; More accurately, the input is string: \tif (i == j)\n\t\tz = ;\n\telse\n\t\tz = ; Goal: find lexemes and map them to tokens:. partition input string into substrings (called lexemes), and 2. classify them according to their role (role = token) 5 Lexer input: \tif(i==j)\n\t\tz = ;\n\telse\n\t\tz = ; partitioned into these lexemes: \t if ( i == j ) \n\t\t z = ; \n\t else \n\t\t z = ; mapped to a sequence of tokens IF, LPR, ID( i ), EQUL, ID( j ) Notes: whitespace lexemes are dropped, not mapped to tokens is this the same fatal mistake as in FORTRN? (see Lecture ) some tokens have attributes: the lexeme and/or line number why do we need them? 6

What s a Token? token is a syntactic category In English: noun, verb, adjective, In a programming language: Identifier, Integer, Keyword, Whitespace, Parser relies on the token distinctions: identifiers are treated differently than keywords but all identifiers are treated the same, regardless of what lexeme created them What are lexemes? Webster: items in the vocabulary of a language cs64: same: items in the vocabulary of a language: numbers, keywords, identifiers, operators, etc. strings into which the input string is partitioned. 7 8 Writing the lexer Not by hand tedious, repetitious, error-prone, non-maintainable How to build a scanner for Decaf? Instead, we ll build a lexer generator once we have the generator, we ll only describe the lexemes and their tokens that is, provide Decaf s lexical specification (the What) and generate code that performs the partitioning generated code hides repeated code (the How) Code generator: key benefit Imperative scanner (in Java) The scanner generator allows the programmer to focus on: Whatthe lexer should do, rather than How it should be done. what: declarative programming how: imperative programming Let s first build the scanner in Java, by hand: to see how it is done, and where s the repetitious code that we want to hide simple scanner will do. Only four tokens: TOKEN ID EQUL PLU TIME Lexeme a sequence of one or more letters or digits starting with a letter == * 2 2

Imperative scanner if (c == = ) { if (c == = ) {return EQUL;}} } Imperative scanner You could write your entire scanner in this style and for small scanners this style is appropriate This code looks simple and clean, but try to add tokens that start with the same string: if and iffy C-style comments: /* anything here /* nested comments */ */ string literals with escape sequences: \t \ error handling, e.g., badly formed strings (see P2) Look at treamtokenizer.nexttoken() for an example of real imperative scanner in Eclipse, type Ctrl+hift+T. Enter treamtokenizer. Press F4. In the Hierarchy view, select method nexttoken. 3 4 Maximal munch rule Imperative Lexer: what vs. how What is the need for undonextchar()? it performs look-ahead, to determine whether the ID lexeme can be grown further This is an example of maximal much rule: this rule followed by all scanners the rule: the input character stream is partitioned into lexemes that are as large as possible Ex.: in Java, iffy is not partitioned into if (the IF keyword) and fy (ID), but into iffy (ID) if (c == = ) { if (c == = ) {return EQUL;}} } little logic, much plumbing 5 6 Identifying the plumbing (the how) Identifying the plumbing (the how) if (c == = ) { if (c == = ) {return EQUL;}} } characters read always the same way if (c == = ) { if (c == = ) {return EQUL;}} } tokens are always return-ed 7 8 3

Identifying the plumbing (the how) Identifying the plumbing (the how) if (c == = ) { if (c == = ) {return EQUL;}} } the lookahead is explicit if (c == = ) { if (c == = ) {return EQUL;}} } must build decision tree out of nested if s (yuck!) 9 2 Can we hide the plumbing? eparate out the how (plumbing) That is, can we avoid having to spell out the details of calls to the input method? write the return in front of tokens? code the look-ahead code explicitly? use if s and while s to indicate the decision tree? In short, can we make the code look like the specification table? TOKEN ID EQUL PLU TIME Lexeme a sequence of one or more letters or digits starting with a letter == * 2 The code actually follows a simple pattern: read next character and compare it with some predetermined character if there is a match, jump to a different line of code repeat this until you return a token. Is there a programming language that can encode this concisely? yes, finite automata! line of code read, compare line of code read, compare return a token 22 eparate out the what declarative scanner if (c == = ) { if (c == = ) {return EQUL;}} } Part : declarative (the what) describe each token as a finite automaton must be supplied for each scanner, of course (it specifies the lexical properties of the input language) Part 2: imperative (the how) connect these automata into a scanner automaton common to all scanners (like a library) responsible for the mechanics of scanning 23 24 4

Deterministic finite automata (DF) DFs We ll use DF s as recognizers: given an input string, the DF will recognize whether the string is a valid lexeme recognize means answer true or false Example: Is xyz an identifier? The DF will says yes. DF s alone insufficient to build a scanner: DF s recognize if a string is, say, an identifier but alone can t partition the input program into lexemes so we ll need to use them in a special way 26 Deterministic Finite utomata Example: Integer Literals Example: Decaf Identifiers sequences of one or more letters or underscores or digits, starting with a letter or underscore: letter _ letter _ digit 27 DF that accepts integer literals with an optional + or - sign: digit + - B digit digit 28 nd another (more abstract) example lphabet {,} What strings does this recognize? Finite-utomata tate Graphs state The start state final state transition a 29 3 5

Finite utomata Transition s a s 2 Is read In state s on input a go to state s 2 If end of input If in accepting state => accept Otherwise => reject If no transition possible (got stuck) => reject Formal Definition finite automaton is a 5-tuple (Σ, Q,, q, F) where: n input alphabet Σ set of states Q start state q set of final states F Q is the state transition function: Q x Σ Q (i.e., encodes transitions state input state) 3 32 Language defined by DF The language defined by a DF is the set of strings accepted by the DF. in the language of the identifier DF shown above: x, tmp2, XyZzy, position27. the declarative scanner not in the language of the identifier DF shown above: 23, a?, 3apples. 33 Part : create a DF for each token Part 2: allow actions on DF transitions ID: PLU: TIME: letter * letter digit the action can be one of "put back one character" or "return token XYZ", such DF is called a transducer it translates input string to an output string EQUL: 35 36 6

tep 2: example of extending a DF The DF recognizing identifiers is modified to: letter digit any char except letter letter or digit action: put back char return ID Look-ahead is added for lexemes of variable length in our case, only ID needs lookahead note on action return ID resets the scanner back into start state (recall that scanner is called by parser; each time, one token is returned) 37 tep 2: Combine the extended DF s F 4 F 3 return PLU * letter return TIME ID return EQUL The algorithm: merge start nodes of the DF s. letter digit F put back char; return ID any char except letter or digit 38 F 3 Towards a realistic scanner Correct scanner Building a scanner out of DF s (as shown) is simple but doesn t quite work Consider a fifth token type, for the assignment operator TOKEN ID EQUL IGN PLU Lexeme a sequence of one or more letters or digits starting with a letter == F 4 F 3 return PLU * return TIME return EQUL letter letter digit ID put back char; return ID any char except letter or digit any char except put back char; return IGN F 3 TIME * 39 F 4 But above algorithm produces F 3 F 4 return PLU * return TIME letter letter digit return IGN put back char; return ID any char except letter or digit F 3 NFs return EQUL Bad: not a DF DF F should perform look-ahead Fix Fix it it with with NF s! 4 7

Deterministic vs. Nondeterministic utomata Deterministic Finite utomata (DF) one transition per input characater per state no -moves Nondeterministic Finite utomata (NF) allows multiple outgoing transitions for one input can have -moves Both: finite automata have finite memory Need only to encode the current state NF s can be in multiple states at once (stay tuned) simple NF example lphabet: {, } The operation of the automaton is not completely defined by the input On input the automaton could be in either state 43 44 Epsilon Moves nother kind of transition: -moves B Machine can move from state to state B without reading input Execution of Finite utomata DF can take only one path through the state graph Completely determined by input NFs can choose whether to make -moves which of multiple transitions for a single input to take so we think of an NF as being in one of multiple states (see next example) 45 46 cceptance of NFs NF vs. DF () n NF can get into multiple states Input: Rule: NF accepts if it can get in a final state 47 NF s and DF s are equally powerful each NF can be translated into a corresponding DF (one that recognizes same strings) formally, NFs and DFs recognize the same set of languages (called regular languages) But NF s are more convenient they allow easy merges of automata, which helps in scanner construction nd DFs are easier to implement There are no choices to consider in P2, you will use NF s we ll give you NF recognizer code 48 8

NF vs. DF (2) For a given language the NF can be simpler than the DF NF DF DF can be exponentially larger than NF full declarative scanner 49 The algorithm With NF s, we can develop the scanner:. Construct an automaton for each lexeme (as before) 2. Merge them into the scanner automaton (as before) 3. Don t extend the automata as before, instead whenever you reach a final state: remember position in input (so that you can undo reads) keep reading more characters, moving to other states whenever you get stuck (cannot make a move on next char): return to the last final state (i.e., undo the reads) return the token associated with this final state Notes Notice that reading past final state implements look-ahead This look-ahead is unbounded can return any number of characters Can you think of two lexemes that will require the scanner to return a large amount of characters? large means we can write an input that will make the necessary look-ahead arbitrarily large. 5 52 Practical concerns We have a full declarative scanner mbiguity problem: scanner may reach multiple final states at once ex.: if matches both ID and IF (the keyword) solution: prioritize tokens (IF wins over ID) Discarding whitespace solution: final state for white-space lexeme is special: don t return a token, but jump to (common) start state Error inputs problem: discard illegal lexemes and print an error message simple solution (discard char by char): add a lexeme that matches any character, giving it lowest priority; it will match when no other will imperative part, stored in the library (the third step of the algorithm) this is the run-time: it performs look-ahead, moves, input matching, returning tokens declarative part think of it as configuring the run-time of the scanner configuration done by specifying an automaton for each token 53 54 9

Programming the declarative scanner configuring the run-time can be done by hand This code creates a DF for the EQUL token: Node start = new Node(), middle = new Node(); Node final = new FinalNode(EQUL); start.addedge(middle, = ); middle.addedge(final, = ); this is an improvement over the imperative scanner more readable, maintainable, les error-prone but our goal is to avoid writing even this, we ll write a code generator it will translate regular expressions (our textual program) into NF s regular expressions 55 Regular Expressions Example: Pascal identifier utomaton is a good visual aid but is not suitable as a specification (its textual description is too clumsy) regular expressions are a suitable specification a compact way to define a language that can be accepted by an automaton. used as the input to a scanner generator define each token, and also define white-space, comments, etc these do not correspond to tokens, but must be recognized and ignored. Lexical specification (in English): a letter, followed by zero or more letters or digits. Lexical specification (as a regular expression): letter. (letter digit)* means "or". means "followed by" * means zero or more instances of () are used for grouping 57 58 Operands of a regular expression Precedence of. * operators. Operands are same as labels on the edges of an FM single characters, or the special character (the empty string) "letter" is a shorthand for a b c... z... Z "digit is a shorthand for 9 sometimes we put the characters in quotes necessary when denoting. * Regular Expression Operator. * nalogous rithmetic Operator plus times exponentiation Consider regular expressions: letter.letter digit* letter.(letter digit)* Precedence lowest middle highest 59 6

More examples Describe (in English) the language defined by each of the following regular expressions: letter (letter digit*) digit digit* "." digit digit* Example: Integer Literals n integer literal with an optional sign can be defined in English as: (nothing or + or -) followed by one or more digits The corresponding regular expression is: (+ - ).(digit.digit*) new convenient operator + same precedence as * digit.digit* is the same as digit+ which means "one or more digits" 6 62 Language Defined by a Regular Expression Translating RE to NF s Recall: language = set of strings Language defined by an automaton the set of strings accepted by the automaton Launguage defined by a regular expression the set of strings that match the expression. Regular Exp. Corresponding et of trings {""} a {"a"} a.b.c {"abc"} a b c {"a", "b", "c"} (a b c)* {"", "a", "b", "c", "aa", "ab",..., "bccabb"...} key idea: find hierarchy in the regular expression find nested RE s define translation for individual operation compose the translations of nested RE s RE s as T translation via T traversal 63 64 Regular Expressions to NF () Regular Expressions to NF (2) For each kind of rexp, define an NF Notation: NF for rexp M For. B B For For input a M a For B B 65 66

Regular Expressions to NF (3) Example of RegExp -> NF conversion For * Consider the regular expression ( )* The NF is B C D E F G H I J 67 68 utomatically translating RE s to NF s we need an T that represents the RE the translation is then a bottom up traversal of the T like in Java pretty printing options: properly, you write T designed for RE operators and a parser from RE syntax to the RE T in P2, we ll reuse Java syntax and Java T overload Java operators it s a hack, but it allows us to implement the RE-NF translation quickly odds and ends 69 Practical issues P2, we ll use NFs But DFs are often faster because they can be implemented with tables Next few slides NF to DF conversion table implementation of DF s Feel free to implement these two in P2 experiment with how much faster your scanner is than the NF-based scanner NF to DF. The Trick imulate the NF Each state of DF = a non-empty subset of states of the NF tart state = the set of NF states reachable through -moves from NF start state dd a transition a to DF iff is the set of NF states reachable from the states in after seeing the input a considering -moves as well 7 72 2

NF -> DF Example NF to DF. Remark B BCDHI C E G H D F I J FGBCDHI EJGBCDHI n NF may be in many states at any time How many different states? If there are N states, the NF must be in some subset of those N states How many non-empty subsets are there? 2 N - = finitely many 73 74 Implementation Table Implementation of a DF DF can be implemented by a 2D table T One dimension is states Other dimension is input symbols For every transition i a k define T[i,a] = k DF execution If in state i and input a, read T[i,a] = k and skip to state k Very efficient T U T U T T U U T U 75 76 Implementation (Cont.) NF -> DF conversion is at the heart of tools such as flex or jlex But, DFs can be huge the end In practice, flex-like tools trade off speed for space in the choice of NF and DF representations 77 3