500 likes | 1.8k Views
University of Central Florida COP 4020: Programming Languages I Summer 2006 Lecture Notes by: Adam Brooks and Abraham Hedtke. Axiomatic Semantics. Axiomatic Semantics. C.A.R. (Tony) Hoare introduced a formal system of logic to define programming language semantics.
E N D
University of Central Florida COP 4020: Programming Languages I Summer 2006 Lecture Notes by: Adam Brooks and Abraham Hedtke Axiomatic Semantics
Axiomatic Semantics • C.A.R. (Tony) Hoare introduced a formal system of logic to define programming language semantics. • It was defined in conjunction with the development of a method to prove the correctness of programs. • Such proof of correctness, when it can be constructed, shows that a program performs the computation described by its specification.
Axiomatic Semantics • Axiomatic Semantics is: • Based on formal logic (Predicate Calculus) • Original purpose: formal program verification • Axioms on inference rules are defined for each statement type in the language. • This allows transformations of expressions to other expressions; these expressions are called “assertions”.
Axiomatic Semantic Expressions • In a proof, each statement of a program is both preceded and followed by a logical expression. • These logical expressions, rather than the entire state of the abstract machine (operational semantics) are used to specify the meaning of the state. • Each axiomatic expression has a logical precondition, followed by the program statement, which is then followed by the logical postcondition.
Logical Precondition • An assertion before a statement is called a “precondition” denoted as {P} • A precondition states the relationships and constraints among variables that are true at that point of the execution. • Only when the program can verify the precondition assertion can it guarantee the correctness of the postcondition.
Logical Postcondition • An assertion following a statement is called a “post condition” denoted as {Q} • A postcondition states the relationships and values of variables that are guaranteed to be true if the precondition was true after the execution of the program statement.
Axiomatic Expression • Between the precondition and the postcondition, we have the program statement, represented here as C. {P} C {Q} • We can read this statement as: “Whenever P holds of the state before the execution of C, then Q will hold afterwards”.
Examples Assignment statement: {k = 5} k := k+1 {k = 6} Steps to find precondition given the postcondition: {k = 6} postcondition {k+1 = 6} use C to substitute k+1 for k {k = 6-1} solve for k {k = 5} precondition (after simplification)
Examples Assignment statement: { j=3 and k=4 } j := j+k { j=7 and k=4 } Steps to find precondition given the postcondition: {j=7 and k=4} postcondition {j+k=7 and k=4} use C to substitute j+k for j {j=7-4 and k=4} solve for k {j=3 and k=4} precondition (after simplification)
Examples Assignment statement: {a>0} a := a–1 {a≥0} Steps to find precondition given the postcondition: {a≥0} postcondition {a–1≥0} use C to substitute a-1 for a {a≥1} solve for a {a>0} precondition (after simplification)
{P} C {Q} The meaning of the command (C) can be viewed as the order pair <pre,post>, called the “specification of C”. • We say that the command C is correct with respect to the specification if: • The precondition is true • The command halts • The resulting values make the post condition true • By introducing these conditions to the program, we can guarantee correctness of the program.
Weakest Precondition • The Weakest Precondition (WP) is the least restrictive precondition that will still guarantee the post condition. • This concept was developed by Dijkstra in 1976, and been used to simplify the process of generating the precondition statements needed for proofs in Axiomatic Semantics
Example General Precondition: {b > 10} (b is larger than necessary to guarantee Q) a := b + 1 {a > 1} The WP would be: {b > 0} (b cannot be any smaller and still guarantee Q) a := b + 1 {a > 1}
Axioms and Rules of Inference Given an assignment of the form: V = E; And a post condition Q, we use the notation: P = Q[E/V] or P = Q[V->E] or P = QV->E To indicate the substitution of E in place of each free occurrence of V in Q.
Axiomatic Definition of Assignment • This notation enables us to give an axiomatic definition for the assignment command: {Q[V->E]} V = E {Q} Thus out precondition is directly dependent on our post condition, but just replace every instance of E with V.
Example Proof of correctness: {a > 0} {a > 0} => { a ≥ 1} = 0 a := a + 1 {a – 1 ≥ 0} = {Q(a -1)} {a ≥ 0} a = a -1 {a ≥ 0} = {Q(a)}
Sample Problem Compute the weakest precondition of the following statements and post conditions: x = 2 * y – 3 {x > 25} Solution: {2*y – 3 > 25} substitute 2*y-3 for x in {Q} {2 * y > 28} simplify... {y > 14} weakest precondition (WP)
Axioms Used as Proof • A given assignment statement with both precondition and a postcondition can be considered a theorem. • We can say that proof of the correctness of a program is like a proven theorem.
Rules of Inference For an axiomatic specification, we introduce rules of inference that have the form: S1, S2, S3, … , Sn S Interpretation of the notation: If S1, S2, S3, … , Sn have all been verified, we may conclude that S is valid.
Example The sequence of two commands: {P1} S1 {P2} {P2} S2 {P3} {P1} S1 {P2}, {P2} S2 {P3} {P1} S1; S2 {P3} Since S1's {Q} is the same as S2's {P}, we can combine the two statements.
Sample Problem Find the WP for: y = 3*x + 1 x = y + 3 {x < 10} Start from bottom, find S2's WP: {y + 3 < 10} substitute y+3 for x in {Q} {y < 7} S2's WP Now use S2's WP as S1's {Q} to find S1's WP: {3 * x + 1 < 7} substitute (3*x+1) for y in {Q} {3 * x < 6} simplify... {x < 2} weakest precondition (WP)
Sample Problem (continued) Proof using rules of inference: {x < 2} y = 3 * x + 1 {y < 7}, {y < 7} x = y + 3 {x < 10} {x < 2} y = 3 * x + 1; x = y + 3 {x < 10}
The “IF” Command(IF, THEN, ELSE) The IF command involves a choice between alternatives. {P and B} S1 {Q}, {P and (¬B)} S2 {Q} {P} if B then S1else S2endif {Q} Where B represents a Boolean value/expressionchecked in the IF statement. For a statement with no “ELSE”: {P and B} S {Q}, {P and (¬B)} -> {Q} {P} if B then S endif {Q}
Sample Problem Find the WP of the following statements with the given postcondition: IF (x > 0) y = y – 1 ELSE y = y + 1 END IF {y > 0}
Sample Problem (step 1) • Find the WP of S1: y = y -1 {y > 0} {y – 1 > 0} substitute y-1 for y in {Q} {y > 1} WP of S1 (after simplify) Problem:IF (x > 0)y = y – 1 (S1)ELSE y = y + 1END IF{y > 0}
Sample Problem (step 2) • Find the WP of S2: y = y + 1 {y > 0} {y + 1 > 0} substitute y+1 for y in {Q} {y > -1} WP of S2 (after simplify) Problem:IF (x > 0) y = y – 1ELSEy = y + 1 (S2)END IF{y > 0}
Sample Problem (step 3) • Use the rule of consequenceto combine the two rules: S1: {y > 1} S2: {y > -1} {y > -1 > 1} -> {y > 1} {y > 1} WP of entire IF statement
The “WHILE” Commandand Loop Invariant The WHILE command involves the repeated execution of a statement while a specified condition exists. {P and B} S {P} {P} while B do S endwhile {P and (¬B)} Where B represents a Boolean value/expression checked at the start of each iteration of the loop. In this definition P is called the “Loop Invariant”.
WHILE Axiom As we have called P the loop invariant, let us rewrite the while axiom as: {I and B} S {I} {I} while B do S endwhile {I and (¬B)} Where I is the Loop Invariant Thus P becomes the precondition for each pass of the loop, and I is now the precondition for the loop as a whole.
WHILE Axiom • The complete axiomatic description of a WHILE construct requires all of the following to be true: (in which I is the loop invariant) • P => I, the weakest precondition for the while statement must guarantee the truth of I. • {I and B}, the statement does not affect the loop invariant. • {I and (¬B)} => Q, the loop invariant implies the post condition at termination. • The loop terminates (in general, this may be very difficult to prove).
Finding I • It is useful to treat the process of producing the WP as a function: WP(statement, post condition) = precondition • In this way we can step through each layer of the loop as a call to the function.
Sample Problem Find the WP of the following statements with the given postcondition: WHILE(y ≠ x) DO y := y + 1 ENDWHILE {y = x} For 0 iterations: the statement is not executed WP is {y = x}
Sample Problem (continued) For 1 iteration: WP(y = y+1, {y=x}) = {y+1 = x} substitute y+1 for y = {y = x-1} weakest precondition For 2 iterations: WP(y = y+1, {y = x-1}) = {y+1 = x-1} substitute y+1 for y = {y = x-2} weakest precondition
Sample Problem (continued) For 3 iterations: WP(y = y+1, {y = x-2}) = {y+1 = x-2} substitute y+1 for y = {y = x-3} weakest precondition General Case: Through analysis we can see that for each step of the loop the value of x must keep increasing above the value of y to ultimately satisfy the postcondition, thus the value of x will always start out larger than y. {y < x} general WP (one or more iterations)
Sample Problem (continued) Combining {y < x} (one or more iterations) with {y = x} (for zero iterations) we get I = {y ≤ x} Now we must prove that the I we have found for the loop will satisfy all of the rules for the complete axiomatic description of a while loop.(see slide 31 for a review of the rules)
Sample Problem Continued:Proving the Loop Testing the conditions: Rule 1) P => I (given) Rule 2) {I and B} S {I}(general while loop axiom) {y ≤ x and y ≠ x} y = y + 1 {y ≤ x} (plug in I and B) Compute the WP: WP(y = y+1, {y ≤ x}) = {y+1 ≤ x} = {y < x} and {y ≤ x and y ≠ x} => {y < x} proves the assertion
Sample Problem Continued:Proving the Loop Testing the conditions (continued): Rule 3) {I and (¬B)} => Q {y ≤ x and ¬(y ≠ x)} => {y = x} (plug in for I, B, and Q) {(y ≤ x) and (y = x)} => {y = x} (simplify) {y = x} => {y = x} so proven true Rule 4) the loop terminates since x and y are integers and {P} ≡ {I} states that {y ≤ x}, and the loop body increases y with iterations until y is equal to x, it will eventually terminate. proven true
Conclusion • Axiomatic semantics is a powerful tool for research into program correctness/proof. • It provides an excellent framework in which to reason about programs. • It has limited usefulness for either compiler writers or language users.