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 (ICU)

2. Spring 2005 2 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Announcements Send your project team information to TA Send your project team information to TA Team name Team name Student names and IDs Student names and IDs

3. Spring 2005 3 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Language Syntax and Semantics – Definitions Language Syntax and Semantics – Definitions Regular Expression Regular Expression Formal Ways to Define Languages Formal Ways to Define Languages Chomsky Hierarchy Chomsky Hierarchy Last Lecture

4. Spring 2005 4 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University This Lecture Backus-Naur Form (BNF) Backus-Naur Form (BNF) Derivations Derivations Parse Trees Parse Trees Ambiguity in Grammars Ambiguity in Grammars Operator Precedence Operator Precedence Associativity of Operators Associativity of Operators Extended BNF (EBNF) Extended BNF (EBNF)

5. Spring 2005 5 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Chomsky Hierarchy Regular Grammars (Type 3) Regular Grammars (Type 3) A  wB (or A  Bw) or A  w, where A and B are variables, and w is a string of terminals (or empty) Context-free Grammars (Type 2) Context-free Grammars (Type 2) A  , where A is a variable and  is a string of variables and terminals  Theoretical basis for the syntax of most programming languages Context-sensitive Grammars (Type 1) Context-sensitive Grammars (Type 1)  A   , where A is a variable, and ,  and  are strings of variables and terminals (  and  may be empty,  ≠ )  A   , where A is a variable, and ,  and  are strings of variables and terminals (  and  may be empty,  ≠ є ) Unrestricted Grammars (Type 0) Unrestricted Grammars (Type 0)   , where  and  are strings of variables and terminals (  ≠   , where  and  are strings of variables and terminals (  ≠ є) 01 e.g., 0(10)* 01010 Finite Control Input Tape finite automata 01 e.g., S  0S0 | 1S1 | c 1c110 Finite Control Input Tape Stack push-down automata Non-deterministic Turing machines Turing machines

6. Spring 2005 6 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Turing Machine An abstract machine introduced in 1936 by Alan Turing to provide a mathematical definition of algorithms Alan Turing (1912-1954) http://en.wikipedia.org/wiki/Turing_machine 0101010 Finite Control Input Tape Turing Machine A simple mathematical model of a computer A simple mathematical model of a computer Input tape is infinite to the right Input tape is infinite to the right n leftmost cells hold the input n leftmost cells hold the input The remaining infinity of cells each the blank The remaining infinity of cells each the blank In one move, In one move, 1.Change state 2.Print the symbol on the tape cell, and replace it 3.Move the head left or right one cell * Hopcroft & Ullman Chap 4

7. Spring 2005 7 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Backus-Naur Form (BNF) Invented by John Backus to describe Algol 58 (1959) Invented by John Backus to describe Algol 58 (1959) The most widely used method for programming language syntax The most widely used method for programming language syntax Equivalent to context-free grammars Equivalent to context-free grammars A meta-language to describe other languages A meta-language to describe other languages e.g., A small program (Example 3.1)  begin end  begin end   | ; | ;  =  =  A | B | C  A | B | C  +  + | - | - | | LHS (Left-hand side): Abstraction or Non-terminal or Variable RHS (Right-hand side): Lexemes (terminals), and reference to other abstractions Production (rule)

8. Spring 2005 8 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Derivations Repeated application of productions, starting with the start symbol and ending with a sentence (all terminal symbols)  begin end  begin end  begin ; end  begin ; end  begin = ; end  begin = ; end  begin A = ; end  begin A = ; end  begin A = + ; end  begin A = + ; end  begin A = B + ; end  begin A = B + ; end  begin A = B + C; end  begin A = B + C; end  begin A = B + C; = end  begin A = B + C; = end  begin A = B + C; B = end  begin A = B + C; B = end  begin A = B + C; B = C end  begin A = B + C; B = C end Leftmost Derivations Sentential Form Sentence Start Symbol

9. Spring 2005 9 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Parse Trees A Parse Tree: a hierarchical representation of a derivation A Parse Tree: a hierarchical representation of a derivation Internal nodes of a parse tree: non-terminal symbols Internal nodes of a parse tree: non-terminal symbols Leaf nodes of a parse tree: terminal symbols Leaf nodes of a parse tree: terminal symbols Each sub-trees of a parse tree: an instance of an abstraction Each sub-trees of a parse tree: an instance of an abstraction C A = B + beginend …

10. Spring 2005 10 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University 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

11. Spring 2005 11 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University 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 ① ②

12. Spring 2005 12 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Operator Precedence Specify operator orderings in a grammar to prevent the grammar ambiguity Specify operator orderings in a grammar to prevent the grammar ambiguity e.g., Grammar:  – | e.g., Grammar:  – |  / const | const  / const | const Sentence to parse: const / const - const Sentence to parse: const / const - const Derivation:  –  –  / const -  / const -  const / const -  const / const -  const / const - const  const / const - const * AW Lecture Notes const const / –

13. Spring 2005 13 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University 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.,  const ** | const e.g., Grammar:  + | const Sentence to parse: const + const + const Sentence to parse: const + const + const  Ambiguous  Ambiguous  Can it be solved by specifying operator precedence?  Can it be solved by specifying operator precedence?

14. Spring 2005 14 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University 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

15. Spring 2005 15 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Attribute Grammars – Problem Description Example Problem: Type Compatibility Rule Example Problem: Type Compatibility Rule  =  =  + |  + |  A | B | C  A | B | C 1.The type of an expression when the operand types are not the same is always real (e.g., C = 10 + 12.5) 2.When they are the same, the expression type is that of the operands (e.g., C = 12.5 + 0.23) 3.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 e.g., C = 10 + 12.5 + 0.23

16. Spring 2005 16 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University 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 rules): specify how attribute values are computed Attribute computation functions (semantic rules): specify how attribute values are computed 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

17. Spring 2005 17 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Attribute Grammars – An Example Attributes: actual_type (synthesized attr.), Attributes: actual_type (synthesized attr.), expected_type (inherited 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)  =  =  + |  + |  A | B | C  A | B | C

18. Spring 2005 18 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University 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 * Sebesta Figure 3.6

19. Spring 2005 19 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Computing Attribute Values – Flow of Attributes in a Parse Tree An Inherited Attribute A Synthesized Attribute An Intrinsic Attribute * Sebesta Figure 3.7

20. Spring 2005 20 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Computing Attribute Values – Fully Attributed Parse Tree * Sebesta Figure 3.8

21. Spring 2005 21 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Homework #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