Lexical Analysis Lecture 3-4 Prof. Necula CS 164 Lecture 3.

Slides:



Advertisements
Similar presentations
COS 320 Compilers David Walker. Outline Last Week –Introduction to ML Today: –Lexical Analysis –Reading: Chapter 2 of Appel.
Advertisements

4b Lexical analysis Finite Automata
COMP-421 Compiler Design Presented by Dr Ioanna Dionysiou.
From Cooper & Torczon1 The Front End The purpose of the front end is to deal with the input language Perform a membership test: code  source language?
1 Lexical Analysis Cheng-Chia Chen. 2 Outline l Introduction to lexical analyzer l Tokens l Regular expressions (RE) l Finite automata (FA) »deterministic.
Winter 2007SEG2101 Chapter 81 Chapter 8 Lexical Analysis.
CS5371 Theory of Computation
Lecture 3-4 Notes by G. Necula, with additions by P. Hilfinger
Prof. Fateman CS 164 Lecture 51 Lexical Analysis Lecture 5.
1 Lexical Analysis Cheng-Chia Chen. 2 Outline 1. The goal and niche of lexical analysis in a compiler 2. Lexical tokens 3. Regular expressions (RE) 4.
Prof. Hilfinger CS 164 Lecture 21 Lexical Analysis Lecture 2-4 Notes by G. Necula, with additions by P. Hilfinger.
1 Foundations of Software Design Lecture 23: Finite Automata and Context-Free Grammars Marti Hearst Fall 2002.
COS 320 Compilers David Walker. Outline Last Week –Introduction to ML Today: –Lexical Analysis –Reading: Chapter 2 of Appel.
Lexical Analysis Recognize tokens and ignore white spaces, comments
CS 426 Compiler Construction
1 Scanning Aaron Bloomfield CS 415 Fall Parsing & Scanning In real compilers the recognizer is split into two phases –Scanner: translate input.
Chapter 3 Lexical Analysis
Topic #3: Lexical Analysis
CPSC 388 – Compiler Design and Construction Scanners – Finite State Automata.
1 Outline Informal sketch of lexical analysis –Identifies tokens in input string Issues in lexical analysis –Lookahead –Ambiguities Specifying lexers –Regular.
어휘분석 (Lexical Analysis). Overview Main task: to read input characters and group them into “ tokens. ” Secondary tasks: –Skip comments and whitespace;
Lecture # 3 Chapter #3: Lexical Analysis. Role of Lexical Analyzer It is the first phase of compiler Its main task is to read the input characters and.
COMP 3438 – Part II - Lecture 2: Lexical Analysis (I) Dr. Zili Shao Department of Computing The Hong Kong Polytechnic Univ. 1.
Lexical Analyzer (Checker)
4b 4b Lexical analysis Finite Automata. Finite Automata (FA) FA also called Finite State Machine (FSM) –Abstract model of a computing entity. –Decides.
CS412/413 Introduction to Compilers Radu Rugina Lecture 4: Lexical Analyzers 28 Jan 02.
TRANSITION DIAGRAM BASED LEXICAL ANALYZER and FINITE AUTOMATA Class date : 12 August, 2013 Prepared by : Karimgailiu R Panmei Roll no. : 11CS10020 GROUP.
1 November 1, November 1, 2015November 1, 2015November 1, 2015 Azusa, CA Sheldon X. Liang Ph. D. Computer Science at Azusa Pacific University Azusa.
CS 536 Fall Scanner Construction  Given a single string, automata and regular expressions retuned a Boolean answer: a given string is/is not in.
Lexical Analysis: Finite Automata CS 471 September 5, 2007.
Overview of Previous Lesson(s) Over View  Symbol tables are data structures that are used by compilers to hold information about source-program constructs.
Compiler Construction By: Muhammad Nadeem Edited By: M. Bilal Qureshi.
CSC3315 (Spring 2009)1 CSC 3315 Lexical and Syntax Analysis Hamid Harroud School of Science and Engineering, Akhawayn University
Lexical Analysis – Part II EECS 483 – Lecture 3 University of Michigan Wednesday, September 13, 2006.
Lexical Analysis.
1st Phase Lexical Analysis
CS412/413 Introduction to Compilers and Translators Spring ’99 Lecture 2: Lexical Analysis.
Prof. Necula CS 164 Lecture 31 Lexical Analysis Lecture 3-4.
1 Topic 2: Lexing and Flexing COS 320 Compiling Techniques Princeton University Spring 2016 Lennart Beringer.
Overview of Previous Lesson(s) Over View  A token is a pair consisting of a token name and an optional attribute value.  A pattern is a description.
CS 404Ahmed Ezzat 1 CS 404 Introduction to Compiler Design Lecture 1 Ahmed Ezzat.
Deterministic Finite Automata Nondeterministic Finite Automata.
CS412/413 Introduction to Compilers Radu Rugina Lecture 3: Finite Automata 25 Jan 02.
Lecture 2 Compiler Design Lexical Analysis By lecturer Noor Dhia
Department of Software & Media Technology
Topic 3: Automata Theory 1. OutlineOutline Finite state machine, Regular expressions, DFA, NDFA, and their equivalence, Grammars and Chomsky hierarchy.
WELCOME TO A JOURNEY TO CS419 Dr. Hussien Sharaf Dr. Mohammad Nassef Department of Computer Science, Faculty of Computers and Information, Cairo University.
CS510 Compiler Lecture 2.
Lecture 2 Lexical Analysis
Chapter 3 Lexical Analysis.
Lecture 2 Lexical Analysis Joey Paquet, 2000, 2002, 2012.
Chapter 2 Scanning – Part 1 June 10, 2018 Prof. Abdelaziz Khamis.
Finite-State Machines (FSMs)
Lexical analysis Finite Automata
Compilers Welcome to a journey to CS419 Lecture5: Lexical Analysis:
CSc 453 Lexical Analysis (Scanning)
Finite-State Machines (FSMs)
Two issues in lexical analysis
Recognizer for a Language
Building a Scanner CS164, Fall 2004 Ras Bodik, CS 164, Fall 2004.
Review: Compiler Phases:
Lecture 5: Lexical Analysis III: The final bits
CS 3304 Comparative Languages
4b Lexical analysis Finite Automata
CS 3304 Comparative Languages
Compiler Construction
4b Lexical analysis Finite Automata
Lexical Analysis.
Lecture 5 Scanning.
CSc 453 Lexical Analysis (Scanning)
Presentation transcript:

