1. ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 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 Your team information is on-line Your team information is on-line

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

4. Spring 2005 4 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University This Lecture Attribute Grammars Attribute Grammars Dynamic Semantics Dynamic Semantics

5. Spring 2005 5 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Language Survey Result Languages that most students can use Most favored languages

6. Spring 2005 6 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

7. Spring 2005 7 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

8. Spring 2005 8 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

9. Spring 2005 9 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

10. Spring 2005 10 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

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

12. Spring 2005 12 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics (Semantics) Definition: Meaning of expressions, statements, and program units Definition: Meaning of expressions, statements, and program units Why do we need semantic information? Why do we need semantic information? Programmers need to know precisely what statements of a language do Programmers need to know precisely what statements of a language do Compiler writers need to know how to interpret and process the meaning embedded in program statements Compiler writers need to know how to interpret and process the meaning embedded in program statements What do we need to utilize semantic information? What do we need to utilize semantic information? Formal ways to describe dynamic semantics Formal ways to describe dynamic semantics No single widely acceptable notation or formalism No single widely acceptable notation or formalism

13. Spring 2005 13 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics – Operational Semantics Operational Semantics: The meaning of a program described by execution of its statements on a machine Operational Semantics: The meaning of a program described by execution of its statements on a machine The meaning of a statement is defined by the change in the state of the machine (memory, registers, etc.) The meaning of a statement is defined by the change in the state of the machine (memory, registers, etc.) Components needed to describe operational semantics Components needed to describe operational semantics Translator: converts statements in a high-level language to a low-level language Translator: converts statements in a high-level language to a low-level language Virtual Machine: interprets the low-level language and reports state changes Virtual Machine: interprets the low-level language and reports state changes Java Statement for (expr1; expr2; expr3) { …} Operational Semantics expr1; expr1; loop: if expr2 = 0 goto out … expr3; expr3; goto loop goto loop out: … Translator Virtual Machine State Changes Meaning of the statement

14. Spring 2005 14 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics – Axiomatic Semantics Method to prove the correctness of programs Method to prove the correctness of programs Described by logical expressions (predicate calculus) rather than the entire state of a virtual machine Described by logical expressions (predicate calculus) rather than the entire state of a virtual machine Precondition: constraints on the program variables immediately preceding a statement Precondition: constraints on the program variables immediately preceding a statement Postcondition: new constraints on the variables after execution of the statement Postcondition: new constraints on the variables after execution of the statement Notation (Hoare Triple) Notation (Hoare Triple) { P } S { Q }, P: Precondition, Q: Postcondition, S: Statement { P } S { Q }, P: Precondition, Q: Postcondition, S: Statement e.g., { x > 10 } sum = 2 * x + 1 { sum > 1 } e.g., { x > 10 } sum = 2 * x + 1 { sum > 1 } Weakest Preconditions: the least restrictive preconditions that will guarantee the validity of the associated postconditions Weakest Preconditions: the least restrictive preconditions that will guarantee the validity of the associated postconditions e.g., { x > 0 } at the above example e.g., { x > 0 } at the above example

15. Spring 2005 15 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics – Axiomatic Semantics – Predicate Calculus Sentences (assertions) are represented by a subject and a predicate: P(x) Sentences (assertions) are represented by a subject and a predicate: P(x) e.g., P: “is red”, P(x): “x is red.” e.g., P: “is red”, P(x): “x is red.” Sentences can be combined by using logical connectives such as , , ~,  Sentences can be combined by using logical connectives such as , , ~,  e.g., Q: “is round”, P(x)  Q(x) : “x is red and round.” e.g., Q: “is round”, P(x)  Q(x) : “x is red and round.” A sentence can be structured using the universal quantifier (  ) or the existential quantifier (  ) A sentence can be structured using the universal quantifier (  ) or the existential quantifier (  ) e.g., e.g., All men are mortal:  x: P(x)  Q(x) All men are mortal:  x: P(x)  Q(x) Socrates is a man: P(Socrates) Socrates is a man: P(Socrates) Socrates is mortal: Q(Socrates) Socrates is mortal: Q(Socrates)

16. Spring 2005 16 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics – Axiomatic Semantics – Inference Rules (Hoare Logic) Inference Rule: Method of inferring the truth of one assertion on the basis of the values of other assertions Inference Rule: Method of inferring the truth of one assertion on the basis of the values of other assertions Axiom of Assignment: { Q x  E } x = E { Q } Axiom of Assignment: { Q x  E } x = E { Q } An assignment statement: x = E An assignment statement: x = E The precondition is computed as the postcondition, Q with all instances of x replaced by E The precondition is computed as the postcondition, Q with all instances of x replaced by E e.g., a = b / 2 – 1 { a < 10 } e.g., a = b / 2 – 1 { a < 10 } The weakest precondition: b / 2 – 1 < 10 b < 22

