6.1.1. Example: Swapping🔗

Consider the following program, which swaps the values of two variables using addition and subtraction, instead of by assigning to a temporary variable.

X := X + Y;
Y := X - Y;
X := X - Y

We can give a proof, in the form of decorations, that this program is correct — i.e., it really swaps X and Y — as follows.

WORK IN CLASS

6.1.2. Example: Simple Conditionals🔗

Here's a simple program using conditionals, along with a possible specification:

{{ True }}
  if X ≤ Y then
    Z := Y - X
  else
    Z := X - Y
  end
{{ Z + X = Y ∨ Z + Y = X }}

Let's turn it into a decorated program...

WORK IN CLASS

6.1.3. Example: Reduce to Zero🔗

Here is a very simple while loop with a simple specification:

{{ True }}
  while (X ≠ 0) do
    X := X - 1
  end
{{ X = 0 }}

WORK IN CLASS

6.1.4. Example: Division🔗

Let's do one more example of simple reasoning about a loop.

The following Imp program calculates the integer quotient and remainder of parameters m and n.

X := m;
Y := 0;
while n ≤ X do
  X := X - n;
  Y := Y + 1
end;

If we replace m and n by concrete numbers and execute the program, it will terminate with the variable X set to the remainder when m is divided by n and Y set to the quotient.

Here's a possible specification:

{{ True }}
  X := m;
  Y := 0;
  while n ≤ X do
    X := X - n;
    Y := Y + 1
  end
{{ n * Y + X = m ∧ X < n }}

WORK IN CLASS

6.1.5. From Decorated Programs to Formal Proofs🔗

From an informal proof in the form of a decorated program, it is "easy in principle" to read off a formal proof using the Lean theorems corresponding to the Hoare Logic rules, but these proofs can be a bit long and fiddly.

For example...

A little more (OK, quite a bit more) tactic fanciness for helping deal with the boring parts of the process of proving assertions:

This makes it pretty easy to verify reduce_to_zero:

This example shows that it is conceptually straightforward to read off the main elements of a formal proof from a decorated program. Indeed, the process is so straightforward that it can be automated, as we will see next.

6.2.1. Syntax🔗

The first thing we need to do is to formalize a variant of the syntax of Imp commands that includes embedded assertions, which we'll call "decorations." We call the new commands decorated commands, or dcoms.

The choice of exactly where to put assertions in the definition of dcom is a bit subtle. The simplest thing to do would be to annotate every dcom with a precondition and postcondition — something like this...

But this would result in very verbose decorated programs with a lot of repeated annotations: a simple program like skip;skip would be decorated like this,

{{p}} ({{p}} skip {{p}}) ; ({{p}} skip {{p}}) {{p}}

with pre- and post-conditions around each skip, plus identical pre- and post-conditions on the semicolon!

In other words, we don't want both preconditions and postconditions on each command, because a sequence of two commands would contain redundant decorations — the postcondition of the first likely being the same as the precondition of the second.

Instead, our formal syntax of decorated commands will omit preconditions whenever possible and embed just postconditions.

• The skip command, for example, is decorated only with its postcondition

skip {{ q }}

on the assumption that the precondition will be provided by somebody else.

We carry the same assumption through the other syntactic forms: each decorated command is assumed to carry its own postcondition within itself but take its precondition from its context in which it is used.

• Sequences d₁ ; d₂ need no additional decorations.

Why?

Because inside d₂ there will be a postcondition, which also serves as the postcondition of d₁;d₂.

Similarly, inside d₁ there will also be a postcondition, which additionally serves as the precondition for d₂.

• An assignment X := a is decorated only with its postcondition:

X := a {{ q }}

• A conditional if b then d₁ else d₂ is decorated with a postcondition for the entire statement, as well as preconditions for each branch:

if b then {{ p₁ }} d₁ else {{ p₂ }} d₂ end {{ q }}

• A loop while (b) {d} is decorated with its final postcondition plus a precondition for the body:

