Axiomatic Semantics The meaning of a program is defined by a formal system that allows one to deduce true properties of that program. No specific meaning.

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.
Reasoning About Code; Hoare Logic, continued
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic.
Axiomatic Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 17.
Partial correctness © Marcelo d’Amorim 2010.
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.
Dynamic semantics Precisely specify the meanings of programs. Why? –programmers need to understand the meanings of programs they read –programmers need.
Simple Example {i = 0} j := i * i {j < 100} Can we ‘verify’ this triple? Only if we know the semantics of assignment.
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
1 Discrete Structures Lecture 29 Predicates and Programming Read Ch
Predicate Transformers
Program Proving Notes Ellen L. Walker.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
Announcements We are done with homeworks Second coding exam this week, in recitation –Times will be posted later today –If in doubt, show up for your regular.
CSE 331 Software Design & Implementation Dan Grossman Winter 2014 Lecture 2 – Reasoning About Code With Logic 1CSE 331 Winter 2014.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
CS 355 – Programming Languages
Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLine’s CSE 503, Software Engineering University of Washington 26 Apr 2004.
Axiomatic Semantics Dr. M Al-Mulhem ICS
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
Describing Syntax and Semantics
Floyd Hoare Logic. Semantics A programming language specification consists of a syntactic description and a semantic description. Syntactic description:symbols.
Semantics “Semantics” has to do with the meaning of a program. We will consider two types of semantics: –Static semantics: semantics which can be enforced.
Reading and Writing Mathematical Proofs
1 Programming Languages (CS 550) Lecture 9 Summary Introduction to Formal Semantics Jeremy R. Johnson TexPoint fonts used in EMF. Read the TexPoint manual.
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
1 Section 8.2 Program Correctness (for imperative programs) A theory of program correctness needs wffs, axioms, and inference rules. Wffs (called Hoare.
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.
Hoare Logic LN chapter 5, 6 but without 6.8, 6.12, 6.13 (to be discussed later) Hoare Logic is used to reason about the correctness of programs. In the.
11/22/2016IT 3271 A formal system:Axioms and Rules, for inferring valid specification x := m; y := n; while ¬(x=y) do if x>y then x := x-y else y := y-x.
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
CSE 331 Software Design & Implementation
Hoare Logic LN chapter 5, 6 but without 6. 8, 6. 12, 6
Hoare-style program verification
Mathematical Structures for Computer Science Chapter 1
Reasoning About Code; Hoare Logic
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Semantics In Text: Chapter 3.
Section 1: Code Reasoning
Axiomatic Verification I
Formal Methods in software development
Predicate Transformers
Formal Methods in software development
Output Variables {true} S {i = j} i := j; or j := i;
Axiomatic Verification I
Program correctness Axiomatic semantics
Program Verification with Hoare Logic
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

Axiomatic Semantics The meaning of a program is defined by a formal system that allows one to deduce true properties of that program. No specific meaning is attached to any particular program by such a system. The task of determining which properties are of interest is left to the programmer. In this setting, we are interested in assertions about program state (in particular values of program variables). Each such assertion can be couched as what’s known as a Hoare triple (after C.A.R. Hoare) {P}S{Q} which is interpreted as follows: Assertion Q will hold in the state yielded immediately upon termination of statement S when executed in state satisfying assertion P. By way of example, consider the following: { x = A } x := x + 1 { x = A + 1} Hoare triples are typically used to express partial correctness of a program, however, one can use them to specify the conditions under which a program will terminate.

Weakest Preconditions To adequately describe the semantics of a programming language construct C, we can’t just manufacture a few true Hoare triples, we must have some plan for describing exactly what we want to say about a program’s behavior. An assertion R is said to be weaker than assertion P if the truth of P implies the truth of R, written P→R (equivalently R or not(P)). Example: x >0 is weaker than x = 3. The program proving game is played as follows: –We know what program construct C we are using. –We know what assertion Q we want to be true after C terminates. –We use the proof system to find out what absolutely must be true before executing C and nothing more, that is we find the weakest precondition of C that will yield Q, wp(C,Q). Then we know that if we execute C in any state P such that P→wp(C,Q), then Q will be true when C terminates.

General Properties of wp (not specific to any language) Law of the Excluded Miracle wp(C,false) = false Note that if false is true, we can prove anything! Distributivity of Conjunction wp(C,P and Q) = wp(C,P) and wp(C,Q) Law of Monotonicity if Q→R then wp(C,Q)→wp(C,R) Distributivity of Disjunction wp(C,P) or wp(C,Q) → wp(C,P or Q)

wp Properties Specific to our Simple Language We make a huge leap of faith assuming that all of us already understand some underlying logic that captures all interesting properties of expressions, and note that true assertions P→Q from this logic can be used in our proofs. Statement Lists wp( L 1 ;L 2,Q) = wp( L 1,wp( L 2,Q)) This says weakest preconditions propagate backwards through statement sequences. Assignment Statements wp( I:=E,Q) = Q[ E/I ] The substitution Q[ E/I ] involves substituting the expression E for each free occurrence of I in Q. An occurrence of a variable is said to be bound in an assertion if it is the argument of an existential (  ) or universal (  ) quantifier. An occurrence is free if it is not bound. Consider Q[1/j] when Q has the following two values: –Q = (for all i, a[i] = a[j]) –Q = (for all j, a[i] = a[j]) Now consider applying this: wp(x := x + 1, x = A) = (x = A)[(x + 1)/x] = (x + 1 = A) = (x = A – 1)

If statements If Statements wp(if E then L 1 else L 2 fi,Q) = ( E >0→wp( L 1,Q)) and ( E  0→wp( L 2,Q)) Consider applying this in Louden’s example: wp(if x then x := 1 else x := -1 fi, x = 1) = (x>0→wp(x := 1,x=1)) and (x  0→wp(x := -1,x=1)) = (x>0→1=1) and (x  0→-1=1) Note (x>0→1=1) = (1=1 or not(x>0)) = true Note (x  0→-1=1) = (-1=1 or not(x  0)) = not(x  0) = x>0 Thus wp(if x then x := 1 else x := -1 fi, x = 1) = (x>0→1=1) and (x  0→-1=1) = true and x>0 = x>0

While Statements To precisely define the weakest precondition of a while loop is difficult, we must define it inductively on the number of times the loop may be executed. Thus we have a sequence of assertions H i (while E do L od,Q) each capturing the weakest preconditions satisfying that the loop executes i times and terminates in a state satisfying Q. Consider the sequence of H’s: H 0 (while E do L od,Q) = E  0 and Q H 1 (while E do L od,Q) = E >0 and wp( L, H 0 (while E do L od,Q)) H i+1 (while E do L od,Q) = E >0 and wp( L, H i (while E do L od,Q)) This seems pretty complicated. What should we really do?

{x = X and y = Y} t := x; x := y; y := t; {x = Y and y = X}

Partial Correctness Proofs for Loop Invariants If we have a while loop, while E do L od, and an assertion W satisfying each of the following: 1.W and ( E >0)→wp( L,W) 2.W and ( E  0)→Q 3.P→W then we can conclude that {P} while E do L od{Q} An assertion W satisfying these conditions is known as a loop invariant. Property 1 above guarantees that the truth of the assertion does not vary when the loop body is executed. Note that the loop termination and the invariant alone must be sufficient to satisfy the postcondition. P can be stronger than the invariant, but that won’t affect the postcondition that is provable in this manner.

Choosing a Loop Invariant {n>0} i := n; sum := 0; while i do sum := sum + i; i := i – 1; od {sum = n}