8 Introduction to Denotational Semantics PS Denotational Semantics

8. Introduction to Denotational Semantics

PS — Denotational Semantics Roadmap > Syntax and Semantics > Semantics of Expressions > Semantics of Assignment > Other Issues © O. Nierstrasz 8. 2

PS — Denotational Semantics References > > D. A. Schmidt, Denotational Semantics, Wm. C. Brown Publ. , 1986 D. Watt, Programming Language Concepts and Paradigms, Prentice Hall, 1990 © O. Nierstrasz 8. 3

PS — Denotational Semantics Roadmap > Syntax and Semantics > Semantics of Expressions > Semantics of Assignment > Other Issues © O. Nierstrasz 8. 4

PS — Denotational Semantics Defining Programming Languages There are three main characteristics of programming languages: 1. Syntax: What is the appearance and structure of its programs? 2. Semantics: What is the meaning of programs? The static semantics tells us which (syntactically valid) programs are semantically valid (i. e. , which are type correct) and the dynamic semantics tells us how to interpret the meaning of valid programs. 3. Pragmatics: What is the usability of the language? How easy is it to implement? What kinds of applications does it suit? © O. Nierstrasz 8. 5

PS — Denotational Semantics Uses of Semantic Specifications Semantic specifications are useful for language designers to communicate with implementors as well as with programmers. A precise standard for a computer implementation: How should the language be implemented on different machines? User documentation: What is the meaning of a program, given a particular combination of language features? A tool for design and analysis: How can the language definition be tuned so that it can be implemented efficiently? Input to a compiler generator: How can a reference implementation be obtained from the specification? © O. Nierstrasz 8. 6

PS — Denotational Semantics Methods for Specifying Semantics Operational Semantics: > [[ program ]] = abstract machine program > can be simple to implement > hard to reason about Axiomatic Semantics: > [[ program ]] = set of properties > good for proving theorems about programs > somewhat distant from implementation Denotational Semantics: > [[ program ]] = mathematical denotation > (typically, a function) > facilitates reasoning > not always easy to find suitable semantic domains Structured Operational Semantics: > [[ program ]] = transition system > (defined using inference rules) > good for concurrency and nondeterminism > hard to reason about equivalence © O. Nierstrasz 8. 7

PS — Denotational Semantics Roadmap > Syntax and Semantics > Semantics of Expressions > Semantics of Assignment > Other Issues © O. Nierstrasz 8. 8

PS — Denotational Semantics Concrete and Abstract Syntax How to parse “ 4 * 2 + 1”? Abstract Syntax is compact but ambiguous: Expr Op : : = Num | Expr Op Expr : : = + | - | * | / Concrete Syntax is unambiguous but verbose: Expr Term Factor Low. Op High. Op : : = Expr Low. Op Term | Term : : = Term High. Op Factor | Factor : : = Num | ( Expr ) : : = + | : : = * | / Concrete syntax is needed for parsing; abstract syntax suffices for semantic specifications. © O. Nierstrasz 8. 9

PS — Denotational Semantics A Calculator Language Abstract Syntax: Prog Stmt Expr : : = | | | 'ON' Stmt Expr 'TOTAL' 'OFF' Expr 1 '+' Expr 2 Expr 1 '*' Expr 2 'IF' Expr 1 ', ' Expr 2 ', ' Expr 3 'LASTANSWER' '(' Expr ')' Num The program “ON 4 * ( 3 + 2 ) TOTAL OFF” should print out 20 and stop. © O. Nierstrasz 8. 10

