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

Similar documents
Lexical Analysis. Lecture 2-4

Lexical Analysis. Chapter 2

Lexical Analysis. Lecture 3-4

Implementation of Lexical Analysis

Implementation of Lexical Analysis

Implementation of Lexical Analysis

Introduction to Lexical Analysis

Implementation of Lexical Analysis

Implementation of Lexical Analysis

Implementation of Lexical Analysis

Lexical Analysis. Implementation: Finite Automata

Lexical Analysis. Finite Automata

Lexical Analysis. Lecture 3. January 10, 2018

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

Introduction to Lexical Analysis

Implementation of Lexical Analysis. Lecture 4

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

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

Lexical Analysis. Finite Automata

Compiler course. Chapter 3 Lexical Analysis

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

Chapter 3 Lexical Analysis

Kinder, Gentler Nation

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

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

Compiler phases. Non-tokens

Compiler Construction LECTURE # 3

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

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

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

CSE 3302 Programming Languages Lecture 2: Syntax

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

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

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

Compiler Construction D7011E

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

Structure of Programming Languages Lecture 3

Lexical Analysis. COMP 524, Spring 2014 Bryan Ward

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

ECS 120 Lesson 7 Regular Expressions, Pt. 1

UNIT -2 LEXICAL ANALYSIS

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

CSc 453 Lexical Analysis (Scanning)

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

Introduction to Parsing. Lecture 8

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

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

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

CS164: Programming Assignment 2 Dlex Lexer Generator and Decaf Lexer

A simple syntax-directed

Lexical Analysis. Introduction

CS308 Compiler Principles Lexical Analyzer Li Jiang

CSC 467 Lecture 3: Regular Expressions

CS415 Compilers. Lexical Analysis

CMSC 350: COMPILER DESIGN

CS 314 Principles of Programming Languages. Lecture 3

Bottom-Up Parsing. Lecture 11-12

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

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

Outline. Limitations of regular languages. Introduction to Parsing. Parser overview. Context-free grammars (CFG s)

Outline CS4120/4121. Compilation in a Nutshell 1. Administration. Introduction to Compilers Andrew Myers. HW1 out later today due next Monday.

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

Compiler Construction

Chapter 4. Lexical and Syntax Analysis. Topics. Compilation. Language Implementation. Issues in Lexical and Syntax Analysis.

CS 314 Principles of Programming Languages

CSCE 314 Programming Languages

2. Lexical Analysis! Prof. O. Nierstrasz!

CS321 Languages and Compiler Design I. Winter 2012 Lecture 4

Part 5 Program Analysis Principles and Techniques

1. Lexical Analysis Phase

Outline. Limitations of regular languages Parser overview Context-free grammars (CFG s) Derivations Syntax-Directed Translation

CSE 401/M501 Compilers

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

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

Week 2: Syntax Specification, Grammars

Lexical Analysis. Chapter 1, Section Chapter 3, Section 3.1, 3.3, 3.4, 3.5 JFlex Manual

Interpreter. Scanner. Parser. Tree Walker. read. request token. send token. send AST I/O. Console

Lecture 9 CIS 341: COMPILERS

The Language for Specifying Lexical Analyzer

Lexing, Parsing. Laure Gonnord sept Master 1, ENS de Lyon

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

Lexical Analyzer Scanner

Lexical Analysis (ASU Ch 3, Fig 3.1)

PRINCIPLES OF COMPILER DESIGN UNIT II LEXICAL ANALYSIS 2.1 Lexical Analysis - The Role of the Lexical Analyzer

Lexical Analyzer Scanner

G52LAC Languages and Computation Lecture 6

Lexical analysis. Syntactical analysis. Semantical analysis. Intermediate code generation. Optimization. Code generation. Target specific optimization

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

Compiler Design. 2. Regular Expressions & Finite State Automata (FSA) Kanat Bolazar January 21, 2010

Regular Languages. MACM 300 Formal Languages and Automata. Formal Languages: Recap. Regular Languages

CSCI312 Principles of Programming Languages!

MIT Specifying Languages with Regular Expressions and Context-Free Grammars. Martin Rinard Massachusetts Institute of Technology

Writing a Lexical Analyzer in Haskell (part II)

Programming Languages (CS 550) Lecture 4 Summary Scanner and Parser Generators. Jeremy R. Johnson

MIT Specifying Languages with Regular Expressions and Context-Free Grammars

Lexical Analysis 1 / 52

CSE 401 Midterm Exam Sample Solution 2/11/15

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

Compiler Construction

Transcription:

