COP4020 Programming Languages

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
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.
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.
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.
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.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
CS 355 – Programming Languages
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.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Describing Syntax and Semantics
Proving Program Correctness The Axiomatic Approach.
Pre/Post Condition Logic 03/06/2013. Agenda Hoare’s Logic Overview Application to Pre/Post Conditions.
Reading and Writing Mathematical Proofs
Proofs of Correctness: An Introduction to Axiomatic Verification Prepared by Stephen M. Thebaut, Ph.D. University of Florida CEN 5035 Software Engineering.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
1 Formal Semantics of Programming Languages “Program testing can be used to show the presence of bugs, but never to show their absence!” --Dijkstra.
Chapter 25 Formal Methods Formal methods Specify program using math Develop program using math Prove program matches specification using.
CS 363 Comparative Programming Languages Semantics.
Program Correctness. 2 Program Verification An object is a finite state machine: –Its attribute values are its state. –Its methods optionally: Transition.
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.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Principle of Programming Lanugages 3: Compilation of statements Statements in C Assertion Hoare logic Department of Information Science and Engineering.
Dr. Naveed Riaz Design and Analysis of Algorithms 1 1 Formal Methods in Software Engineering Lecture # 26.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
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.
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.
Proving Loops Testing debugging and verification
Formal Methods in Software Engineering 1
Mathematical Structures for Computer Science Chapter 1
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.
Axiomatic Verification I
Formal Methods in software development
Predicate Transformers
Formal Methods in software development
Axiomatic Semantics Will consider axiomatic semantics (A.S.) of IMP:
Axiomatic Verification I
Program correctness Axiomatic semantics
Program Verification with Hoare Logic
CIS 720 Lecture 3.
Programming Languages and Compilers (CS 421)
CIS 720 Lecture 3.
Programming Languages 2nd edition Tucker and Noonan
Program Correctness an introduction.
Presentation transcript:

COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen

Assertions and Preconditions Assertions are used by programmers to verify run-time execution An assertion is a logical formula to verify the state of variables and data to ensure safe continuation A failed assertion should stop the program Assertions are placed by programmers explicitly in code assert (len>0); mean = sum/len; By contrast, preconditions state the initial conditions under which an algorithm has been proven correct 7/29/2019 COP4020 Fall 2006 COP4020 Fall 2006

Preconditions, Postconditions and Partial Correctness We will place assertions before and after a command C: { Precondition } C { Postcondition } We say that the command C is partially correct with respect to the <precondition,postcondition> specification, provided that The command C is executed with values that make the precondition true If the command terminates, then the resulting values make the postcondition true Total correctness requires termination 7/29/2019 COP4020 Fall 2006

Assignment Axiom If we view assertions as predicates, the assignment axiom can be stated { P(E) } V := E { P(V) } that is, if we state a property of V after the assignment, then the property must hold for expression E before the assignment We can use substitution to derive the precondition given a postcondition formula P: this is the assignment axiom: { P[VE] } V := E { P } where P[VE] denotes the substitution of V by E in P 7/29/2019 COP4020 Fall 2006

Examples for Assignments { k = 5 } k := k + 1 { k = 6 } (k = 6)[kk+1]  (k+1 = 6)  (k = 5) { j = 3 and k = 4 } j := j + k { j = 7 and k = 4 } (j = 7 and k = 4)[jj+k]  (j+k = 7 and k = 4)  (j = 3 and k = 4) { true } x := 2 { x = 2 } (x = 2)[x2]  (2 = 2)  (true) { a > 0 } a := a - 1 { a > 0 } (a > 0)[aa - 1]  (a - 1 > 0)  (a > 0) Assuming a is int ! { false } y := 1 { y = 2 } No state can satisfy precondition ! = partially correct 7/29/2019 COP4020 Fall 2006

Validity of Assignment Axiom At first glance it seems that working backward from a postcondition is more complicated than necessary and we could use { true } V := E { V = E } However, consider { true } m := m + 1 { m = m + 1} and we find that { m = m + 1 }  { false } assignment equality 7/29/2019 COP4020 Fall 2006

Statement Composition: Sequence Axiom The sequence axiom: { P } C1 { Q } C2 { R } Q is a postcondition of C1 and a precondition for C2 Written as a rule of inference { P } C1 { Q } { Q } C2 { R } { P } C1 ; C2 { R } 7/29/2019 COP4020 Fall 2006

Example Sequencing We usually write the sequencing vertical and insert the assertions between the statements: { i > 0 } k := i + 1; { k > 0 and j = j }  { k > 0 } i := j; { k > 0 and i = j } The rule of inference: { i > 0 } k := i + 1 { k > 0 } { k > 0 } i := j { k > 0 and i = j } { i > 0 } k := i + 1; i := j { k > 0 and i = j } (k > 0)[ki + 1] (k > 0 and i = j)[ij] 7/29/2019 COP4020 Fall 2006

Skip Axiom The ‘skip’ statement is a no-op { P } skip { P } pre- and postconditions are identical 7/29/2019 COP4020 Fall 2006

If-then-else Axiom The if-then-else axiom written vertically: { P } if B then { P and B } C1 { Q } else { P and not B } C2 { Q } end if { Q } 7/29/2019 COP4020 Fall 2006

If-then-else Axiom And as an inference rule: { P and B } C1 { Q } { P and not B } C2 { Q } { P } if B then C1 else C2 end if { Q } 7/29/2019 COP4020 Fall 2006

