Remark. Some material in this lecture is from << Software Foundation >> volume 2.

Last time, we discovered a common pattern in describing a strongest postcondition of an assignment command. That is, given a precondition P, and an assignment command X := E, their postcondition can be:

       There exists an old value x of program variable
       X, such that (1) the precondition P would hold if
       the value of X would be x (2) the value of X is
       result of evaluating the expression E if treating
       all occurrences of X in E as x.

For example, the strongest postcondition of can be: Today, we will describe that in logic formally.

Symbolic substitution

The assertion language

We have seen many assertions. They mainly follow the following syntax rules. P ::= t < t, t = t, t ≤ t, ... | [[ B ]] | P AND P | P OR P | NOT P | EXISTS x, P | FORALL x, P t ::= 0, 1, -1, ... | x | [[ E ]] | t + t | t - t | t * t | ... where x represents logical variables, E represents integer program expressions and B represents boolean integer program expressions. When we define an assertion that

       P would hold if the value of X would be x

or an expression that

       replacing all occurrences of X in E with x

we can complete the construction according to P's (or E's) syntax.

Symbolic substitution in program expressions

Suppose E is an integer-type expression of the programming language, represents the result of replacing every occurence of program variable X with program expression E₀ in E. This result is still an integer-type expression. What is the result of the following symbolic substitution (x is some constant)? x + Y What is the result of the following symbolic substitution? 1 - Y What is the result of the following symbolic substitution? (X - Y) + Y What is the result of the following symbolic substitution? 1 * Y What is the result of the following symbolic substitution? 1 + 1

• (X * Y) [ X ⟼ 1] is 1 * Y , not Y.
• (X + 1) [ X ⟼ 1] is 1 + 1 , not 2.

Remark. 1 * Y and Y are two different program expressions although their values are always the same. We can also apply symbolic substitution on a boolean expression. Specifically, for a boolean-type expression B and an integer-type expression E₀, we use to represent the result of replacing every occurence of program variable X with E₀ in B, e.g. is ! (0 ≤ Y) .

Symbolic substitution in assertions

We can also define symbolic substitution in assertions. We use to represent the result of replacing every occurence of program variable X with program expression E₀ in assertion P. For example, are In other words, the effect of symbolic substitution on an assertion P is applying substitution on those program expressions mentioned in P.

Assignment rule (forward)

The following axiom describes the behavior of assignment commands.

Write down the postcondition described by hoare_asgn_fwd. EXISTS x₀, [[x₀]] = x AND [[Y]] = y AND [[TEMP]] = [[x]] Write down the postcondition described by hoare_asgn_fwd. EXISTS x₀, 0 ≤ [[Y]] AND [[X]] = [[Y]] Write down the postcondition described by hoare_asgn_fwd. EXISTS x₀, n * [[Y]] + [[x₀]] = m AND 0 ≤ [[x₀]] AND [[n ≤ x₀]] AND [[X]] = [[x₀ - n]] Write down the postcondition described by hoare_asgn_fwd. EXISTS y₀, n * [[y₀]] + [[X]] + n = m AND 0 ≤ [[X]] AND [[Y]] = [[y₀ + 1]] Write down the postcondition described by hoare_asgn_fwd. EXISTS x₀, [[x₀]] = x AND [[Y]] = y AND [[X]] = [[x₀ + Y]]

Assignment rule (backward)

When C. A. R. Hoare first proposed Hoare logic for program correctness proof in 1960s, the assignment rule is not in the forward direction; it was in the backward direction. Robert W. Floyd proposed forward assignment rule later. Due to this reason, people also use the nomenclature "Floyd-Hoare" logic sometimes. (Another reason is that the original ideas of Hoare logic were seeded by Floyd's work of a similar system for flowcharts.)

Write down the precondition described by hoare_asgn_bwd. [[X + Y]] = x + y AND [[Y]] = y Write down the precondition described by hoare_asgn_bwd. n * [[Y + 1]] + [[X]] = m AND 0 ≤ [[X]]

Consequence rule

Summary: axiomatic semantics

Coq proof time! Now, we are able to prove a nicer Hoare triple with simpler hypothese.

After eliminating the first assignment command using hoare_seq and hoare_asgn_fwd, we see the substitution symbol and the existential quantifier in our precondition. Our library PL.Imp provided the two tactics to simplify such assertions.

Now we try to prove the same Hoare triple again with forward proof style.

These two tactics assert_subst and assert_simpl can also simplify assertions in assumptions

It is unfortunate that we cannot achieve a Hoare triple for the while loop here using H₂ and hoare_while because the assertion that loop condition is true has been simplified into n ≤ [[X]] . Thus, we assert the triple that we want to prove.

After assert, we first prove the asserted triple.

We then prove the original proof goal with an extra assumption—-the asserted triple H.

Derived proof rules and programmable proof tactics

We know that an assertion can always derive itself. This property is called derives_refl in our Imp library.

Using it, we can derive two specialized consequence rule. The first one is a single-sided consequence rule for preconditions.

Similarly, we have a single-sided consequence rule for postconditions as well.

Since we prove these two rules from primary rules, we call them derived rules (导出规则). There are other derived proof rules. They can be useful for some special situations. The following rule is a weaker version of hoare_if (we have shown why it is weak in our previous lectures). We can derive it from our primary hoare_if rule now. But this proof is based on the following properties of AND.

Also, we have seen a lot of examples, in which we use hoare_seq and hoare_asgn_fwd together when the first command is an assignment. We can pack them together:

What if the assignment is the only command? We have also seen a combination of hoare_asgn_fwd and hoare_consequence.

These derived rule can make Coq formalized proofs shorter; and more importantly, they help to describe how we understand Hoare logic proofs. We do not apply proof rules one by one in our mind, we use proof rule "combos" instead. Now, let's redo our proofs about swapping.

Decorated program as informal Hoare logic proof

The beauty of Hoare Logic is that it is compositional （可组合的）: the structure of proofs exactly follows the structure of programs. This suggests that we can record the essential ideas of a proof by "decorating" a program with appropriate assertions on each of its commands. In <<software foundation>>, such informal proofs are called decorated programs. In other text books or programming language literature, they are also called annotated programs or commented programs (带注释程序）. Here are two sample decorated programs. Sample 1 Sample 2

Exercises

Exercise: 3 stars, standard (remainder_only)

In the this task, you can write hypothese about assignment commands without proving them.

Exercise: 2 stars, standard (reduce_to_zero_alter1)

You are only allowed write assertion derivations as hypotheses in this exercise.

Hint: the following decorated program shows a proof skeleton.

Exercise: 3 stars, standard (reduce_to_zero_alter2)

You are only allowed write assertion derivations as hypotheses in this exercise.