Lexical Analysis Lecture 3-4 Prof. Necula CS 164 Lecture 3

Course Administration PA1 due September 16 11:59:59 PM Read Chapters 1-3 of Red Dragon Book Continue Learning about Flex or JLex Prof. Necula CS 164 Lecture 3

Informal sketch of lexical analysis Outline Informal sketch of lexical analysis Identifies tokens in input string Issues in lexical analysis Lookahead Ambiguities Specifying lexers Regular expressions Examples of regular expressions Prof. Necula CS 164 Lecture 3

Recall: The Structure of a Compiler Lexical analysis Source Tokens Today we start Parsing Interm. Language Code Gen. Machine Code Optimization Prof. Necula CS 164 Lecture 3

What do we want to do? Example: Lexical Analysis What do we want to do? Example: if (i == j) z = 0; else z = 1; The input is just a sequence of characters: \tif (i == j)\n\t\tz = 0;\n\telse\n\t\tz = 1; Goal: Partition input string into substrings And classify them according to their role Prof. Necula CS 164 Lecture 3

Output of lexical analysis is a stream of tokens What’s a Token? Output of lexical analysis is a stream of tokens A 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. Necula CS 164 Lecture 3

Tokens correspond to sets of strings. Identifier: strings of letters or digits, starting with a letter Integer: a non-empty string of digits Keyword: “else” or “if” or “begin” or … Whitespace: a non-empty sequence of blanks, newlines, and tabs OpenPar: a left-parenthesis Prof. Necula CS 164 Lecture 3

Lexical Analyzer: Implementation An implementation must do two things: Recognize substrings corresponding to tokens Return the value or lexeme of the token The lexeme is the substring Prof. Necula CS 164 Lecture 3