while (b) {{ p }} { d } {{ q }}

The postcondition embedded in d serves as the loop invariant.

• Implications ->> can be added as decorations either for a precondition...

->> {{ p }} d

...or for a postcondition:

d ->> {{ q }}

The former is waiting for another precondition to be supplied by the context; the latter relies on the postcondition already embedded in d.

Putting this all together gives us the formal syntax of decorated commands:

Lean keeps decorated-command notation in its own syntax category, dcom, so it can coexist with the ordinary Imp command syntax.

(We then need to redefine all our Notations to get nice concrete syntax for dcom.)

To provide the initial precondition that goes at the very top of a decorated program, we introduce a new type decorated:

To inspect the fully elaborated term behind this notation, put set_option pp.all true in before a #check or #print command.

The formal definitions can use either constructors directly or the decorated-command notation introduced above.

An example decorated program that decrements X to 0:

It is easy to go from a dcom to a com by erasing all annotations.

It is also straightforward to extract the precondition and postcondition from a decorated program.

It would be nice to use <{ ... }> notations
in this definition and the ones below...
     | <{ skip {{p}} }>        => p
     | <{ _; d₂ }>             => post d₂
     | <{ _ := _ {{q}} }>      => q

We can then express what it means for a decorated program to be correct as follows:

For example:

The outer Hoare triple of a decorated program is just a Prop; thus, to show that it is valid, we need to produce a proof of this proposition.

We will do this by extracting "proof obligations" from the decorations sprinkled throughout the program.

These obligations are often called verification conditions, because they are the facts that must be verified to see that the decorations are locally consistent and thus constitute a proof of validity of the outer triple.

6.2.2. Extracting Verification Conditions🔗

The function DCom.VerificationConditions takes a decorated command d together with a precondition p and returns a proposition that, if it can be proved, implies that the triple

{{p}} d.erase {{d.postcondition}}

is valid.

It does this by walking over d and generating a big conjunction that includes

• local consistency checks for each form of command, plus

• uses of ->> to bridge the gap between the assertions found inside a decorated command and the assertions imposed by the external precondition; these uses correspond to applications of the consequence rule.

Local consistency is defined as follows...

• The decorated command

skip {{q}}

is locally consistent with respect to a precondition p if p ->> q.

• The sequential composition of d₁ and d₂ is locally consistent with respect to p if d₁ is locally consistent with respect to p and d₂ is locally consistent with respect to the postcondition of d₁.

• An assignment

X := a {{q}}

is locally consistent with respect to a precondition p if:

p ->> q [X ↦ a]

• A conditional

if b then {{p₁}} d₁ else {{p₂}} d₂ end {{q}}

is locally consistent with respect to precondition p if

(1) p ∧ b ->> p₁

(2) p ∧ b ->> p₂

(3) d₁ is locally consistent with respect to p₁

(4) d₂ is locally consistent with respect to p₂

(5) d₁.postcondition ->> q

(6) d₂.postcondition ->> q

• A loop

while (b) {{{q}} d} {{r}}

is locally consistent with respect to precondition p if:

(1) p ->> d.postcondition

(2) d.postcondition ∧ b ->> q

(3) d.postcondition ∧ b ->> r

(4) d is locally consistent with respect to q

• A command with an extra assertion at the beginning

->> {{q}} d

is locally consistent with respect to a precondition p if:

(1) p ->> q

(2) d is locally consistent with respect to q

• A command with an extra assertion at the end

d ->> {{q}}

is locally consistent with respect to a precondition p if:

(1) d is locally consistent with respect to p

(2) d.postcondition ->> q

With all this in mind, we can write a verification condition generator that takes a decorated command and reads off a proposition saying that all its decorations are locally consistent.

Formally, since a decorated command is "waiting for its precondition" the main VC generator takes a dcom plus a given precondition as arguments.

The following key theorem states that DCom.VerificationConditions does its job correctly. Not surprisingly, each of the Hoare Logic rules plays a critical role at some point in the proof.

