Lecture 19 Minding Ps Qs Axiomatic Semantics and
- Slides: 18
Lecture 19: Minding Ps & Qs: Axiomatic Semantics and Program Verification It is easier to write an incorrect program than understand a correct one. Alan Perlis CS 655: Programming Languages David Evans University of Virginia 5 April 2001 CS 655: Lecture 19 http: //www. cs. virginia. edu/~evans Computer Science
Operational Semantics • Map to execution of a virtual machine • Depends on informal understanding of machine • Were able to prove that all programs in a language without loops terminate • Awkward notion of equivalence • Hard to prove properties about all possible executions of a program – need to simulate execution 5 April 2001 CS 655: Lecture 19 2
Static Semantics • Can prove properties about simple properties (type checking) easily • Cannot take into account any dynamic properties – Proofs must assume type of reference does not change throughout execution 5 April 2001 CS 655: Lecture 19 3
Axiomatic Semantics • Reason about programs using axioms (mathematical rules about program text fragments) • Depends on informal (almost formal) understanding of logic – Better than depending on informal understanding of Virtual Machine (Operational Semantics) • Allows reasoning about all possible executions • Can prove more interesting properties about programs than static semantics – Can deal with control flow, dynamic properties, etc. 5 April 2001 CS 655: Lecture 19 4
Floyd-Hoare Rules pre-condition post-condition P { code fragment } Q Partial correctness: For all execution states which satisfy P, if the code fragment terminates, the resulting execution state satisfies Q. Total correctness: For all execution states which satisfy P, the code fragment terminates and the resulting execution state satisfies Q. (Sometimes people write: P [ code fragment ] Q. ) 5 April 2001 CS 655: Lecture 19 5
A simple example { true } while true do x : = 1 { 2 + 2 = 5 } Partial correctness: Yes! Since code doesn’t terminate, any post-condition is satisfied. Total correctness: No! Since code doesn’t terminate, no total correctness post-condition could be satisfied. 5 April 2001 CS 655: Lecture 19 6
A Toy Language: Algorel Program : : = Statement : : = Variable : = Expression | Statement ; Statement | while Pred do Statement end Expression : : = Variable | Int. Literal | Expression + Expression | Expression * Expression Pred : : = true | false | Expression <= Expression 5 April 2001 CS 655: Lecture 19 7
Assignment Axiom P[e/x] { x : = e side-effect-free(e) } P P is true after x : = e, iff P with e substituted for x was true before the assignment. 5 April 2001 CS 655: Lecture 19 8
Assignment Example wp { x : = x + 1 } x = 3 P[e/x] { x : = e sef(e) } P wp = (x = 3)[x + 1/x] wp = ((x + 1)= 3) wp = (x = 2) 5 April 2001 CS 655: Lecture 19 9
Weakest Preconditions P{S}Q • Given Q and S, what is the weakest P such that P { S } Q x = 2 { x : = x + 1 } x = 3 • Is there a stronger precondition? • Is there a weaker precondition? • Is there always a weakest precondition for any S and Q? 5 April 2001 CS 655: Lecture 19 10
If Axiom side-effect-free (b) (P b { s 1 } Q) (P b { s 2 } Q) P { if b then s 1 else s 2 } Q 5 April 2001 CS 655: Lecture 19 11
If Example P { if (x < 3) then x : = x + 1 else x : = x – 1 } x 3 5 April 2001 CS 655: Lecture 19 12
If Example side-effect-free (x < 3) (P x < 3 {x : = x + 1} x 3) (P (x < 3) {x : = x – 1} x 3) P { if (x < 3) then x : = x + 1 else x : = x – 1} x 3 weakest-precondition: P = x 3 x 2 5 April 2001 CS 655: Lecture 19 13
An Algorel Program Fragment % Pre-condition: ? while n <= x do n : = n + 1; result : = result * n; end % Post-condition: result = x! 5 April 2001 CS 655: Lecture 19 14
Goal: find weakest pre-condition P & x 0 = x { while n <= x do n : = n + 1; result : = result * n; end } result = x 0! 5 April 2001 CS 655: Lecture 19 Elevator speech 15
Rule for while P Inv { Pred } Inv & Pred { Statement } Inv (Inv & ~Pred) Q while Pred do Statement end terminates P { while Pred do Statement end } Q 5 April 2001 CS 655: Lecture 19 16
What can go wrong? • Invariant too weak – Can’t prove (Inv & ~Pred) Q • Invariant too strong – Can’t prove Inv & Pred { Statement } Inv – Can’t prove P Inv (for sufficiently weak P) 5 April 2001 CS 655: Lecture 19 17
Summary • Once you have the right invariant, proving partial correctness is tedious but easy – Computers can do this quickly • Picking the right invariant is hard and not well understood – Computers can do this slowly in special circumstances, often need help (from programmer or language designer) • Next time: Proof-Carrying Code – Can quickly and automatically prove interesting properties (type safety, memory safety, etc. ) about arbitrary code if you are given the right invariants 5 April 2001 CS 655: Lecture 19 18
- Minding the gap introduction
- Compare procedural semantics and declarative semantics.
- Axiomatic definition of probability
- 01:640:244 lecture notes - lecture 15: plat, idah, farad
- Axiomatic design example
- Axiomatic design
- What are the undefined terms in the axiomatic system
- Axiomatic design
- The axiomatic method
- Axiomatic system of geometry
- Definition in an axiomatic system
- Axiomatic antonym
- Axiomatic definition of probability
- Semantics reference and sense
- Syntax vs semantics
- Pragmatics vs semantics
- Sense and reference in semantics
- Semantic meaning and examples
- Difference between semantics and pragmatics