Announcements Introduction to Axiomatic • Homework 3 due tonight Semantics • Homework 2 is graded Meeting 10, CSCI 5535, Spring 2009 – 13 (mean), 14 (median), out of 21 total, but… – Graduate class: final project is what counts, homeworks are to check understanding – Most difficult: comparing big-step and contextual for IMP with exceptions • Many did not answer the question, rather echoed general comparisons made in class. • “Both your ideas and the clarity with which they are expressed matter.” (like research papers) 2 Questions? Plan for Axiomatic Semantics • History and Motivation (last time) • Assertions (today) • Validity (today) • Derivation Rules (today) • Soundness (next time) • Completeness (next time) 3 4 Axiomatic Semantics One-Slide Summary • An axiomatic semantics consists of: – A language for stating assertions about programs, – Rules for establishing the truth of assertions • Some typical kinds of assertions: – This program terminates A semantics that is appropriate – If this program terminates, the variables x and y have the for arguing program correctness same value throughout the execution of the program – The array accesses are within the array bounds • Some typical languages of assertions – First-order logic – Other logics (temporal, linear, pointer-assertion) – Special-purpose specification languages (SLIC, Z, Larch) 5 6 1 Another Tony Hoare Quote Do you believe this? “It has been found a serious problem to define • Would such language specifications be these languages [ALGOL, FORTRAN, COBOL] useful to you? with sufficient rigor to ensure compatibility among all 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 inference as the ultimately definitive specification of the meaning of the language .” 7 8 Other Applications of Axiomatic Semantics • The project of defining and proving everything formally has not succeeded (at least not yet) • Proving has not replaced testing and debugging • Applications of axiomatic semantics: – Proving the correctness of algorithms (or finding bugs) – Proving the correctness of hardware descriptions (or finding bugs) – “extended static checking” (e.g., checking array bounds) – Proof-carrying code – Documentation of programs and interfaces 9 Notation: Assertions Assertions for IMP {A} c {B} • {A} c {B} is a partial correctness assertion . with the meaning that: – Doesn’t imply termination (= it is valid if c diverges) • [A] c [B] is a total correctness assertion – if A holds in state σ and if <c, σ> ⇓ σ’ meaning that – then B holds in σ’ If A holds in state σ • A is the precondition Then there exists σ’ such that <c, σ> ⇓ σ’ • B is the postcondition and B holds in state σ’ • For example: • Now let us be more formal ( you know you want it!) ≤ { y x } z := x; z := z +1 { y < z } – Formalize the language of assertions, A and B is a valid assertion – Say when an assertion holds in a state • These are called Hoare triples or Hoare assertions – Give rules for deriving Hoare triples 11 12 2 The Assertion Language Semantics of Assertions: • We use first-order predicate logic on top of • Need to assign meanings to our assertions IMP expressions • Relation σσσ AA to say that an assertion ≥ A ::= true | false | e 1 = e 2 | e 1 e2 holds in a given state (= “A is true in σ”) | A Æ A | A Ç A | A ⇒ A | ∀x.A | ∃x.A 1 2 1 2 1 2 – This is well-defined when σ is defined on all variables occurring in A • Note that we are somewhat sloppy in mixing • The relation is defined inductively on logical variables and the program variables the structure of assertions (surprise!) • It relies on the denotational semantics of • All IMP variables implicitly range over integers arithmetic expressions from IMP • All IMP boolean expressions are also assertions 13 14 Formal Definition of Formal Definition of σ true always σ true always σ σ σ σ e1 = e 2 iff e1 = e 2 iff e1 = e2 σ σ σ σ e1 ≥ e2 iff e1 ≥ e2 iff e1 ≥ e2 σ σ σ σ A1 Æ A2 iff A1 Æ A2 iff A1 and A2 σ σ σ σ A1 Ç A2 iff A1 Ç A2 iff A1 or A2 σ σ σ σ A1 ⇒ A2 iff A1 ⇒ A2 iff A1 implies A2 σ ∀x.A iff σ ∀x.A iff ∀n∈Z. σ[x:=n] A σ ∃x.A iff σ ∃x.A iff ∃n∈Z. σ[x:=n] A 15 16 Hoare Triple Semantics Deriving Assertions • Now we can define formally the meaning of a partial • Have a formal mechanism to decide { A } c { B } correctness assertion { A } c { B } – But it is not satisfactory . Why? ∀∀∀σσσ∈∈∈ΣΣΣ. ∀∀∀σσσ’∈∈∈ΣΣΣ. ( σσσ A ÆÆÆ <c, σσσ> ⇓⇓⇓σσσ ’) ⇒⇒⇒ σσσ’ B • and a total correctness assertion [A] c [B] ∀∀∀σσσ∈∈∈ΣΣΣ. σσσ A ⇒⇒⇒∃∃∃ σσσ’∈∈∈ΣΣΣ. <c, σσσ> ⇓⇓⇓σσσ ’ ÆÆÆ σσσ’ B • or even better yet: (explain this to me!) ∀∀∀σσσ∈∈∈ΣΣΣ. ∀∀∀σσσ’∈∈∈ΣΣΣ. ( σσσ A ÆÆÆ <c, σσσ> ⇓⇓⇓σσσ ’) ⇒⇒⇒ σσσ’ B ÆÆÆ ∀∀∀σσσ∈∈∈ΣΣΣ. σσσ A ⇒⇒⇒∃∃∃ σσσ’∈∈∈ΣΣΣ. <c, σσσ> ⇓⇓⇓σσσ ’ 17 18 3 Deriving Assertions • Have a formal mechanism to decide { A } c { B } – But it is not satisfactory – Because {A} c {B} is defined in terms of the operational semantics , we practically have to run the program to verify an assertion – It is impossible to effectively verify the truth of a ∀x. A assertion (check every integer?) • 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 19 Natural Derivation Rules Propositional Rules deduction style • We write ⊢ A when A can be derived ⊢ A ⊢ B ⊢ A Æ B ⊢ A Æ B ÆI ÆE ÆE from basic axioms ( ⊢ A === “we can ⊢ A Æ B ⊢ A 1 ⊢ B 2 prove A” ) ⊢ A ⊢ B ⊢ A ⊢ B ÇI1 ÇI2 • The derivation rules for the judgment ⊢ A Ç B ⊢ A Ç B …… ⊢ A Ç B ⊢ C ⊢ C ⊢ A are the usual ones from first-order ÇE logic with arithmetic ⊢ A ⊢ C … ⊢ B ⊢ A ⇒ B ⊢ A ⇒I ⇒E 21 ⊢ A ⇒ B ⊢ B 22 First-Order Rules Derivation Rules for Hoare Triples ⊢ [a/x]A (a is fresh) ⊢ ∀x.A • Similarly we write ⊢ {A} c {B} when we ∀I ∀E ⊢ ∀x.A ⊢ [e/x]A can derive the triple using derivation rules substitution : “substitute a • There is one derivation rule for each for x in A” ⊢ [a/x]A command in the language Guess: Why … • Plus, the “evil” rule of consequence “evil”? ⊢ [e/x]A ⊢ ∃x.A ⊢ B ∃I ∃E ⊢ A’ ⇒ A ⊢ {A} c {B} ⊢ B ⇒ B’ ⊢ ∃x.A ⊢ B ⊢ {A’} c {B’} 23 24 4 Derivation Rules for Hoare Logic Derivation Rules for Hoare Logic • One rule for each syntactic construct: • One rule for each syntactic construct: ⊢ {A} skip {A} ⊢ {[e/x]A} x := e {A} ⊢ {A} skip {A} ⊢ {[e/x]A} x := e {A} ⊢ { } c1 { } ⊢ { } c2 { } ⊢ {A} c 1 {B} ⊢ {B} c 2 {C} ⊢ {A} c 1; c 2 {C} ⊢ {A} c 1; c 2 {C} ⊢ { } c1 { } ⊢ { } c2 { } ⊢ {A Æ b} c 1 {B} ⊢ {A Æ ¬ b} c 2 {B} ⊢ {A} if b then c 1 else c 2 {B} ⊢ {A} if b then c 1 else c 2 {B} ⊢ { } c { } ⊢ {A Æ b} c {A} ⊢ {A} while b do c { } 25 ⊢ {A} while b do c {A Æ ¬ b} 26 Alternate Hoare Rules Alternate Hoare Rules • For some constructs multiple rules are possible: • For some constructs multiple rules are possible: • (Exercise: these rules can be derived from the • (Exercise: these rules can be derived from the previous ones using the consequence rules) previous ones using the consequence rules) ⊢ {A} x := e { } ⊢ {A} x := e { ∃x0.[x 0/x]A Æ x = [x 0/x]e} (This one is called the “forward” axiom for assignment) (This one is called the “forward” axiom for assignment) ⊢ ⊢ {C} c {A} ⊢ . ⊢ A Æ b ⇒ C ⊢ {C} c {A} ⊢ A Æ ¬ b ⇒ B ⊢ {A} while b do c {B} ⊢ {A} while b do c {B} (C is the loop invariant ) (C is the loop invariant ) 27 28 Example: Assignment • (Assuming that x does not appear in e) Prove that {true} x := e { x = e } Example Verifications ⊢ {true} x := e {x = e} 30 5 Example: Assignment The Assignment Axiom • (Assuming that x does not appear in e) • “Assignment is undoubtedly the most characteristic feature of programming a digital computer, and one Prove that {true} x := e { x = e } that most clearly distinguishes it from other branches of mathematics. It is surprising therefore that the • Assignment Rule: axiom governing our reasoning about assignment is quite as simple as any to be found in elementary ⊢ {e = e} x := e {x = e} logic .” - Tony Hoare because [e/x](x = e) → e = e • Caveats are sometimes needed for languages with • Use Assignment + Consequence: aliasing (the strong update problem): – If x and y are aliased then ⊢ true ⇒ e = e ⊢ {e = e} x := e {x = e} { true } x := 5 { x + y = 10} ⊢ {true} x := e {x = e} is true 31 32 For Next Time • Homework 4 out tonight due Mon Feb 23 • Think about possible projects 33 6.