dministrivia Lexical nalysis Lecture 2-4 Notes by G. Necula, with additions by P. Hilfinger Moving to 6 Evans on Wednesday HW available Pyth manual available on line. Please log into your account and electronically register today. Register your team with make-team. See class announcement page. Project # available Friday. Use submit hw to submit your homework this week. Section (9M) is gone. Prof. Hilfinger CS 64 Lecture 2 Prof. Hilfinger CS 64 Lecture 2 2 Outline The Structure of a Compiler Informal sketch of lexical analysis Identifies tokens in input string Source Lexical analysis Tokens Issues in lexical analysis Lookahead mbiguities Specifying lexers Regular expressions Examples of regular expressions Prof. Hilfinger CS 64 Lecture 2 3 Today we start Optimization Parsing Interm. Language Code Gen. Machine Code Prof. Hilfinger CS 64 Lecture 2 4 Lexical nalysis What do we want to do? Example: if (i == j) z = ; else z = ; The input is just a sequence of characters: \tif (i == j)\n\t\tz = ;\n\telse\n\t\tz = ; Goal: Partition input string into substrings nd classify them according to their role Prof. Hilfinger CS 64 Lecture 2 5 What s a Token? Output of lexical analysis is a stream of tokens token is a syntactic category In English: noun, verb, adjective, In a programming language: Identifier, Integer, Keyword, Whitespace, Parser relies on the token distinctions: E.g., identifiers are treated differently than keywords Prof. Hilfinger CS 64 Lecture 2 6

