Denotational Semantics (Denotational Semantics)

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

Semantics Static semantics Dynamic semantics attribute grammars
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.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap Overview:  Syntax and Semantics  Semantics of Expressions.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
Fall Semantics Juan Carlos Guzmán CS 3123 Programming Languages Concepts Southern Polytechnic State University.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
CS 355 – Programming Languages
Comp 205: Comparative Programming Languages Semantics of Imperative Programming Languages denotational semantics operational semantics logical semantics.
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap  Syntax and Semantics  Semantics of Expressions 
School of Computing and Mathematics, University of Huddersfield CAS810: WEEK 3 LECTURE: LAMBDA CALCULUS PRACTICAL/TUTORIAL: (i) Do exercises given out.
1 Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications.
Concepts of Programming Languages 1 Describing Syntax and Semantics Brahim Hnich Högskola I Gävle
Denotational Semantics Syntax-directed approach, generalization of attribute grammars: –Define context-free abstract syntax –Specify syntactic categories.
CS 330 Programming Languages 09 / 18 / 2007 Instructor: Michael Eckmann.
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
PSUCS322 HM 1 Languages and Compiler Design II Formal Semantics Material provided by Prof. Jingke Li Stolen with pride and modified by Herb Mayer PSU Spring.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
Dec Formal Semantics1 Programming Language Theory Formal Semantics Leif Grönqvist The national Graduate School of Language Technology (GSLT) MSI.
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Describing Syntax and Semantics
Programming Languages Third Edition Chapter 12 Formal Semantics.
Floyd Hoare Logic. Semantics A programming language specification consists of a syntactic description and a semantic description. Syntactic description:symbols.
Programming Language Semantics Denotational Semantics Chapter 5 Part III Based on a lecture by Martin Abadi.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 2: Operational Semantics I Roman Manevich Ben-Gurion University.
1 Programming Languages (CS 550) Lecture 9 Summary Introduction to Formal Semantics Jeremy R. Johnson TexPoint fonts used in EMF. Read the TexPoint manual.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
3.2 Semantics. 2 Semantics Attribute Grammars The Meanings of Programs: Semantics Sebesta Chapter 3.
Chapter 3 Part II Describing Syntax and Semantics.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
Semantics In Text: Chapter 3.
1 / 48 Formal a Language Theory and Describing Semantics Principles of Programming Languages 4.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications Chapter.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Functional Programming
Describing Syntax and Semantics
Spring 2017 Program Analysis and Verification
Denotational Semantics
Spring 2017 Program Analysis and Verification Operational Semantics
Lecture 5 Floyd-Hoare Style Verification
Lecture 2: Axiomatic semantics
Programming Languages 2nd edition Tucker and Noonan
Semantics In Text: Chapter 3.
Defining A Formal Semantics For The Rosetta Specification Language
Predicate Transformers
Chapter 3 Describing Syntax and Semantics.
This Lecture Substitution model
Describing Syntax and Semantics
Program correctness Axiomatic semantics
Lecture 2: Axiomatic semantics
Spring 2016 Program Analysis and Verification Operational Semantics
CIS 720 Lecture 3.
Programming Languages and Compilers (CS 421)
CIS 720 Lecture 3.
Programming Languages 2nd edition Tucker and Noonan
Presentation transcript:

Denotational Semantics (Denotational Semantics)

Formal Semantics What does y:= f(x) + x mean? y is assigned the value of f(x) + x y becomes a pointer to the result of f(x) + x f(x) may or may not have side effects statement is undefined if types aren't equivalent statement is undefined if types aren't compatible etc Need formal semantics to make meanings of programs unambiguous.

Utility of Formal Semantics Handy for: language design proofs of correctness language implementation reasoning about programs providing a clear specification of behavior

Formal Semantics (continued) Tennent: " ... a precise specification of the meanings of programs for use by programmers, language designers and implementers, and in the theoretical investigations of language properties.” Three major approaches: 1) Denotational: define functions that map syntactic structures into mathematical objects (e.g. numbers, truth values & functions) (Algebraic) - considered a component of denotational 2) Operational: formal virtual machine description (VDL, H-Graphs) 3) Axiomatic: development of axioms defining meanings of classic statement types. (Dijkstra, Hoare)

Uses Denotational: Ashcroft and Wadge argue best use is language design. (as opposed to retrofit, as attempted with Ada). Used some for formal verification. Operational: Best for implementation description. Axiomatic: Most often used for formal verification.

Axiomatic Semantics a: antecedent Axioms: c: consequent null: {P} skip {P} assignment: {PE} x:= E {P} where PE is the assertion formed by replacing every occurrence of x in P by E. alternation: {P ^ B} S1 {Q}, {P ^ ØB) S2 {Q} {P} if B then S1 else S2 {Q} iteration: {P ^ B } S {P} {P} while B do S {P ^ ØB} composition: {P1} S1 {P2},{P2} S2 {P3},…,{Pn} Sn {Pn+1} {P1} begin S1, S2, …, Sn end {Pn+1} x x rules of inference

Axiomatic Semantics More axioms: consequence: {P1} S {Q1}, P P1, Q1 Q await: {P ^ B} S {Q} {P} await B then S {Q} cobegin: {P1} S1 {Q1},…, {Pn} Sn {Qn} are interference free {P1 ^ … ^ Pn} cobegin S1 //…// Sn coend {Q1 ^…^ Qn} Uses: Dijkstra’s weakest preconditions Temporal logic

