Proof of correctness of an imperative summation algorithm, using weakest preconditions. We investigate a few different invariants and see how different versions lead to proofs and failures.

It is instructive to look at several proof attempts to see what can go wrong and how the weakest-precondition engine behaves.

Always false invariant

Let's see what happens if we have an always false invariant. Clearly, this will not do the job, but it is instructive to see the output. For this exercise, we are only interested in partial correctness (to see the impact of the invariant only), so we will simply use Nothing for the measures.

>>> import Control.Monad (void)
>>> let invariant _ = sFalse
>>> void $ correctness invariant Nothing
Following proof obligation failed:
==================================
  Invariant for loop "i < n" fails upon entry:
    SumS {n = 0, i = 0, s = 0}

When the invariant is constant false, it fails upon entry to the loop, and thus the proof itself fails.

Always true invariant

The invariant must hold prior to entry to the loop, after the loop-body executes, and must be strong enough to establish the postcondition. The easiest thing to try would be the invariant that always returns true:

>>> let invariant _ = sTrue
>>> void $ correctness invariant Nothing
Following proof obligation failed:
==================================
  Postcondition fails:
    Start: SumS {n = 0, i = 0, s = 0}
    End  : SumS {n = 0, i = 0, s = 1}

In this case, we are told that the end state does not establish the post-condition. Indeed when n=0, we would expect s=0, not s=1.

The natural question to ask is how did SBV come up with this unexpected state at the end of the program run? If you think about the program execution, indeed this state is unreachable: We know that s represents the sum of all numbers up to i, so if i=0, we would expect s to be 0. Our invariant is clearly an overapproximation of the reachable space, and SBV is telling us that we need to constrain and outlaw the state {n = 0, i = 0, s = 1}. Clearly, the invariant has to state something about the relationship between i and s, which we are missing in this case.

Failing to maintain the invariant

What happens if we pose an invariant that the loop actually does not maintain? Here is an example:

>>> let invariant SumS{n, i, s} = s .<= i .&& s .== (i*(i+1)) `sDiv` 2 .&& i .<= n
>>> void $ correctness invariant Nothing
Following proof obligation failed:
==================================
  Invariant for loop "i < n" is not maintained by the body:
    Before: SumS {n = 2, i = 1, s = 1}
    After : SumS {n = 2, i = 2, s = 3}

Here, we posed the extra incorrect invariant that s <= i must be maintained, and SBV found us a reachable state that violates the invariant. The before state indeed satisfies s <= i, but the after state does not. Note that the proof fails in this case not because the program is incorrect, but the stipulated invariant is not valid.

Having a bad measure, Part I

The termination measure must always be non-negative:

>>> let invariant SumS{n, i, s} = s .== (i*(i+1)) `sDiv` 2 .&& i .<= n
>>> let measure   SumS{n, i}    = [- i]
>>> void $ correctness invariant (Just measure)
Following proof obligation failed:
==================================
  Measure for loop "i < n" is negative:
    State  : SumS {n = 3, i = 2, s = 3}
    Measure: -2

The failure is pretty obvious in this case: Measure produces a negative value.

Having a bad measure, Part II

The other way we can have a bad measure is if it fails to decrease through the loop body:

>>> let invariant SumS{n, i, s} = s .== (i*(i+1)) `sDiv` 2 .&& i .<= n
>>> let measure   SumS{n, i}    = [n + i]
>>> void $ correctness invariant (Just measure)
Following proof obligation failed:
==================================
  Measure for loop "i < n" does not decrease:
    Before : SumS {n = 1, i = 0, s = 0}
    Measure: 1
    After  : SumS {n = 1, i = 1, s = 1}
    Measure: 2

Clearly, as i increases, so does our bogus measure n+i. Note that a counterexample where i is negative is also possible for this failure, as the SMT solver will find a counter-example to induction, not necessarily a reachable state. Obviously, all such failures need to be addressed for the full proof.