PS — Denotational Semantics Calculator Semantics We need three semantic functions: one for programs, one for statements (expression sequences) and one for expressions. The meaning of a program is the list of integers printed: Programs: P : Program Int* P [[ ON S ]] = S [[ S ]] (0) A statement may use and update LASTANSWER: Statements: S : : Expr. Sequence Int* S [[ E TOTAL S ]] (n) = let n' = E [[ E ]] (n) in cons(n', S [[ S ]] (n')) S [[ E TOTAL OFF ]] (n) = [ E [[ E ]] (n) ] © O. Nierstrasz 8. 11

PS — Denotational Semantics Calculator Semantics. . . Expressions: E : Expression Int E [[ E 1 + E 2 ]] (n) = E [[ E 1 ]] (n) + E [[ E 2 ]] (n) E [[ E 1 * E 2 ]] (n) = E [[ E 1 ]] (n) E [[ E 2 ]] (n) E [[ IF E 1 , E 2 , E 3 ]] (n) = if E [[ E 1 ]] (n) = 0 then E [[ E 2 ]] (n) else E [[ E 3 ]] (n) E [[ LASTANSWER ]] (n) = n E [[ ( E ) ]] (n) = E [[ E ]] (n) E [[ N ]] (n) = N © O. Nierstrasz 8. 12

PS — Denotational Semantics Semantic Domains In order to define semantic mappings of programs and their features to their mathematical denotations, the semantic domains must be precisely defined: data Bool = True | False (&&), (||) : : Bool -> Bool False && x = False True && x = x False || x =x True || x = True not : : Bool -> Bool not True = False not False = True © O. Nierstrasz 8. 13

PS — Denotational Semantics Data Structures for Abstract Syntax We can represent programs in our calculator language as syntax trees: data Program = On Expr. Sequence data Expr. Sequence = Total Expression Expr. Sequence | Total. Off Expression data Expression = Plus Expression | Times Expression | If Expression | Last. Answer | Braced Expression | N Int © O. Nierstrasz 8. 14

PS — Denotational Semantics Representing Syntax The test program “ON 4 * ( 3 + 2 ) TOTAL OFF” can be parsed as: 4 Prog Stmt 3 * () ON TOTAL OFF + 2 And represented as: test = On (Total. Off (Times (Braced (N 4) (Plus (N 3) (N 2))))) © O. Nierstrasz 8. 15

PS — Denotational Semantics Implementing the Calculator We can implement our denotational semantics directly in a functional language like Haskell: pp : : Program -> [Int] pp (On s) = ss s 0 ss : : Expr. Sequence -> Int -> [Int] ss (Total e s) n = let n' = (ee e n) in n' : (ss s n') ss (Total. Off e) n = (ee e n) : [ ] ee : : Expression -> Int ee (Plus e 1 e 2) n = (ee e 1 n) + (ee e 2 n) ee (Times e 1 e 2) n = (ee e 1 n) * (ee e 2 n) ee (If e 1 e 2 e 3) n | (ee e 1 n) == 0 = (ee e 2 n) | otherwise = (ee e 3 n) ee (Last. Answer) n =n ee (Braced e) n = (ee e n) ee (N num) n = num © O. Nierstrasz 8. 16

PS — Denotational Semantics Roadmap > Syntax and Semantics > Semantics of Expressions > Semantics of Assignment > Other Issues © O. Nierstrasz 8. 17

PS — Denotational Semantics A Language with Assignment Prog : : = Cmd '. ' Cmd : : = Cmd 1 '; ' Cmd 2 | 'if' Bool 'then' Cmd 1 'else' Cmd 2 | Id ': =' Exp : : = Exp 1 '+' Exp 2 | Id | Num Bool : : = Exp 1 '=' Exp 2 | 'not' Bool Example: z : = 1 ; if a = 0 then z : = 3 else z : = z + a. Input number initializes a; output is final value of z. © O. Nierstrasz 8. 18

PS — Denotational Semantics Representing abstract syntax trees Data Structures: data Program data Command data Expression data Boolean. Expr type Identifier © O. Nierstrasz = = | | = | = Dot Command CSeq Command Assign Identifier Expression If Boolean. Expr Command Plus Expression Id Identifier Num Int Equal Expression Not Boolean. Expr Char 8. 19

PS — Denotational Semantics An abstract syntax tree Example: z : = 1 ; if a = 0 then z : = 3 else z : = z + a. Is represented as: Dot (CSeq (Assign 'z' (Num 1)) (If (Equal (Id 'a') (Num 0)) (Assign 'z' (Num 3)) (Assign 'z' (Plus (Id 'z') (Id 'a'))) ) ) © O. Nierstrasz 8. 20

PS — Denotational Semantics Modelling Environments A store is a mapping from identifiers to values: type Store = Identifier -> Int newstore : : Store newstore id = 0 update : : Identifier -> Int -> Store update id val store = store' where store' id' | id' == id = val | otherwise = store id' © O. Nierstrasz 8. 21

PS — Denotational Semantics Functional updates Example: env 1 = update 'a' 1 (update 'b' 2 (newstore)) env 2 = update 'b' 3 env 1 ‘b’ 2 env 2 ‘b’ 3 env 2 ‘z’ 0 © O. Nierstrasz 8. 22

PS — Denotational Semantics of assignments pp : : Program -> Int pp (Dot c) n = (cc c (update 'a' n newstore)) ‘z’ cc : : Command -> Store cc (CSeq c 1 c 2) s cc (Assign id e) s cc (If b c 1 c 2) s = cc c 2 (cc c 1 s) = update id (ee e s) s = ifelse (bb b s) (cc c 1 s) (cc c 2 s) ee : : Expression -> Store -> Int ee (Plus e 1 e 2) s ee (Id id) s ee (Num n) s = (ee e 2 s) + (ee e 1 s) = s id =n bb : : Boolean. Expr -> Store -> Bool bb (Equal e 1 e 2) s bb (Not b) s = (ee e 1 s) == (ee e 2 s) = not (bb b s) ifelse : : Bool -> a ifelse True x y ifelse False x y =x =y © O. Nierstrasz 8. 23

PS — Denotational Semantics Running the interpreter src 1 = "z : = 1 ; if a = 0 then z : = 3 else z : = z + a. " ast 1 = Dot (CSeq (Assign 'z' (Num 1)) (If (Equal (Id 'a') (Num 0)) (Assign 'z' (Num 3)) (Assign 'z' (Plus (Id 'z') (Id 'a'))))) pp ast 1 10 11 © O. Nierstrasz 8. 24

PS — Denotational Semantics Roadmap > Syntax and Semantics > Semantics of Expressions > Semantics of Assignment > Other Issues © O. Nierstrasz 8. 25

PS — Denotational Semantics Practical Issues Modelling: > Errors and non-termination: — need a special “error” value in semantic domains > Branching: — semantic domains in which “continuations” model “the rest of the program” make it easy to transfer control > Interactive input > Dynamic typing >. . . © O. Nierstrasz 8. 26

PS — Denotational Semantics Theoretical Issues What are the denotations of lambda abstractions? > need Scott’s theory of semantic domains What are the semantics of recursive functions? > need least fixed point theory How to model concurrency and non-determinism? > abandon standard semantic domains > use “interleaving semantics” > “true concurrency” requires other models. . . © O. Nierstrasz 8. 27

PS — Denotational Semantics What you should know! What is the difference between syntax and semantics? What is the difference between abstract and concrete syntax? What is a semantic domain? How can you specify semantics as mappings from syntax to behaviour? How can assignments and updates be modelled with (pure) functions? © O. Nierstrasz 8. 28

PS — Denotational Semantics Can you answer these questions? Why are semantic functions typically higher-order? Does the calculator semantics specify strict or lazy evaluation? Does the implementation of the calculator semantics use strict or lazy evaluation? Why do commands and expressions have different semantic domains? © O. Nierstrasz 8. 29

ST — Introduction License http: //creativecommons. org/licenses/by-sa/3. 0/ Attribution-Share. Alike 3. 0 Unported You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page. Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights. © Oscar Nierstrasz 1. 30