Top Banner
ICE1341 ICE1341 Programming Languages Programming Languages Spring 2005 Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko .AT. i cu . ac.kr Information and Communications University (ICU)
21

ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Jan 15, 2016

Download

Documents

Rosalyn Hawkins
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

ICE1341 ICE1341 Programming LanguagesProgramming Languages

Spring 2005Spring 2005

Lecture #5Lecture #5

In-Young Koiko .AT. icu.ac.kr

Information and Communications University (ICU)

Page 2: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 2 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

AnnouncementsAnnouncements

Send your project team information to TASend your project team information to TA Team nameTeam name Student names and IDsStudent names and IDs

Page 3: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 3 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Language Syntax and Semantics – Language Syntax and Semantics – DefinitionsDefinitions

Regular ExpressionRegular Expression Formal Ways to Define LanguagesFormal Ways to Define Languages

Chomsky HierarchyChomsky Hierarchy

Last LectureLast Lecture

Page 4: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 4 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

This LectureThis Lecture

Backus-Naur Form (BNF)Backus-Naur Form (BNF) DerivationsDerivations Parse TreesParse Trees

Ambiguity in GrammarsAmbiguity in Grammars Operator PrecedenceOperator Precedence Associativity of OperatorsAssociativity of Operators

Extended BNF (EBNF)Extended BNF (EBNF)

Page 5: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 5 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Chomsky HierarchyChomsky Hierarchy Regular Grammars (Type 3)Regular Grammars (Type 3)

A A wwBB (or (or A A B Bww)) or or A A ww, where , where A and B are variables, and A and B are variables, and ww is a string of is a string of terminals (or empty)terminals (or empty)

Context-free Grammars (Type 2)Context-free Grammars (Type 2)A A , where A is a variable and , where A is a variable and is a is a string of variables and terminalsstring of variables and terminals Theoretical basis for the syntax of most Theoretical basis for the syntax of most programming languagesprogramming languages

Context-sensitive Grammars (Type 1)Context-sensitive Grammars (Type 1)AA , where A is a variable, and , where A is a variable, and , , and and are strings of variables and are strings of variables and

terminals (terminals ( and and may be empty, may be empty, ≠ ≠ є))

Unrestricted Grammars (Type 0)Unrestricted Grammars (Type 0) , where , where and and are strings of are strings of

