March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Programming Languages (ICE 1341) Lecture #4 Programming Languages (ICE 1341) Lecture #4 March 5, 2004 In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Announcements Confirming the class registration Confirming the class registration Rescheduling of the class on March 10 th Rescheduling of the class on March 10 th Monday, March 8 th 4:00pm-5:00pm, L401 Monday, March 8 th 4:00pm-5:00pm, L401

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Review of the Previous Lecture Compilation Process Compilation Process Syntax and Semantics Syntax and Semantics Formal Ways to Define Languages Formal Ways to Define Languages Language Recognizers Language Recognizers Language Generators Language Generators Context-free Grammars Context-free Grammars Chomsky Hierarchy Chomsky Hierarchy

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Ambiguity in a Grammar A grammar is ambiguous iff it generates a sentential form that has two or more distinct parse trees A grammar is ambiguous iff it generates a sentential form that has two or more distinct parse trees The meaning (semantics) of an ambiguous grammar cannot be determined uniquely The meaning (semantics) of an ambiguous grammar cannot be determined uniquely e.g., Grammar:  | const  / | –  / | – Sentence to parse: const – const / cont Sentence to parse: const – const / cont const –/ const – / * AW Lecture Notes

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko How to Remove Ambiguity? Make the grammar grow only on one direction (similar to a regular grammar) ? Make the grammar grow only on one direction (similar to a regular grammar) ? e.g., Grammar:  const | const  / | –  / | – const -/ Then, how about the case of parsing the following sentence? const / const - const * AW Lecture Notes

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Operator Precedence Specify operator orderings in a grammar to prevent the grammar ambiguity Specify operator orderings in a grammar to prevent the grammar ambiguity const /– e.g., Grammar:  – | e.g., Grammar:  – |  / const | const  / const | const Sentence to parse: const – const / cont Sentence to parse: const – const / cont Derivation:  –  –  const –  const –  const – / const  const – / const  const – const / const  const – const / const * AW Lecture Notes

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Associativity of Operators A left recursive grammar (e.g., S  Sw) specifies left associativity A left recursive grammar (e.g., S  Sw) specifies left associativity e.g.,  + const | const A right recursive grammar (e.g., S  wS) specifies right associativity A right recursive grammar (e.g., S  wS) specifies right associativity e.g.1,  const + | const e.g.2,  const ** | const e.g., Grammar:  + | const Sentence to parse: const + const + cont Sentence to parse: const + const + cont  Ambiguous  Ambiguous  Can it be solved by specifying operator precedence?  Can it be solved by specifying operator precedence?

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Extended BNF (EBNF) Optional parts Optional parts e.g.,  if ( ) [ else ] Repetition Repetition e.g.,  {, } Multiple choices Multiple choices e.g.,  ( * | / | % ) e.g.,  ( * | / | % ) BNF BNF  +  + | – | – | |  *  * | / | / | | EBNF EBNF  {(+ | -) }  {(+ | -) }  {(* | /) }  {(* | /) } * AW Lecture Notes

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Attribute Grammars – Problem Description Example Problem: Type Compatibility Rule Example Problem: Type Compatibility Rule  =  =  + |  + |  A | B | C  A | B | C The type of an expression when the operand types are not the same is always real. The type of an expression when the operand types are not the same is always real. When they are the same, the expression type is that of the operands. When they are the same, the expression type is that of the operands. The type of the left side of the assignment must match the type of the right side. The type of the left side of the assignment must match the type of the right side. This rule represents the static semantics that needs to be checked at compile time (c.f., dynamic semantics) This rule represents the static semantics that needs to be checked at compile time (c.f., dynamic semantics) This rule cannot be represented in BNF This rule cannot be represented in BNF

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Attribute Grammars – Definition Designed by Donald E. Knuth, 1968 Designed by Donald E. Knuth, 1968 A formal approach to both describing and checking the correctness of the static semantics of a program A formal approach to both describing and checking the correctness of the static semantics of a program Main elements Main elements Attributes: associated with grammar symbols Attributes: associated with grammar symbols Synthesized Attributes: computed based on the attributes in a parse tree Synthesized Attributes: computed based on the attributes in a parse tree Inherited Attributes: inherited from parents in a parse tree Inherited Attributes: inherited from parents in a parse tree Intrinsic Attributes: synthesized attributes of leaf nodes Intrinsic Attributes: synthesized attributes of leaf nodes Attribute computation functions (semantic functions): associated with grammar rules (productions) Attribute computation functions (semantic functions): associated with grammar rules (productions) Predicate functions: syntactic and semantic rules of a language, associated with grammar rules Predicate functions: syntactic and semantic rules of a language, associated with grammar rules

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Attribute Grammars – An Example Attributes: actual_type (synthesized attr.), expected_type (inherited attr.) Attributes: actual_type (synthesized attr.), expected_type (inherited attr.) 1.Syntax rule:  = 1.Syntax rule:  = Semantic rule:.expected_type .actual_type 2.Syntax rule:  [2] + [3] Semantic rule:.actual_type  if ( [2].actual_type = int) and ( [3].actual_type = int) then int ( [3].actual_type = int) then int else real endif Predicate:.actual_type =.expected_type 3.Syntax rule:  3.Syntax rule:  Semantic rule:.actual_type .actual_type Predicate:.actual_type =.expected_type 4.Syntax rule:  A | B | C Semantic rule:.actual_type  look-up(.string)

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Computing Attribute Values – Evaluating Attributes Sentence: A = A + B 1..actual_type  look-up(A) (Rule 4) 2..expected_type .actual_type (Rule 1) 3. [2].actual_type  look-up(A) (Rule 4) [3].actual_type  look-up(B) (Rule 4) [3].actual_type  look-up(B) (Rule 4) 4..actual_type  either int or real (Rule 2) either int or real (Rule 2) 5..expected_type =.actual_type is.actual_type is either TRUE or FALSE (Rule 2) either TRUE or FALSE (Rule 2) Grammar:  =  =  + |  + |  A | B | C  A | B | C

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Computing Attribute Values – Flow of Attributes in a Parse Tree An Inherited Attribute A Synthesized Attribute An Intrinsic Attribute

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Computing Attribute Values – Fully Attributed Parse Tree

March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Homework #2 Chapter 3 Problem Set (pp. 157 – 158) Chapter 3 Problem Set (pp. 157 – 158) #2 – a, b #2 – a, b #5 #5 #6 – a #6 – a #8 #8 #13 #13 #14 #14