Using Axiomatic Semantics Prove noninterference in the following: {x=0 and y = 0} S: cobegin s1: await true then y:= y + 1 // s2: await true then x:= x + 2 s3: await y>0 then x:= x + y coend {x=3 and y=1}

Denotational Semantics Assigning denotations to language constructs Utilizes domains and functions over domains domains are sets with properties that allow us to deal with questions regarding recursive definitions of functions (over domains) recursive definitions of domains e.g. consider (recursive function over domain) f: Num ® Num -- f: maps numbers into numbers Mathematical recursion

Candidates f’s Two candidate "defining" functions for f: (i) fx = (fx) + 1 (ii) fx = fx Assuming Num = {0,1,2,....}, there is no f for (i) and every f satisfies (ii). In contrast: (iii) fx = (x=0) ® 1, x * f(x-1) uniquely defines f as factorial

Scott’s Theory Scott's (1969) theory of domains ensures every definition is good by: requiring all domains to have an "implicit structure." This requirement guarantees that all equations (e.g. i, ii and iii) have at least one solution. providing direction, using implicit structure, for choosing an "intended" solution from the solutions guaranteed by (a). based on lattices and fixed point theory. e.g. Num consists of 0, 1, 2, ... and undefined - Num^ is called a lifted domain

Defining Moment Thus, (i) and (ii) define f to be undefined and (iii) defines f as fx = x! if x=0, 1, 2, ... and f undefined = undefined Using ^ as a value is an alternative to using partial functions. With ^, all elements in domain have a value. e.g. f undefined = undefined Scott's theory applies as well to recursive definitions of domains. e.g. lists defined in terms of lists

On Defining a Language's Denotational Semantics Three components: Abstract syntax (syntactic domain) list of syntactic categories list of syntactic clauses (a mapping onto immediate constituents) Semantic Domain (Semantic Algebras) domain equations: provide framework for defining denotations sets that are used as value spaces in PL semantics Semantic functions functions that define denotation of constructs semantic clauses

Terms lx.e : A^ ® B^ ::= (lx.e)^ = ^ (lx.e)a = [a/x]e for a ¹ ^ lx.e: Church's lambda notation (seen before) lx.e : A^ ® B^ ::= (lx.e)^ = ^ (lx.e)a = [a/x]e for a ¹ ^ ^-"proper element" lx.e is e.g. of a strict operation non-strict operations allow ^ to be mapped to proper elements (let x = e1 in e2) is a syntactic substitute for (lx.e2)e1 diverge: statement that goes into an infinite loop

More Terms x ® e1 ½ e2: syntactic form for conditional e.g. C[If B THEN C1 ELSE C2] = ls.B[B]s ® C[C1]s ½C[C2]s Expressions in mini-language assumed to have no side effects. e.g. no reads in expressions. [i ® n]s is a function updating expression ([i ® n]s)(i) = n ([i ® n]s)(j) = s(j) " j ¹ i useful for reflecting effects of updating the ith component of a store: ith component changes; rest stays the same update's signature: Id x Nat x Store ® Store

Even More Terms Interpretation of: P[C.] = ln. let s = (update [A] n newstore) in let s' = C[C]s in (access [Z]s') input number is associated with identifier [A] in a new store then program body is evaluated then answer is extracted from store at [Z] (program mapping: Nat ® Nat^ -- ^ is possible because diverge is possible) Clauses for C are all strict in use of store E does not modify store; expression evaluation order is not specified e.g. E[E1]s plus E[E2]s Same for Booleans

A Small Imperative Language Abstract Syntax P Î Program C Î Command E Î Expression B Î Boolean-expr N Î Numeral P ::= C. C ::= C1;C2 | if B then C | if B then C1 else C2 | I:=E | diverge E ::= E1 + E2 | I | N B ::= E1 = E2 | ØB Syntactic categories Syntactic clauses

A Small Imperative Language (cont) Semantic domain . . . Semantic Functions P: Program ® Nat ® Nat^ P[C.] = ln. let s = (update[A] n newstore) in let s’ = C[C]s in (access[Z] s’) C: Command ® Store^ ® Store^ C[C1;C2] = ls. C[C2] (C[C1]s) C[if B then C] = ls. B[B]s ® C[C]s | s C[if B then C1 else C2] = ls. B[B]s ® C[C1]s | C[C2]s C[I:=E] = ls. update [I] (E[E]s) s C[diverge] = ls. ^ functions clauses

A Small Imperative Language (cont) Semantic Functions (cont) E: Expression ® Store ® Nat E[E1+E2] = ls. E[E1]s plus E[E2]s E[I] = ls. access [I] s E[N] = ls. N[N] B: Boolean-expr ® Store ® Tr B[E1=E2] = ls. E[E1]s equals E[E2]s B[ØB] = ls. not B[B]s N: Numeral ® Nat (omitted) note

Semantic Domain Truth Values Domain t Î Tr = B Operations true, false: Tr not: Tr ® Tr Identifiers Domain i Î Id = Identifier Natural numbers Domain n Î Nat = N zero, one, …: Nat plus: Nat x Nat ® Nat equals: Nat x Nat ® Tr Zero order function

Semantic Domain (cont) Store Domain s Î Store = Id ® Nat Operations newstore: Store newstore = li. zero access: Id ® Store ® Nat access = li. ls. s(i) update: Id ® Nat ® Store ® Store update = li. ln. ls. [i ® n]s