The if-then-else Weakest Precondition Rule We can derive the weakest precondition P of and if-then-else using: P  (not B or P1) and (B or P2) where P1 is the precondition of C1 given postcondition Q and P2 is the precondition of C2 given postcondition Q Example: { ( x < 0 or x > 0) and (x > 0 or true) }  { true } if x > 0 then { x > 0 } y := x else { 0 > 0 }  { true } y := 0 end if { y > 0 } Compute preconditions P1 and P2 of C1 and C2 7/29/2019 COP4020 Fall 2006

Precondition Strengthening Logical implication ( or ) means stronger condition  weaker condition (more restrictive) (less restrictive) For example: x = y and y = 0  y = 0 x  0  x = 0 or x < 0 or x > 0 x = 0  x > 0 x = y  true false  x = y2 7/29/2019 COP4020 Fall 2006

Using Precondition Strengthening We can always make a precondition stronger than necessary to complete a proof For example, suppose we know that x > 0 and y = 2 at the start of the program: { x > 0 and y = 2}  { x > 0} y := x { y = x and y > 0 } (y = x and y > 0)[yx]  (x = x and x > 0) 7/29/2019 COP4020 Fall 2006

Loops and Loop Invariants A loop-invariant condition is a logical formula that is true before the loop, in the loop, and after the loop An common example: grocery shopping The invariant is: groceries needed = groceries on list + groceries in cart cart := empty; { groceries needed = groceries on list + groceries in cart }  { groceries needed = groceries on list } while grocery list not empty do { groceries needed = groceries on list + groceries in cart and not empty list } add grocery to cart; take grocery off list; { groceries needed = groceries on list + groceries in cart } end do; { groceries needed = groceries on list + groceries in cart and empty list }  { groceries needed = groceries in cart } 7/29/2019 COP4020 Fall 2006

While-loop Axiom The while-loop axiom uses a loop invariant I, which must be determined Invariant cannot generally be automatically computed and must be “guessed” by an experienced programmer { I } while B do { I and B } C { I } end do { I and not B } 7/29/2019 COP4020 Fall 2006

While-loop Example (1) Loop invariant I  (f*k! = n! and k > 0) { n > 0 } k := n; f := 1; while k > 0 do f := f*k; k := k-1; end do { f = n! } Proof that this algorithm is correct given precondition n>0 and postcondition f=n! 7/29/2019 COP4020 Fall 2006

While-loop Example (2) Loop invariant I  (f*k! = n! and k > 0) { n > 0 } k := n; f := 1; { f*k! = n! and k > 0 } while k > 0 do { f*k! = n! and k > 0 and k > 0 } f := f*k; k := k-1; { f*k! = n! and k > 0 } end do { f*k! = n! and k > 0 and k < 0 } { f = n! } Add while-loop preconditions and postconditions based on the invariant 7/29/2019 COP4020 Fall 2006

While-loop Example (3) Use assignment axioms Loop invariant I  (f*k! = n! and k > 0) { n > 0 } k := n; { 1*k! = n! and k > 0 } f := 1; { f*k! = n! and k > 0 } while k > 0 do { f*k! = n! and k > 0 and k > 0 } f := f*k; { f*(k-1)! = n! and k-1 > 0 } k := k-1; { f*k! = n! and k > 0 } end do { f*k! = n! and k > 0 and k < 0 } { f = n! } Use assignment axioms 7/29/2019 COP4020 Fall 2006

While-loop Example (4) Use assignment axioms Loop invariant I  (f*k! = n! and k > 0) { n > 0 } { n! = n! and n > 0 } k := n; { 1*k! = n! and k > 0 } f := 1; { f*k! = n! and k > 0 } while k > 0 do { f*k! = n! and k > 0 and k > 0 } { f*k*(k-1)! = n! and k-1 > 0 } f := f*k; { f*(k-1)! = n! and k-1 > 0 } k := k-1; { f*k! = n! and k > 0 } end do { f*k! = n! and k > 0 and k < 0 } { f = n! } Use assignment axioms 7/29/2019 COP4020 Fall 2006

While-loop Example (5) Loop invariant I  (f*k! = n! and k > 0) { n > 0 }  { n! = n! and n > 0 } k := n; { 1*k! = n! and k > 0 } f := 1; { f*k! = n! and k > 0 } while k > 0 do { f*k! = n! and k > 0 and k > 0 }  { f*k*(k-1)! = n! and k-1 > 0 } f := f*k; { f*(k-1)! = n! and k-1 > 0 } k := k-1; { f*k! = n! and k > 0 } end do { f*k! = n! and k > 0 and k < 0 } { f = n! } Use precondition strengthening to prove the correctness of implications 7/29/2019 COP4020 Fall 2006

While-loop Example (6) Loop invariant I  (f*k! = n! and k > 0) { n > 0 }  { n! = n! and n > 0 } k := n; { 1*k! = n! and k > 0 } f := 1; { f*k! = n! and k > 0 } while k > 0 do { f*k! = n! and k > 0 and k > 0 }  { f*k*(k-1)! = n! and k-1 > 0 } f := f*k; { f*(k-1)! = n! and k-1 > 0 } k := k-1; { f*k! = n! and k > 0 } end do { f*k! = n! and k > 0 and k < 0 }  { f*k! = n! and k = 0 }  { f = n! } Use simplification and logical implications to complete the proof 7/29/2019 COP4020 Fall 2006

Specifications A postcondition specification can by any logical formula A specification that states the input-output requirements of an algorithm is needed to prove correctness A specification that tests a violation can aid in debugging For example (precondition strengthening is disallowed): { (n > 0 or false) and (n < 0 or n = 0) }  { false } if (n < 0) { false } p = 2; else { n = 0 } p = n+1; { p = 1 } k = m / (p-1); if (n < 0) p = 2; else p = n+1; k = m / (p-1); // Error when p = 1 Means: never possible 7/29/2019 COP4020 Fall 2006