Bonus Lecture Introduction to ≠ • Is Optional ( required ) Axiomatic • Thursday, September 14 (= After Next Class) Axiomatic • Starts at 6:15 pm Semantics • Will last two-ish hours (you can leave early) • I will provide pizza, soda, chips (what do you like?) • I will “sit on the table” and comment on PL advances. Good for project ideas, getting the lay of thel and, etc. • Want to hear about something specific? #1 #2 How’s The Aujourd’hui, nous ferons … Homework Going? •History & Motivation • Remember that •Assertions you can’t just define a •Validity meaning function in •Derivation Rules terms of itself – •Soundness you must use some fixed point •Completeness machinery. #3 #4 Review via Class Participation Axiomatic Semantics • Tell Me About Operational Semantics • An axiomatic semantics consists of: – A language for stating assertions about programs, • Tell Me About Structural Induction – Rules for establishing the truth of assertions • Tell Me About Denotational Semantics • Some typical kinds of assertions: – This program terminates – If this program terminates, the variables x and y have • We would also like a semantics that is the same value throughout the execution of the program appropriate for arguing program correctness – The array accesses are within the array bounds Some typical languages of assertions •“Axiomatic Semantics ”, we ’ll call it. • – First-order logic – Other logics (temporal, linear, pointer-assertion) – Special-purpose specification languages (SLIC, Z, Larch) #5 #6 1 History Tony Hoare Quote •“Thus the practice of proving programs • Program verification is almost as old as would seem to lead to solution of three of programming (e.g., Checking a Large the most pressing problems in software and Routine , Turing 1949) programming, namely, reliability , • In the late ’60s, Floyd had rules for flow- documentation , and compatibility . However, charts and Hoare for structured languages program proving, certainly at present, will • Since then, there have been axiomatic be difficult even for programmers of high semantics for substantial languages, and caliber; and may be applicable only to quite many applications simple program designs. ” – ESC/Java, SLAM, PCC, SPARK Ada, … -- C.A.R Hoare, An Axiomatic Basis for Computer Programming ,1969 #7 #8 Edsger Dijkstra Quote Tony Hoare Quote, Mark 2 •“Program testing can be used to •“It has been found a serious problem to define these languages [ALGOL, FORTRAN, COBOL] with show the presence of bugs, but sufficient rigor to ensure compatibility among all never to show their absence !” implementations. ... one way to achieve this would be to insist that all implementations of the language shall satisfy the axioms and rules of inference which underlie proofs of properties of programs expressed in the language. In effect, this is equivalent to accepting the axioms and rules of Qu’est-ce inference as the ultimately definitive specification que c’est? of the meaning of the language .” #9 #10 Other Applications of Axiomatic Assertion Notation Semantics • The project of defining and proving everything {A} c {B} formally has not succeeded (at least not yet) with the meaning that: • Proving has not replaced testing and debugging – if A holds in state σ and if <c, σ> ⇓ σ’ • Applications of axiomatic semantics: – then B holds in σ’ – Proving the correctness of algorithms (or finding bugs) • A is the precondition – Proving the correctness of hardware descriptions (or • B is the postcondition finding bugs) • For example: –“extended static checking ” (e.g., checking array bounds) { y x } z := x; z := z +1 { y < z } – Proof-carrying code is a valid assertion – Documentation of programs and interfaces • These are called Hoare triples or Hoare assertions #11 #12 2 Assertions for IMP The Assertion Language • {A} c {B} is a partial correctness assertion . • We use first-order predicate logic on top of IMP – Does not imply termination (= it is valid if c diverges) expressions • [A] c [B] is a total correctness assertion meaning A :: = true | false | e = e | e ≥ e that 1 2 1 2 | A ∧ A | A ∨ A | A ⇒ A | ∀x.A | ∃x.A If A holds in state σ 1 2 1 2 1 2 Then there exists σ’ such that <c, σ> ⇓ σ’ and B holds in state σ’ • Note that we are somewhat sloppy in mixing logical variables and the program variables • Now let us be more formal (you know you want it!) – Formalize the language of assertions, A and B – Say when an assertion holds in a state • All IMP variables implicitly range over integers – Give rules for deriving Hoare triples • All IMP boolean expressions are also assertions #13 #14 Assertion Judgment Semantics of Assertions • We need to assign meanings to our assertions Formal definition σ • New judgment σ A to say that an assertion true always σ σ σ holds in a given state (= “A is true in σ”) e1 = e 2 iff e1 = e2 σ σ σ – This is well-defined when σ is defined on all e1 ≥ e2 iff e1 ≥ e2 σ σ σ variables occurring in A A1 ∧ A2 iff A1 and A2 σ σ σ • The judgment is defined inductively on the A1 ∨ A2 iff A1 or A2 σ σ σ structure of assertions (surprise!) A1 ⇒ A2 iff A1 implies A2 • It relies on the denotational semantics of σ ∀x.A iff ∀n∈Z. σ[x:=n] A arithmetic expressions from IMP σ ∃x.A iff ∃n∈Z. σ[x:=n] A #15 #16 Hoare Triple Semantics Deriving Assertions • Now we can define formally the meaning of a • Have a formal mechanism to decide { A } c { B } partial correctness assertion { A } c { B } – But it is not satisfactory ∀∀∀σσσ∈∈∈ΣΣΣ. ∀∀∀σσσ’∈∈∈ΣΣΣ. ( σσσ A ∧∧∧ <c, σσσ> ⇓⇓⇓σσσ ’) ⇒⇒⇒ σσσ’ B – Because {A} c {B} is defined in terms of the operational •… and a total correctness assertion [A] c [B] semantics , we practically have to run the program to verify an assertion σσσ ΣΣΣ σσσ σσσ ΣΣΣ σσσ ⇓⇓⇓σσσ σσσ ∀∀∀ ∈∈∈ . A ⇒⇒⇒∃∃∃ ’∈∈∈ . <c, > ’ ∧∧∧ ’ B – It is impossible to effectively verify the truth of a ∀x. A • or even better yet: (explain this to me!) assertion (check every integer?) ∀∀∀σσσ∈∈∈ΣΣΣ. ∀∀∀σσσ’∈∈∈ΣΣΣ. ( σσσ A ∧∧∧ <c, σσσ> ⇓⇓⇓σσσ ’) ⇒⇒⇒ σσσ’ B • Plan: define a symbolic technique for deriving valid ∧∧∧ assertions from others that are known to be valid – We start with validity of first-order formulas ∀∀∀σσσ∈∈∈ΣΣΣ. σσσ A ⇒⇒⇒∃∃∃ σσσ’∈∈∈ΣΣΣ. <c, σσσ> ⇓⇓⇓σσσ ’ #17 #18 3 Derivation Rules Derivation Rules for Hoare Triples • We write ⊢ A when A can be derived from basic Similarly we write {A} c {B} when we axioms ( ⊢ A === “we can prove A ”) • ⊢ • The derivation rules for ⊢ A are the usual ones from can derive the triple using derivation first-order logic with arithmetic: ⊢ A ⇒ B ⊢ A rules ⊢ A ⊢ B ⊢ B • There is one derivation rule for each ⊢ A ∧ B ⊢ [a/x]A (a is fresh) command in the language ⊢ A ⊢ [a/x]A ⊢ ∀x.A • Plus, the evil rule of consequence … … ⊢ B ⊢ ∀x.A ⊢ [e/x]A ⊢ ∃ x.A ⊢ B ⊢ A’ ⇒ A ⊢ {A} c {B} ⊢ B ⇒ B’ ⊢ A ⇒ B ⊢ [e/x]A ⊢ ∃x.A ⊢ B ⊢ {A ’} c {B ’} #19 #20 Derivation Rules for Hoare Logic Alternate Hoare Rules • One rule for each syntactic construct: • For some constructs multiple rules are possible: • (Exercise: these rules can be derived from the previous ones using the consequence rules) ⊢ {A} skip {A} ⊢ {[e/x]A} x := e {A} ⊢ {A} c 1 {B} ⊢ {B} c 2 {C} ⊢ {A} x := e { ∃x0.[x 0/x]A ∧ x = [x 0/x]e} ⊢ {A} c ; c {C} 1 2 (This one is called the “forward” axiom for assignment) ⊢ {A ∧ b} c 1 {B} ⊢ {A ∧ ¬ b} c 2 {B} ⊢ A ∧ b ⇒ C ⊢ {C} c {A} ⊢ A ∧ ¬ b ⇒ B ⊢ {A} if b then c 1 else c 2 {B} ⊢ {A} while b do c {B} ⊢ {A ∧ b} c {A} (C is the loop invariant ) ⊢ {A} while b do c {A ∧ ¬ b} #21 #22 Example: Assignment The Assignment Axiom (Cont.) • (Assuming that x does not appear in e) •“Assignment is undoubtedly the most characteristic feature of programming a digital computer, and Prove that {true} x := e { x = e } one that most clearly distinguishes it from other • Assignment Rule: branches of mathematics. It is surprising therefore that the axiom governing our reasoning about ⊢ {e = e} x := e {x = e} assignment is quite as simple as any to be found in because [e/x](x = e) → e = e elementary logic .” - Tony Hoare • Caveats are sometimes needed for languages with • Use Assignment + Consequence: aliasing (the strong update problem): ⊢ true ⇒ e = e ⊢ {e = e} x := e {x = e} – If x and y are aliased then { true } x := 5 { x + y = 10} ⊢ {true} x := e {x = e} is true #23 #24 4 Example: Conditional Example: Loop • We want to derive that ⊢ {x 0} while x 5 do x := x + 1 { x = 6} D :: ⊢ {true ∧ y 0} x := 1 {x > 0} 1 • Use the rule for while with invariant x 6 D2 :: ⊢ {true ∧ y > 0} x := y {x > 0} ⊢ {true} if y 0 then x := 1 else x := y {x > 0} ⊢ x 6 ∧ x 5 ⇒ x+1 6 ⊢ {x+1 6} x := x+1 { x 6 } ⊢ {x 6 ∧ x 5 } x := x+1 { x 6} ⊢ {x 6} while x 5 do x := x+1 { x 6 ∧ x > 5} • D1 and D 2 were obtained by consequence and assignment. D 1 details: Then finish-off with consequence ⊢ {1 > 0} x := 1 {x > 0} ⊢ true ∧ y 0 ⇒ 1 > 0 • ⊢ x 0 ⇒ x 6 ⊢ D :: {true ∧ y 0} x := 1 {x > 0} 1 ⊢ x 6 ∧ x > 5 ⇒ x = 6 ⊢ {x 6} while … { x 6 ∧ x > 5} ⊢ {x 0} while … {x = 6} #25 #26 Using Hoare Rules Where Do We Stand? We have a language for asserting properties • Hoare rules are mostly syntax directed • of programs • There are three wrinkles: – What invariant to use for while? (fix points, widening) • We know when such an assertion is true – When to apply consequence? (theorem proving) • We also have a symbolic method for deriving How do you prove the implications involved in – assertions meaning consequence? (theorem proving) • This is how theorem proving gets in the picture A σ A {A} c {B} soundness {A} c {B} – This turns out to be doable! symbolic – The loop invariants turn out