Now that all the pieces are in place, we can define what it means to verify an entire program.

And this brings us to the main theorem of this section:

6.2.3. More Automation🔗

The propositions generated by DCom.VerificationConditions are fairly big and contain many conjuncts that are essentially trivial.

HIDE: MRC'20: The conditions here used to be just [Eval]ed instead
of being duplicated in a comment.  They were actually incorrect
because of changes to notation.  Putting them in as an [Example]
will force us to keep them up-to-date. APT20: Yes, but but stating
this an equality completely misses the point about verify_assertion! So I
changed things back.

Fortunately, our verify_assertion tactic can generally take care of most (or sometimes all) of them.

To automate the overall process of verification, we can use verification_correct to extract the verification conditions, use verify_assertion to verify them as much as it can, and finally tidy up any remaining bits by hand.

Here's the final, formal proof that decWhile is correct.

6.3.1. Example: Slow Subtraction🔗

The following program subtracts the value of X from the value of Y by repeatedly decrementing both X and Y. We want to verify its correctness with respect to the pre- and postconditions shown:

{{ X = m ∧ Y = n }}
  while X ≠ 0 do
    Y := Y - 1;
    X := X - 1
  end
{{ Y = n - m }}

To verify this program, we need to find an invariant Inv for the loop. As a first step we can leave Inv as an unknown and build a skeleton for the proof by applying the rules for local consistency, working from the end of the program to the beginning, as usual, and without doing any thinking at all yet.

This leads to the following skeleton:

(1)    {{ X = m ∧ Y = n }}  ->>                   (a)
(2)    {{ Inv }}
         while X ≠ 0 do
(3)              {{ Inv ∧ X ≠ 0 }}  ->>          (c)
(4)              {{ Inv [X ↦ X-1] [Y ↦ Y-1] }}
           Y := Y - 1;
(5)              {{ Inv [X ↦ X-1] }}
           X := X - 1
(6)              {{ Inv }}
         end
(7)    {{ Inv ∧ ¬ (X ≠ 0) }}  ->>                (b)
(8)    {{ Y = n - m }}

Examining this skeleton, we can see that any valid Inv will have to respect three conditions:

• (a) it must be weak enough to be implied by the loop's precondition, i.e., (1) must imply (2);

• (b) it must be strong enough to imply the program's postcondition, i.e., (7) must imply (8);

• (c) it must be preserved by a single iteration of the loop, assuming that the loop guard also evaluates to true, i.e., (3) must imply (4).

WORK IN CLASS (by filling in the previous template)

6.3.2. Exercise: Slow Assignment🔗

6.3.3. Example: Parity🔗

6.3.4. Example: Finding Square Roots🔗

6.3.5. Example: Squaring🔗

6.3.6. Exercise: Factorial🔗

HIDE: LY: Many are tempted to use division in their propositions here,
with the loop invariant [Y = m!/X!].
Informally, such a decorated program can be correct if we assume
they use real division (in q or r). The issue is that formally in Rocq,
the notation / is also in scope and means integer division, so a pedantic
interpretation would mark those answers wrong, even though that is most
likely *not* what students intended (thus making the grading unfair).
Should we explicitly forbid use of division for this exercise?
(I added a note to that effect in the problem statement).

MRC'20: I strengthened your note so that it explicitly advises
against division (and subtraction).

6.3.7. Exercise: Minimum🔗

6.3.8. Exercise: Two Loops🔗

6.3.9. Exercise: Power Series🔗

This is again a program schema rather than a program.  Why not...
[[
      {{ True }}
    X := 0;
    Y := 1;
    Z := 1;
    while X ≠ W do
      Z := 2 * Z;
      Y := Y + Z;
      X := X + 1
    end
      {{ Y = 2 ^ (W + 1) - 1 }}
]]
   ...?

   BCP 21: Ditto my response above.  IMO this is not a problem.