Tokens Lexical nalyzer: Implementation Tokens correspond to sets of strings: Identifiers: strings of letters or digits, starting with a letter Integers: non-empty strings of digits Keywords: else or if or begin or Whitespace: non-empty sequences of blanks, newlines, and tabs OpenPars: left-parentheses n implementation must do two things:. Recognize substrings corresponding to tokens 2. Return:. The type or syntactic category of the token, 2. the value or lexeme of the token (the substring itself). Prof. Hilfinger CS 64 Lecture 2 7 Prof. Hilfinger CS 64 Lecture 2 8 Example Lexical nalyzer: Implementation Our example again: \tif (i == j)\n\t\tz = ;\n\telse\n\t\tz = ; Token-lexeme pairs returned by the lexer: (Whitespace, \t ) (Keyword, if ) (OpenPar, ( ) (Identifier, i ) (Relation, == ) (Identifier, j ) The lexer usually discards uninteresting tokens that don t contribute to parsing. Examples: Whitespace, Comments Question: What happens if we remove all whitespace and all comments prior to lexing? Prof. Hilfinger CS 64 Lecture 2 9 Prof. Hilfinger CS 64 Lecture 2 Lookahead. Two important points:. The goal is to partition the string. This is implemented by reading left-to-right, recognizing one token at a time 2. Lookahead may be required to decide where one token ends and the next token begins Even our simple example has lookahead issues i vs. if = vs. == Next We need way to describe the lexemes of each token way to resolve ambiguities Is if two variables i and f? Is == two equal signs = =? Prof. Hilfinger CS 64 Lecture 2 Prof. Hilfinger CS 64 Lecture 2 2 2

Regular Languages Languages There are several formalisms for specifying tokens Regular languages are the most popular Simple and useful theory Easy to understand Efficient implementations Def. Let Σ be a set of characters. language over Σ is a set of strings of characters drawn from Σ (Σ is called the alphabet ) Prof. Hilfinger CS 64 Lecture 2 3 Prof. Hilfinger CS 64 Lecture 2 4 Examples of Languages Notation lphabet = English characters Language = English sentences Not every string on English characters is an English sentence lphabet = SCII Language = C programs Note: SCII character set is different from English character set Languages are sets of strings. Need some notation for specifying which sets we want For lexical analysis we care about regular languages, which can be described using regular expressions. Prof. Hilfinger CS 64 Lecture 2 5 Prof. Hilfinger CS 64 Lecture 2 6 Regular Expressions and Regular Languages Each regular expression is a notation for a regular language (a set of words) tomic Regular Expressions Single character: c L( c ) = { c } (for any c Σ) If is a regular expression then we write L() to refer to the language denoted by Concatenation: B (where and B are reg. exp.) L(B) = { ab a L() and b L(B) } Example: L( i f ) = { if } (we will abbreviate i f as if ) Prof. Hilfinger CS 64 Lecture 2 7 Prof. Hilfinger CS 64 Lecture 2 8 3

Compound Regular Expressions Union L( B) = L() L(B) = { s s L() or s L(B) } Examples: if then else = { if, then, else } 9 = {,,, 9 } (note the are just an abbreviation) nother example: L(( ) ( )) = {,,, } Prof. Hilfinger CS 64 Lecture 2 9 More Compound Regular Expressions So far we do not have a notation for infinite languages Iteration: * L( * ) = { } L() L() L() Examples: * = {,,,, } * = { strings starting with and followed by s } Epsilon: L() = { } Prof. Hilfinger CS 64 Lecture 2 2 Example: Keyword Keyword: else or if or begin or Example: Integers Integer: a non-empty string of digits else if begin ( else abbreviates e l s e ) digit = 2 3 4 5 6 7 8 9 number = digit digit * bbreviation: + = * Prof. Hilfinger CS 64 Lecture 2 2 Prof. Hilfinger CS 64 Lecture 2 22 Example: Identifier Identifier: strings of letters or digits, starting with a letter Example: Whitespace Whitespace: a non-empty sequence of blanks, newlines, and tabs letter = Z a z identifier = letter (letter digit) * ( \t \n ) + (Can you spot a subtle omission?) Is (letter * digit * ) the same as (letter digit) *? Prof. Hilfinger CS 64 Lecture 2 23 Prof. Hilfinger CS 64 Lecture 2 24 4

Example: Phone Numbers Regular expressions are all around you! Consider (5) 643-48 Σ = {,, 2, 3,, 9, (, ), - } area = digit 3 exchange = digit 3 phone = digit 4 number = ( area ) exchange - phone Example: Email ddresses Consider necula@cs.berkeley.edu Σ = letters [ {., @ } name = letter + address = name @ name (. name) * Prof. Hilfinger CS 64 Lecture 2 25 Prof. Hilfinger CS 64 Lecture 2 26 Summary Regular expressions describe many useful languages Next: Given a string s and a R.E. R, is s L( R )? But a yes/no answer is not enough! Instead: partition the input into lexemes We will adapt regular expressions to this goal Next: Outline Specifying lexical structure using regular expressions Finite automata Deterministic Finite utomata (DFs) Non-deterministic Finite utomata (NFs) Implementation of regular expressions RegExp => NF => DF => Tables Prof. Hilfinger CS 64 Lecture 2 27 Prof. Hilfinger CS 64 Lecture 2 28 Regular Expressions => Lexical Spec. (). Select a set of tokens Number, Keyword, Identifier,... Regular Expressions => Lexical Spec. (2) 3. Construct R, matching all lexemes for all tokens 2. Write a R.E. for the lexemes of each token Number = digit + Keyword = if else Identifier = letter (letter digit)* OpenPar = ( Prof. Hilfinger CS 64 Lecture 2 29 R = Keyword Identifier Number = R R 2 R 3 Facts: If s L(R) then s is a lexeme Furthermore s L(R i ) for some i This i determines the token that is reported Prof. Hilfinger CS 64 Lecture 2 3 5

Regular Expressions => Lexical Spec. (3) 4. Let the input be x x n (x... x n are characters in the language alphabet) For i n check x x i L(R)? 5. It must be that x x i L(R j ) for some i and j 6. Remove x x i from input and go to (4) Lexing Example R = Whitespace Integer Identifier + Parse f+3 +g f matches R, more precisely Identifier + matches R, more precisely + The token-lexeme pairs are (Identifier, f ), ( +, + ), (Integer, 3 ) (Whitespace, ), ( +, + ), (Identifier, g ) We would like to drop the Whitespace tokens after matching Whitespace, continue matching Prof. Hilfinger CS 64 Lecture 2 3 Prof. Hilfinger CS 64 Lecture 2 32 mbiguities () There are ambiguities in the algorithm Example: R = Whitespace Integer Identifier + Parse foo+3 f matches R, more precisely Identifier But also fo matches R, and foo, but not foo+ How much input is used? What if x x i L(R) and also x x K L(R) Maximal munch rule: Pick the longest possible substring that matches R More mbiguities R = Whitespace new Integer Identifier Parse new foo new matches R, more precisely new but also Identifier, which one do we pick? In general, if x x i L(R j ) and x x i L(R k ) Rule: use rule listed first (j if j < k) We must list new before Identifier Prof. Hilfinger CS 64 Lecture 2 33 Prof. Hilfinger CS 64 Lecture 2 34 Error Handling R = Whitespace Integer Identifier + Parse =56 No prefix matches R: not =, nor =5, nor =56 Problem: Can t just get stuck Solution: dd a rule matching all bad strings; and put it last Lexer tools allow the writing of: R = R... R n Error Token Error matches if nothing else matches Summary Regular expressions provide a concise notation for string patterns Use in lexical analysis requires small extensions To resolve ambiguities To handle errors Good algorithms known (next) Require only single pass over the input Few operations per character (table lookup) Prof. Hilfinger CS 64 Lecture 2 35 Prof. Hilfinger CS 64 Lecture 2 36 6

Finite utomata Regular expressions = specification Finite automata = implementation finite automaton consists of n input alphabet Σ set of states S start state n set of accepting states F S set of transitions state input state 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, othewise => reject If no transition possible => reject Prof. Hilfinger CS 64 Lecture 2 37 Prof. Hilfinger CS 64 Lecture 2 38 Finite utomata State Graphs state The start state Simple Example finite automaton that accepts only n accepting state transition a finite automaton accepts a string if we can follow transitions labeled with the characters in the string from the start to some accepting state Prof. Hilfinger CS 64 Lecture 2 39 Prof. Hilfinger CS 64 Lecture 2 4 nother Simple Example finite automaton accepting any number of s followed by a single lphabet: {,} nd nother Example lphabet {,} What language does this recognize? Check that is accepted but is not Prof. Hilfinger CS 64 Lecture 2 4 Prof. Hilfinger CS 64 Lecture 2 42 7

nd nother Example lphabet still {, } Epsilon Moves nother kind of transition: -moves B Machine can move from state to state B without reading input The operation of the automaton is not completely defined by the input On input the automaton could be in either state Prof. Hilfinger CS 64 Lecture 2 43 Prof. Hilfinger CS 64 Lecture 2 44 Deterministic and Nondeterministic utomata Deterministic Finite utomata (DF) One transition per input per state No -moves Nondeterministic Finite utomata (NF) Can have multiple transitions for one input in a given state Can have -moves Finite automata have finite memory Need only to encode the current state 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 Prof. Hilfinger CS 64 Lecture 2 45 Prof. Hilfinger CS 64 Lecture 2 46 cceptance of NFs n NF can get into multiple states NF vs. DF () NFs and DFs recognize the same set of languages (regular languages) Input: Rule: NF accepts if it can get in a final state DFs are easier to implement There are no choices to consider Prof. Hilfinger CS 64 Lecture 2 47 Prof. Hilfinger CS 64 Lecture 2 48 8

NF vs. DF (2) Regular Expressions to Finite utomata For a given language the NF can be simpler than the DF NF DF DF can be exponentially larger than NF High-level sketch Regular expressions Lexical Specification NF DF Table-driven Implementation of DF Prof. Hilfinger CS 64 Lecture 2 49 Prof. Hilfinger CS 64 Lecture 2 5 Regular Expressions to NF () Regular Expressions to NF (2) For each kind of rexp, define an NF Notation: NF for rexp For B B For For input a a For B B Prof. Hilfinger CS 64 Lecture 2 5 Prof. Hilfinger CS 64 Lecture 2 52 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 Prof. Hilfinger CS 64 Lecture 2 53 Prof. Hilfinger CS 64 Lecture 2 54 9

Next NF to DF. The Trick Regular expressions Lexical Specification NF DF Table-driven Implementation of DF Simulate the NF Each state of resulting DF = a non-empty subset of states of the NF Start state = the set of NF states reachable through -moves from NF start state dd a transition S a S to DF iff S is the set of NF states reachable from the states in S after seeing the input a considering -moves as well Prof. Hilfinger CS 64 Lecture 2 55 Prof. Hilfinger CS 64 Lecture 2 56 NF -> DF Example B C E G H D F I J FGBCDHI BCDHI EJGBCDHI Prof. Hilfinger CS 64 Lecture 2 57 NF to DF. Remark 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, but exponentially many Prof. Hilfinger CS 64 Lecture 2 58 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 S i a S k define T[i,a] = k DF execution If in state S i and input a, read T[i,a] = k and skip to state S k Very efficient S T U S T U T T U U T U Prof. Hilfinger CS 64 Lecture 2 59 Prof. Hilfinger CS 64 Lecture 2 6

Implementation (Cont.) NF -> DF conversion is at the heart of tools such as flex or jflex But, DFs can be huge In practice, flex-like tools trade off speed for space in the choice of NF and DF representations Perl s Regular Expressions Some kind of pattern-matching feature now common in programming languages. Perl s is widely copied (cf. Java, Python). Not regular expressions, despite name. E.g., pattern / (\S+) is a $/ matches spade is a spade and deal is a deal, but not spade is a shovel But no regular expression recognizes this language! Capturing substrings with ( ) itself is an extension Prof. Hilfinger CS 64 Lecture 2 6 Prof. Hilfinger CS 64 Lecture 2 62 Implementing Perl Patterns (Sketch) Can use NFs, with some modification Implement an NF as one would a DF + use backtracking search to deal with states with nondeterministic choices. dd extra states (with transitions) for parentheses. ( state records place in input as side effect. ) state saves string started at matching ( $n matches input with stored value. Backtracking much slower than DF implementation. Prof. Hilfinger CS 64 Lecture 2 63