1. Fall 20021 Semantics Juan Carlos Guzmán CS 3123 Programming Languages Concepts Southern Polytechnic State University

2. Fall 20022 Why Semantics? We need to establish precisely the meaning of programs English is not enough – it is imprecise!

3. Fall 20023 Examples What does it mean to compute x+5 x++ x+y

4. Fall 20024 More Examples What does it mean to compute fact(5) fact(-5) where fact is defined as int fact(n) { if (n==0) return 1; return n * fact(--n); }

5. Fall 20025 Still more Examples What does it mean to define int fact(n) { if (n==0) return 1; return n * fact(--n); }

6. Fall 20026 Issues Any construct can be given a semantics, if one is persistent enough! The more complex the semantics, the less intuitive your language is! Be simple and elegant

7. Fall 20027 Classes of Semantics Operational Semantics Meaning is given by presenting an “interpreter”: the meaning of a language is the behavior of such an interpreter Axiomatic Semantics Meaning given by using Logic to establish assertions (properties) about programs Denotational Semantics Based on mathematics (Function Theory,  Calculus) Meaning given by modeling each construct as a function

8. Fall 20028 Operational Semantics Meaning by interpretation Easy to construct: just build the machine To know the meaning of a program, run the program in the machine The machine provided is simple, of easy implementation The limitation of this approach is that the meaning is given in the realm of computation: only computable concepts can be understood

9. Fall 20029 Operational Semantics (II) Typical machine: JVM von Neumann machine Turing Machine! for (exp 1 ; exp 2 ; exp 3 ) body exp 1 loop: if exp 2 = 0 goto out body exp 3 goto loop out: …

10. Fall 200210 Limitations of Operational Semantics Because meaning is given by another machine, there is no reasoning about noncomputable properties: nontermination function equality

11. Fall 200211 Axiomatics Semantics Meaning by using Logic Assertions everywhere! Each assertion establishes the state of the system at any given time Computation changes the system from one state to another Therefore, computation can be thought of a transformer of states

12. Fall 200212 Axiomatic Semantics (II) State Transformer: { P } S { Q } S being the statement, or construct, P is its precondition, and Q its postcondition P being valid before S is executed implies that Q must be valid after S The “name of the game” is finding the weakest precondition so that the postcondition holds true!

13. Fall 200213 Example of Axiomatic Semantics { x>10 } sum = 2*x+1 { sum>1 } Why the weakest precondition? The expected result of the program happens to be the postcondition of the program, i.e., the postcondition of its last statement We can work all the way back to find the weakest precondition of the program that would satisfy the expected result! Anything stronger that the weakest precondition will work

14. Fall 200214 More Examples { P 1 } S 1 ; S 2 { P 3 } { P 1 } S 1 { P 2 }  { P 2 } S 2 { P 3 } Sequence { P } if B then S 1 else S 2 { Q } { B  P } S 1 { Q } {  B  P } S 2 { Q } If { I } while B do S { I   B } { I  B } S { I } While

15. Fall 200215 A Correct Program { n >= 0 } count = n; fact =1; while count <> 0 do fact = fact * count; count = count –1; end { fact = n! }

16. Fall 200216 A Correct Program { n  0 } count = n; fact =1; {count  0  n  0  fact * count! = n! } while count <> 0 do {count > 0  n  0  fact * count! = n! } fact = fact * count; count = count –1; end {count = 0  n  0  fact * count! = n! } { i.e., fact = n! }

17. Fall 200217 Denotational Semantics Meaning given by modeling each construct as a function Maps all syntactic objects to corresponding semantic elements: The number 12 present in the program means the mathematical concept 12

18. Fall 200218 Example Let e ::= n(number) | e 1 +e 2 (sum) Eval [[n]] = Number [[n]] Eval [[e 1 +e 2 ]] = (Eval [[e 1 ]]) + (Eval [[e 2 ]]) Number [[n]], not defined, maps the input n into its corresponding mathematical concept

19. Fall 200219 Other Semantics Many other ways of expressing the semantics of a program have been invented: you can always express the semantics if you try hard enough! Simple semantics usually means simple implementation and a better mathematical foundation

20. Fall 200220 Attribute Grammars Attribute grammars are extensions to Context-Free grammars that allow certain language rules to be expressed They are used to further restrict the phrases in a language  building and use of symbol tables: enforce static binding (decl. & use of id’s) compute properties of phrases  Construction of the AST

21. Fall 200221 Attribute Grammars (II) There is the tendency associate syntax with the CFG used in parsing, and to call all other properties pertaining to the phrases of the language as semantics, or, more properly, static semantics Your professor would rather call them “abstract interpretations”, with AG being one convenient way of expressing these

22. Fall 200222 Attribute Grammars (III) An attribute grammar is a context-free grammar, with  attributes  attribute computation functions  predicate functions Attributes are variables that can hold values on specific nodes of a syntax tree Attribute computation functions indicate how the values to those attributes are computed Predicate functions state properties that must be satisfied by the tree

23. Fall 200223 Attributes Attributes are variables, associated to tree nodes, that will be given a value Synthesized attribute: the value of the attribute is dependant on the information contained in the subtree where it is located Inherited attribute: the value of the attribute is determined by the environment where the attribute is located

24. Fall 200224 Grammar for Simple Assignment Statements  assign    var  =  expr   expr    var 2  +  var 3   expr    var   var   A | B | C Allowable types are int or real Attributes: actual_type, for nonterminals  expr  and  var  expected_type, for nonterminal  expr  string, for  var 

25. Fall 200225 Attribute Grammar for Simple Assignment Statements  assign    var  =  expr   expr .expected_type :=  var .actual_type  expr    var  2 +  var  3  expr .actual_type := if (  var  2.actual_type==int) && (  var  3.actual_type==int) then int else real  expr .actual_type ==  expr .expected_type  expr    var   expr .actual_type :=  var .actual_type  expr .actual_type ==  expr .expected_type  var   A | B | C  var .actual_type := lookup(  var .string)

26. Fall 200226 Parse Tree for A=A+B  assign   expr   var  A=A+B This tree does not reflect the checking of the Predicate Functions, in this case, just in the  expr  node

27. Fall 200227 Flow of Attributes for A=A+B  assign   expr   var  A=A+B actual_type expected_type This tree does not reflect the checking of the Predicate Functions, in this case, just in the  expr  node

28. Fall 200228 Fully Attributed Parse Tree for A=A+B  assign   expr   var  A=A+B actual_type = int string = A actual_type = int string = A actual_type = int string = B expected_type = int actual_type = int This tree does not reflect the checking of the Predicate Functions, in this case, just in the  expr  node