Token-lexeme pairs returned by the lexer: Example Recall: \tif (i == j)\n\t\tz = 0;\n\telse\n\t\tz = 1; Token-lexeme pairs returned by the lexer: (Whitespace, “\t”) (Keyword, “if”) (OpenPar, “(“) (Identifier, “i”) (Relation, “==“) (Identifier, “j”) … Prof. Necula CS 164 Lecture 3

Lexical Analyzer: Implementation 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. Necula CS 164 Lecture 3

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 “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. == Prof. Necula CS 164 Lecture 3

Next We need A way to describe the lexemes of each token A way to resolve ambiguities Is if two variables i and f? Is == two equal signs = =? Prof. Necula CS 164 Lecture 3

There are several formalisms for specifying tokens Regular Languages There are several formalisms for specifying tokens Regular languages are the most popular Simple and useful theory Easy to understand Efficient implementations Prof. Necula CS 164 Lecture 3

(S is called the alphabet ) Languages Def. Let S be a set of characters. A language over S is a set of strings of characters drawn from S (S is called the alphabet ) Prof. Necula CS 164 Lecture 3

Examples of Languages Alphabet = English characters Language = English sentences Not every string on English characters is an English sentence Alphabet = ASCII Language = C programs Note: ASCII character set is different from English character set Prof. Necula CS 164 Lecture 3

Languages are sets of strings. Notation 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. Necula CS 164 Lecture 3

Regular Expressions and Regular Languages Each regular expression is a notation for a regular language (a set of words) If A is a regular expression then we write L(A) to refer to the language denoted by A Prof. Necula CS 164 Lecture 3

Atomic Regular Expressions Single character: ‘c’ L(‘c’) = { “c” } (for any c 2 ) Concatenation: AB (where A and B are reg. exp.) L(AB) = { ab | a 2 L(A) and b 2 L(B) } Example: L(‘i’ ‘f’) = { “if” } (we will abbreviate ‘i’ ‘f’ as ‘if’ ) Prof. Necula CS 164 Lecture 3

Compound Regular Expressions Union L(A | B) = { s | s 2 L(A) or s 2 L(B) } Examples: ‘if’ | ‘then‘ | ‘else’ = { “if”, “then”, “else”} ‘0’ | ‘1’ | … | ‘9’ = { “0”, “1”, …, “9” } (note the … are just an abbreviation) Another example: (‘0’ | ‘1’) (‘0’ | ‘1’) = { “00”, “01”, “10”, “11” } Prof. Necula CS 164 Lecture 3

More Compound Regular Expressions So far we do not have a notation for infinite languages Iteration: A* L(A*) = { “” } [ L(A) [ L(AA) [ L(AAA) [ … Examples: ‘0’* = { “”, “0”, “00”, “000”, …} ‘1’ ‘0’* = { strings starting with 1 and followed by 0’s } Epsilon:  L() = { “” } Prof. Necula CS 164 Lecture 3

Keyword: “else” or “if” or “begin” or … Example: Keyword Keyword: “else” or “if” or “begin” or … ‘else’ | ‘if’ | ‘begin’ | … (Recall: ‘else’ abbreviates ‘e’ ‘l’ ‘s’ ‘e’ ) Prof. Necula CS 164 Lecture 3

Integer: a non-empty string of digits Example: Integers Integer: a non-empty string of digits digit = ‘0’ | ‘1’ | ‘2’ | ‘3’ | ‘4’ | ‘5’ | ‘6’ | ‘7’ | ‘8’ | ‘9’ number = digit digit* Abbreviation: A+ = A A* Prof. Necula CS 164 Lecture 3

Identifier: strings of letters or digits, starting with a letter Example: Identifier Identifier: strings of letters or digits, starting with a letter letter = ‘A’ | … | ‘Z’ | ‘a’ | … | ‘z’ identifier = letter (letter | digit) * Is (letter* | digit*) the same ? Prof. Necula CS 164 Lecture 3

Whitespace: a non-empty sequence of blanks, newlines, and tabs Example: Whitespace Whitespace: a non-empty sequence of blanks, newlines, and tabs (‘ ‘ | ‘\t’ | ‘\n’)+ (Can you spot a small mistake?) Prof. Necula CS 164 Lecture 3

Example: Phone Numbers Regular expressions are all around you! Consider (510) 643-1481  = { 0, 1, 2, 3, …, 9, (, ), - } area = digit3 exchange = digit3 phone = digit4 number = ‘(‘ area ‘)’ exchange ‘-’ phone Prof. Necula CS 164 Lecture 3

Example: Email Addresses Consider necula@cs.berkeley.edu  = letter | ‘.’ | ‘@’ } name = letter+ address = name ‘@’ name (‘.’ name)* Prof. Necula CS 164 Lecture 3

Regular expressions describe many useful languages Summary Regular expressions describe many useful languages Next: Given a string s and a rexp R, is But a yes/no answer is not enough ! Instead: partition the input into lexemes We will adapt regular expressions to this goal Prof. Necula CS 164 Lecture 3

Specifying lexical structure using regular expressions Outline Specifying lexical structure using regular expressions Finite automata Deterministic Finite Automata (DFAs) Non-deterministic Finite Automata (NFAs) Implementation of regular expressions RegExp => NFA => DFA => Tables Prof. Necula CS 164 Lecture 3

Regular Expressions => Lexical Spec. (1) Select a set of tokens Number, Keyword, Identifier, ... Write a R.E. for the lexemes of each token Number = digit+ Keyword = ‘if’ | ‘else’ | … Identifier = letter (letter | digit)* OpenPar = ‘(‘ … Prof. Necula CS 164 Lecture 3

Regular Expressions => Lexical Spec. (2) Construct R, matching all lexemes for all tokens R = Keyword | Identifier | Number | … = R1 | R2 | R3 | … Facts: If s  L(R) then s is a lexeme Furthermore s  L(Ri) for some “i” This “i” determines the token that is reported Prof. Necula CS 164 Lecture 3

Regular Expressions => Lexical Spec. (3) Let the input be x1…xn (x1 ... xn are characters in the language alphabet) For 1  i  n check x1…xi  L(R) ? It must be that x1…xi  L(Rj) for some i and j Remove x1…xi from input and go to (4) Prof. Necula CS 164 Lecture 3

R = Whitespace | Integer | Identifier | ‘+’ Parse “f +3 +g” 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. Necula CS 164 Lecture 3

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 x1…xi  L(R) and also x1…xK  L(R) “Maximal munch” rule: Pick the longest possible substring that matches R Prof. Necula CS 164 Lecture 3

R = Whitespace | ‘new’ | Integer | Identifier Parse “new foo” More Ambiguities 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 x1…xi  L(Rj) and x1…xi  L(Rk) Rule: use rule listed first (j if j < k) We must list ‘new’ before Identifier Prof. Necula CS 164 Lecture 3

R = Whitespace | Integer | Identifier | ‘+’ Parse “=56” Error Handling R = Whitespace | Integer | Identifier | ‘+’ Parse “=56” No prefix matches R: not “=“, nor “=5”, nor “=56” Problem: Can’t just get stuck … Solution: Add a rule matching all “bad” strings; and put it last Lexer tools allow the writing of: R = R1 | ... | Rn | Error Token Error matches if nothing else matches Prof. Necula CS 164 Lecture 3

Regular expressions provide a concise notation for string patterns 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. Necula CS 164 Lecture 3

Regular expressions = specification Finite automata = implementation A finite automaton consists of An input alphabet  A set of states S A start state n A set of accepting states F  S A set of transitions state input state Prof. Necula CS 164 Lecture 3

In state s1 on input “a” go to state s2 Finite Automata Transition s1 a s2 Is read In state s1 on input “a” go to state s2 If end of input (or no transition possible) If in accepting state => accept Otherwise => reject Prof. Necula CS 164 Lecture 3

Finite Automata State Graphs The start state An accepting state a A transition Prof. Necula CS 164 Lecture 3

A finite automaton that accepts only “1” A Simple Example A finite automaton that accepts only “1” 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 1 Prof. Necula CS 164 Lecture 3

Another Simple Example A finite automaton accepting any number of 1’s followed by a single 0 Alphabet: {0,1} Check that “1110” is accepted but “110…” is not 1 Prof. Necula CS 164 Lecture 3

What language does this recognize? And Another Example Alphabet {0,1} What language does this recognize? 1 1 Prof. Necula CS 164 Lecture 3

The operation of the automaton is not completely defined by the input And Another Example Alphabet still { 0, 1 } The operation of the automaton is not completely defined by the input On input “11” the automaton could be in either state 1 Prof. Necula CS 164 Lecture 3

Another kind of transition: -moves  Epsilon Moves Another kind of transition: -moves  A B Machine can move from state A to state B without reading input Prof. Necula CS 164 Lecture 3

Deterministic and Nondeterministic Automata Deterministic Finite Automata (DFA) One transition per input per state No -moves Nondeterministic Finite Automata (NFA) 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 Prof. Necula CS 164 Lecture 3

Execution of Finite Automata A DFA can take only one path through the state graph Completely determined by input NFAs can choose Whether to make -moves Which of multiple transitions for a single input to take Prof. Necula CS 164 Lecture 3

An NFA can get into multiple states Acceptance of NFAs An NFA can get into multiple states 1 Input: 1 1 Rule: NFA accepts if it can get in a final state Prof. Necula CS 164 Lecture 3

NFAs and DFAs recognize the same set of languages (regular languages) NFA vs. DFA (1) NFAs and DFAs recognize the same set of languages (regular languages) DFAs are easier to implement There are no choices to consider Prof. Necula CS 164 Lecture 3

For a given language the NFA can be simpler than the DFA NFA vs. DFA (2) For a given language the NFA can be simpler than the DFA 1 NFA 1 DFA DFA can be exponentially larger than NFA Prof. Necula CS 164 Lecture 3

Regular Expressions to Finite Automata High-level sketch NFA Regular expressions DFA Lexical Specification Table-driven Implementation of DFA Prof. Necula CS 164 Lecture 3

Regular Expressions to NFA (1) For each kind of rexp, define an NFA Notation: NFA for rexp A A For   For input a a Prof. Necula CS 164 Lecture 3

Regular Expressions to NFA (2) For AB A B  For A | B A B  Prof. Necula CS 164 Lecture 3

Regular Expressions to NFA (3) For A*  A   Prof. Necula CS 164 Lecture 3

Example of RegExp -> NFA conversion Consider the regular expression (1 | 0)*1 The NFA is  A H 1 C E  B G 1 I J D F  Prof. Necula CS 164 Lecture 3

Next NFA Regular expressions DFA Lexical Table-driven Specification Implementation of DFA Prof. Necula CS 164 Lecture 3

Add a transition S a S’ to DFA iff NFA to DFA. The Trick Simulate the NFA Each state of DFA = a non-empty subset of states of the NFA Start state = the set of NFA states reachable through -moves from NFA start state Add a transition S a S’ to DFA iff S’ is the set of NFA states reachable from the states in S after seeing the input a considering -moves as well Prof. Necula CS 164 Lecture 3

NFA -> DFA Example  1   1      1 1 1 C E A B G H I J D F G H I J   D F   FGABCDHI 1 ABCDHI 1 1 EJGABCDHI Prof. Necula CS 164 Lecture 3

An NFA may be in many states at any time How many different states ? NFA to DFA. Remark An NFA may be in many states at any time How many different states ? If there are N states, the NFA must be in some subset of those N states How many non-empty subsets are there? 2N - 1 = finitely many Prof. Necula CS 164 Lecture 3

A DFA can be implemented by a 2D table T Implementation A DFA can be implemented by a 2D table T One dimension is “states” Other dimension is “input symbols” For every transition Si a Sk define T[i,a] = k DFA “execution” If in state Si and input a, read T[i,a] = k and skip to state Sk Very efficient Prof. Necula CS 164 Lecture 3

Table Implementation of a DFA T 1 S 1 1 U 1 S T U Prof. Necula CS 164 Lecture 3

Implementation (Cont.) NFA -> DFA conversion is at the heart of tools such as flex or jlex But, DFAs can be huge In practice, flex-like tools trade off speed for space in the choice of NFA and DFA representations Prof. Necula CS 164 Lecture 3

Tips on building large systems: PA2: Lexical Analysis Correctness is job #1. And job #2 and #3! Tips on building large systems: Keep it simple Design systems that can be tested Don’t optimize prematurely It is easier to modify a working system than to get a system working Prof. Necula CS 164 Lecture 3