variables and terminals (variables and terminals ( ≠ ≠ є)

0 1

e.g., e.g., 0(10)*0(10)*

0 1 0 1 0

Finite Control

Input Tape

finite automatafinite automata

0 1

e.g., e.g., S S 0S0 | 1S1 | c 0S0 | 1S1 | c

1 c 1 1 0

Finite Control

Input Tape

Stack

push-down automatapush-down automata

Non-deterministic Non-deterministic Turing machinesTuring machines

Turing machinesTuring machines

Page 6: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 6 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Turing MachineTuring Machine

An An abstract machineabstract machine introduced in introduced in 1936 by 1936 by Alan TuringAlan Turing to provide a to provide a mathematical definition of algorithmsmathematical definition of algorithms

Alan Turing (1912-1954)Alan Turing (1912-1954)

http://en.wikipedia.org/wiki/Turing_machinehttp://en.wikipedia.org/wiki/Turing_machine

0 1 0 1 0 1 0

Finite Control

Input Tape

Turing MachineTuring Machine A simple mathematical model of A simple mathematical model of

a computera computer Input tape is infinite to the rightInput tape is infinite to the right n leftmost cells hold the inputn leftmost cells hold the input The remaining infinity of cells The remaining infinity of cells

each the blankeach the blank In one move,In one move,

1.1. Change stateChange state

2.2. Print the symbol on the tape cell, Print the symbol on the tape cell, and replace itand replace it

3.3. Move the head left or right one cellMove the head left or right one cell

* Hopcroft & Ullman Chap 4

Page 7: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 7 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Backus-Naur Form (BNF)Backus-Naur Form (BNF) Invented by Invented by John BackusJohn Backus to describe Algol 58 (1959) to describe Algol 58 (1959) The most widely used method for The most widely used method for programming programming

language syntaxlanguage syntax Equivalent to Equivalent to context-free grammarscontext-free grammars A A meta-languagemeta-language to describe other languages to describe other languages

e.g., A small program (Example 3.1)e.g., A small program (Example 3.1)

<program> <program> beginbegin <stmt_list> <stmt_list> endend<stmt_list> <stmt_list> <stmt> <stmt>

| <stmt> | <stmt> ;; <stmt_list> <stmt_list><stmt> <stmt> <var> <var> == <expression> <expression><var> <var> A | B | C A | B | C<expression> <expression> <var> <var> ++ <var> <var>

| <var> | <var> -- <var> <var>| <var>| <var>

LHS (Left-hand side): LHS (Left-hand side): AbstractionAbstraction or or Non-terminalNon-terminal or or

VariableVariable

RHS (Right-hand side): RHS (Right-hand side): Lexemes (terminals)Lexemes (terminals), ,

and and reference to other reference to other abstractionsabstractions

Production (rule)Production (rule)

Page 8: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 8 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

DerivationsDerivations

Repeated application of Repeated application of productionsproductions, starting with the , starting with the start start symbolsymbol and ending with a and ending with a sentencesentence (all terminal symbols) (all terminal symbols)

<program> <program> beginbegin <stmt_list> <stmt_list> endend beginbegin <stmt> <stmt>;; <stmt_list> <stmt_list> endend beginbegin <var> <var> == <expression> <expression>;; <stmt_list> <stmt_list> endend beginbegin A A == <expression> <expression>;; <stmt_list> <stmt_list> endend beginbegin A A == <var> <var> ++ <var> <var>;; <stmt_list> <stmt_list> endend beginbegin A A == B B ++ <var> <var>;; <stmt_list> <stmt_list> endend beginbegin A A == B B ++ C C;; <stmt_list> <stmt_list> endend beginbegin A A == B B ++ C C;; <stmt> <stmt> endend beginbegin A A == B B ++ C C;; <var> <var> == <expression> <expression> end end beginbegin A A == B B ++ C C;; B B == <expression> <expression> end end beginbegin A A == B B ++ C C;; B B == <var> <var> end end beginbegin A A == B B ++ C C;; B B == C C end end

Leftmost Leftmost DerivationsDerivations

Sentential FormSentential Form

SentenceSentence

Start Start SymbolSymbol

Page 9: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 9 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Parse TreesParse Trees

A A Parse TreeParse Tree: a hierarchical : a hierarchical representation of a derivationrepresentation of a derivation Internal nodesInternal nodes of a parse tree: of a parse tree:

non-terminal symbolsnon-terminal symbols Leaf nodesLeaf nodes of a parse tree: of a parse tree:

terminal symbolsterminal symbols Each Each sub-treessub-trees of a parse tree: of a parse tree:

an instance of an abstractionan instance of an abstraction

<program>

<stmt_list>

<stmt>

C

A

<var> = <expr>

B

<var> + <var>

begin end

Page 10: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 10

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Ambiguity in a GrammarAmbiguity in a Grammar A grammar is A grammar is ambiguousambiguous iff it generates a sentential form that has iff it generates a sentential form that has

two or more distinct parse treestwo or more distinct parse trees The meaning (semantics) of an ambiguous grammar cannot be The meaning (semantics) of an ambiguous grammar cannot be

determined uniquelydetermined uniquely

e.g.,e.g., Grammar:Grammar: <expr> <expr> <expr> <op> <expr> | const <expr> <op> <expr> | const

<op> <op> // | | ––

Sentence to parse: Sentence to parse: const – const / contconst – const / cont

<expr>

<expr> <expr>

<expr> <expr><op>

const const const– /

<op>

<expr>

<expr> <expr>

<expr> <expr>

<op><op>

<op>

const const const– /

* AW Lecture Notes

Page 11: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 11

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

How to Remove Ambiguity?How to Remove Ambiguity?

Make the grammar grow only on one direction Make the grammar grow only on one direction (similar to a regular grammar) ?(similar to a regular grammar) ?e.g.,e.g., Grammar:Grammar: <expr> <expr> const <op> <expr> | const const <op> <expr> | const

<op> <op> // | | ––

<expr>

<expr>

<expr>

<op><op>

<op>

const const const- /

Then, how about the case Then, how about the case of parsing the following of parsing the following sentence?sentence?

const / const - constconst / const - const

* AW Lecture Notes

①①

②②

Page 12: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 12

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Operator PrecedenceOperator Precedence

Specify Specify operator orderingsoperator orderings in a grammar to in a grammar to prevent the grammar ambiguityprevent the grammar ambiguity

e.g.,e.g., Grammar:Grammar: <expr> <expr> <expr> – <term> | <term> <expr> – <term> | <term> <term> <term> <term> / const | const <term> / const | const

Sentence to parse: Sentence to parse: const / const - constconst / const - const

Derivation:Derivation:<expr> <expr> <expr> <expr> –– <term> <term> <term> <term> –– <term> <term> <term> <term> // const - <term> const - <term> const const // const - <term> const - <term> const const // const - const const - const

* AW Lecture Notes

<expr>

<term>

const

<expr>

<term>

const

const/

–<term>

Page 13: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 13

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Associativity of OperatorsAssociativity of Operators

A A left recursiveleft recursive grammar (e.g., S grammar (e.g., S Sw) specifies Sw) specifies left associativityleft associativitye.g., <expr> e.g., <expr> <expr> + const | const <expr> + const | const

AA right recursive grammar right recursive grammar (e.g., S (e.g., S wS) specifies wS) specifies right associativityright associativitye.g., <expr> e.g., <expr> const ** <expr> | const const ** <expr> | const

e.g.,e.g., Grammar:Grammar: <expr> <expr> <expr> + <expr> | const <expr> + <expr> | const Sentence to parse: Sentence to parse: const + const + constconst + const + const

AmbiguousAmbiguous Can it be solved by specifying operator precedence?Can it be solved by specifying operator precedence?

Page 14: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 14

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Extended BNF (EBNF)Extended BNF (EBNF) Optional partsOptional parts

e.g., <selection> e.g., <selection> if (<expression>) <statement> if (<expression>) <statement> [[ else <statement> else <statement>]] RepetitionRepetition

e.g., <ident_list> e.g., <ident_list> <identifier> <identifier> {{, <identifier>, <identifier>}} Multiple choicesMultiple choices

e.g., <term> e.g., <term> <term> ( * <term> ( * || / / || % ) <factor> % ) <factor>

BNFBNF <expr> <expr> <expr> + <term> <expr> + <term>

| <expr> – <term>| <expr> – <term> | <term>| <term> <term> <term> <term> * <factor> <term> * <factor> | <term> / | <term> /

<factor><factor> | <factor>| <factor>

EBNFEBNF <expr> <expr> <term> <term> {{(+ (+ || -) <term> -) <term>}}

<term> <term> <factor> <factor> {{(* (* || /) <factor> /) <factor>}}

* AW Lecture Notes

Page 15: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 15

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Attribute Grammars – Attribute Grammars – Problem DescriptionProblem Description

Example Problem: Example Problem: Type Compatibility RuleType Compatibility Rule<assign> <assign> <var> = <expr> <var> = <expr>

<expr> <expr> <var> + <var> | <var> <var> + <var> | <var>

<var> <var> A | B | C A | B | C

1.1. The type of an expression The type of an expression when the operand types are not the when the operand types are not the samesame is always is always realreal (e.g., C = 10 + 12.5) (e.g., C = 10 + 12.5)

2.2. When they are the sameWhen they are the same, the expression type is that of the , the expression type is that of the operands (e.g., C = 12.5 + 0.23)operands (e.g., C = 12.5 + 0.23)

3.3. The type of the left side of the assignment must The type of the left side of the assignment must match the match the typetype of the right side of the right side

This rule represents the This rule represents the static semanticsstatic semantics that needs to that needs to be checked at compile time (c.f., dynamic semantics)be checked at compile time (c.f., dynamic semantics)

This rule cannot be represented in BNFThis rule cannot be represented in BNF

e.g., C = 10 + 12.5 + 0.23e.g., C = 10 + 12.5 + 0.23

Page 16: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 16

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Attribute Grammars –Attribute Grammars –DefinitionDefinition

Designed by Designed by Donald E.Donald E. KnuthKnuth, 1968, 1968 A formal approach to both A formal approach to both describing and checking the describing and checking the

correctness of the static semanticscorrectness of the static semantics of a program of a program Main elementsMain elements

AttributesAttributes: associated with grammar symbols: associated with grammar symbols Synthesized AttributesSynthesized Attributes: computed based on the attributes in a : computed based on the attributes in a

parse treeparse tree Inherited AttributesInherited Attributes: inherited from parents in a parse tree: inherited from parents in a parse tree Intrinsic AttributesIntrinsic Attributes: synthesized attributes of leaf nodes: synthesized attributes of leaf nodes

Attribute computation functionsAttribute computation functions ( (semantic rulessemantic rules): spec): specify ify how attribute values are computedhow attribute values are computed

Predicate functionsPredicate functions: syntactic and semantic rules of a : syntactic and semantic rules of a language, associated with grammar ruleslanguage, associated with grammar rules

Page 17: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 17

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Attribute Grammars –Attribute Grammars –An ExampleAn Example

Attributes: Attributes: actual_typeactual_type (synthesized attr.), (synthesized attr.), expected_typeexpected_type (inherited attr.) (inherited attr.)

1.1. Syntax rule:Syntax rule: <assign> <assign> <var> = <expr> <var> = <expr>Semantic rule:Semantic rule: <expr>. <expr>.expected_typeexpected_type <var>. <var>.actual_typeactual_type

2.2. Syntax rule:Syntax rule: <expr> <expr> <var>[2] + <var>[3] <var>[2] + <var>[3]Semantic rule:Semantic rule: <expr>. <expr>.actual_typeactual_type

if (<var>[2].if (<var>[2].actual_typeactual_type = int) and = int) and (<var>[3].(<var>[3].actual_typeactual_type = int) then int = int) then intelse realelse realendifendif

Predicate:Predicate: <expr>. <expr>.actual_typeactual_type = <expr>. = <expr>.expected_typeexpected_type

3.3. Syntax rule:Syntax rule: <expr> <expr> <var> <var>Semantic rule:Semantic rule: <expr>. <expr>.actual_typeactual_type <var>. <var>.actual_typeactual_typePredicate:Predicate: <expr>. <expr>.actual_typeactual_type = <expr>. = <expr>.expected_typeexpected_type

4.4. Syntax rule:Syntax rule: <var> <var> A | B | C A | B | CSemantic rule:Semantic rule: <var>. <var>.actual_typeactual_type look-up(<var>. look-up(<var>.stringstring))

<assign> <assign> <var> = <expr> <var> = <expr><expr> <expr> <var> + <var> | <var> <var> + <var> | <var><var> <var> A | B | C A | B | C

Page 18: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 18

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Computing Attribute Values – Computing Attribute Values – Evaluating AttributesEvaluating Attributes

Sentence: Sentence: A = A + BA = A + B

1. <var>.1. <var>.actual_typeactual_type look-up(A) look-up(A) (Rule 4)(Rule 4)

2. <expr>.2. <expr>.expected_typeexpected_type <var>. <var>.actual_typeactual_type (Rule 1)(Rule 1)

3. <var>[2].3. <var>[2].actual_typeactual_type look-up(A)look-up(A) (Rule 4)(Rule 4)

<var>[3].<var>[3].actual_typeactual_type look-up(B)look-up(B) (Rule 4)(Rule 4)

4. <expr>.4. <expr>.actual_typeactual_type either int or realeither int or real (Rule 2)(Rule 2)

5. <expr>.5. <expr>.expected_typeexpected_type = =

<expr>.<expr>.actual_typeactual_type is is

either TRUE or FALSEeither TRUE or FALSE (Rule 2)(Rule 2)

Grammar:Grammar:<assign> <assign> <var> = <expr> <var> = <expr><expr> <expr> <var> + <var> | <var> <var> + <var> | <var><var> <var> A | B | C A | B | C

* Sebesta Figure 3.6

Page 19: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 19

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Computing Attribute Values – Computing Attribute Values – Flow of Attributes in a Parse TreeFlow of Attributes in a Parse Tree

An Inherited An Inherited AttributeAttribute

A Synthesized A Synthesized AttributeAttribute

An Intrinsic An Intrinsic AttributeAttribute

* Sebesta Figure 3.7

Page 20: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 20

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Computing Attribute Values – Computing Attribute Values – Fully Attributed Parse TreeFully Attributed Parse Tree

* Sebesta Figure 3.8

Page 21: ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.

Spring 2005 21

ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University

Homework #2Homework #2

Chapter 3 Problem Set (pp. 157 – 158)Chapter 3 Problem Set (pp. 157 – 158) #2 – a#2 – a #5#5 #7#7 #8#8 #13#13