17. Spring 2005 17 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Inference Rules (Hoare Logic) – Rules of Consequence Rules to deduce new theorems from one or more axioms or theorems already proved Rules to deduce new theorems from one or more axioms or theorems already proved If S1, S2, …, Sn are true, then the truth of S can be inferred Formal representation: Formal representation: A postcondition can always be A postcondition can always be weakened and a precondition weakened and a precondition can always be strengthened can always be strengthened e.g., e.g., }{Q' S }{P' Q' Q P, P' {Q}, S {P} S S1, S2, …, Sn {x>5} x = x – 3 {x>0} {x>3} x = x – 3 {x>0}, (x>5)=>(x>3), (x>0)=>(x>0)

18. Spring 2005 18 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Inference Rules (Hoare Logic) – Rules of Composition (Sequencing) Rules to prove the correctness of a sequence of statements Rules to prove the correctness of a sequence of statements S1 and S2 are adjacent program statements S1 and S2 are adjacent program statements Inference rule: Inference rule: e.g., e.g., y = 3 * x + 1; x = y + 3; { x < 10 } The precondition of the 2 nd statement: y < 7 The precondition of the 1 st statement: x < 2 { P1 } S1; S2 { P3 } { P1 } S1 { P2 }, { P2 } S2 { P3 }

19. Spring 2005 19 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Inference Rules (Hoare Logic) – Rules of Selection Rules to prove the correctness of conditional statements Rules to prove the correctness of conditional statements Inference rule: Inference rule: e.g., e.g., if (x > 0) y = y – 1 else y = y + 1 { y > 0 } { y > 1 } y = y – 1 { y > 0} { y > -1 } y = y + 1 { y > 0 } precondition: { y > 1 } {P} if B then S1 else S2 {Q} {B P} S1 {Q}, {~B P} S2 {Q} V V

20. Spring 2005 20 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Inference Rules (Hoare Logic) – Rules of Iteration Rules to prove the correctness of while loops Rules to prove the correctness of while loops Inference rule: Inference rule: Loop Invariant ( I ): an assertion that is unaffected by the loop- controlling Boolean expression ( B ) and the loop body statements ( S ) Loop Invariant ( I ): an assertion that is unaffected by the loop- controlling Boolean expression ( B ) and the loop body statements ( S ) wp(statement, postcondition) = precondition wp(statement, postcondition) = precondition e.g., while y <> x do y = y + 1 end { y = x } e.g., while y <> x do y = y + 1 end { y = x } Zero iterations: wp( ε, { y = x } ) = { y = x } Zero iterations: wp( ε, { y = x } ) = { y = x } One iteration: wp( y = y + 1, { y = x } ) = { y = x – 1 } One iteration: wp( y = y + 1, { y = x } ) = { y = x – 1 } Two iterations: wp( y = y + 1, { y = x – 1 } ) = { y = x – 2 } Two iterations: wp( y = y + 1, { y = x – 1 } ) = { y = x – 2 } … Loop Invariant (precondition): { y <= x } Loop Invariant (precondition): { y <= x }  Proof: see Text pp.145-146  Proof: see Text pp.145-146 {I} while B do S end {I ~B} {I B} S {I} V V

21. Spring 2005 21 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics – Denotational Semantics Based on recursive function theory Based on recursive function theory The most abstract semantics description method The most abstract semantics description method Originally developed by Scott and Strachey (1970) Originally developed by Scott and Strachey (1970) Define a function that maps instances of the language entities onto instances of the corresponding mathematical objects Define a function that maps instances of the language entities onto instances of the corresponding mathematical objects e.g.,  0 | 1 | 0 | 1 e.g.,  0 | 1 | 0 | 1 Mapping Function: M bin (‘0’) = 0 M bin (‘0’) = 0 M bin (‘1’) = 1 M bin (‘1’) = 1 M bin ( ‘0’) = 2 * M bin ( ) M bin ( ‘0’) = 2 * M bin ( ) M bin ( ‘1’) = 2 * M bin ( ) + 1 M bin ( ‘1’) = 2 * M bin ( ) + 1 Parse Tree for ‘110’ with Denoted Objects  * Sebesta Figure 3.10

22. Spring 2005 22 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics – Denotational Semantics – State of a Program The state of a program is the values of all its current variables The state of a program is the values of all its current variables s = {,, …, } s = {,, …, } Let VARMAP be a function that, when given a variable name and a state, returns the current value of the variable Let VARMAP be a function that, when given a variable name and a state, returns the current value of the variable VARMAP(i j, s) = v j, VARMAP(i j, s) = v j, v j can be undef * AW Lecture Notes

23. Spring 2005 23 ICE 1341 – Programming Languages © In-Young Ko, Information and Communications University Dynamic Semantics – Denotational Semantics – Assignment Statements Ma(x := E, s)  = if Me(E, s) == error if Me(E, s) == error then error then error else s’ = {,,..., }, where else s’ = {,,..., }, where for j = 1, 2,..., n, for j = 1, 2,..., n, v j ’ = VARMAP(i j, s) if i j <> x; v j ’ = VARMAP(i j, s) if i j <> x; Me(E, s) if i j == x Me(E, s) if i j == x