# Joachim Breitner's Homepage

## Existence and Termination

I recently had some intense discussions that revolved around issues of existence and termination of functions in Coq, about axioms and what certain proofs actually mean. We came across some interesting questions and thoughts that I’ll share with those of my blog readers with an interest in proofs and interactive theorem proving.

### tl;dr

- It can be meaningful to assume the
*existence*of a function in Coq, and under that assumption prove its*termination*and other properties. - Axioms and assumptions are logically equivalent.
- Unsound axioms do not necessary invalidate a theory development, when additional meta-rules govern their use.

### Preparation

Our main running example is the infamous Collatz series. Starting at any natural number, the next is calculated as follow:

```
Require Import Coq.Arith.Arith.
Definition next (n : nat) :nat :=
if Nat.even n then n / 2 else 3*n + 1.
```

If you start with some positive number, you are going to end up reaching 1 eventually. Or are you? So far nobody has found a number where that does not happen, but we also do not have a proof that it never happens. It is one of the great mysteries of Mathematics, and if you can solve it, you’ll be famous.

### A failed definition

But assume we had an idea on how to prove that we are always going to reach 1, and tried to formalize this in Coq. One attempt might be to write

```
Fixpoint good (n : nat) : bool :=
if n <=? 1
then true
else good (next n).
Theorem collatz: forall n, good n = true.
Proof. (* Insert genius idea here.*) Qed.
```

Unfortunately, this does not work: Coq rejects this recursive definition of the function `good`

, because it does not see how that is a terminating function, and Coq requires all such recursive function definitions to be obviously terminating – without this check there would be a risk of Coq’s type checking becoming incomplete or its logic being unsound.

The idiomatic way to avoid this problem is to state `good`

as an inductive predicate… but let me explore another idea here.

### Working with assumptions

What happens if we just assume that the function `good`

, described above, exists, and then perform our proof:

```
Theorem collatz
(good : nat -> bool)
(good_eq : forall n,
good n = if n <=? 1 then true else good (next n))
: forall n, good n = true.
Proof. (* Insert genius idea here.*) Qed.
```

Would we accept this as a proof of Collatz’ conjecture? Or did we just assume what we want to prove, in which case the theorem is vacuously true, but we just performed useless circular reasoning?

Upon close inspection, we find that the assumptions of the theorem (`good`

and `good_eq`

) are certainly satisfiable:

```
Definition trivial (n: nat) : bool := true.
Lemma trivial_eq: forall n,
trivial n = if n <=? 1 then true else trivial (next n).
Proof. intro; case (n <=? 1); reflexivity. Qed.
Lemma collatz_trivial: forall n, trivial n = true.
Proof.
apply (collatz trivial trivial_eq).
Qed.
```

So clearly there exists a function of type `nat -> bool`

that satisfies the assumed equation. This is good, because it means that the `collatz`

theorem is not simply assuming `False`

!

Some (including me) might already be happy with this theorem and proof, as it clearly states: “Every function that follows the Collatz series eventually reaches 1”.

Others might still not be at ease with such a proof. Above we have seen that we cannot define the real collatz series in Coq. How can the `collatz`

theorem say something that is not definable?

### Classical reasoning

One possible way of getting some assurance it to define `good`

as a classical function. The logic of Coq can be extended with the law of the excluded middle without making it inconsistent, and with that axiom, we can define a version of `good`

that is pretty convincing (sorry for the slightly messy proof):

```
Require Import Coq.Logic.ClassicalDescription.
Require Import Omega.
Definition classical_good (n:nat) : bool :=
if excluded_middle_informative (exists m, Nat.iter m next n <= 1)
then true else false.
Lemma iter_shift:
forall a f x (y:a), Nat.iter x f (f y) = f (Nat.iter x f y).
Proof.
intros. induction x. reflexivity. simpl. rewrite IHx. reflexivity. Qed.
Lemma classical_good_eq: forall n,
classical_good n = if n <=? 1 then true else classical_good (next n).
Proof.
intros.
unfold classical_good at 1.
destruct (Nat.leb_spec n 1).
* destruct (excluded_middle_informative _); try auto.
contradict n0. exists 0. simpl. assumption.
* unfold classical_good.
destruct (Nat.eqb_spec (next n) 0); try auto.
destruct (excluded_middle_informative _), (excluded_middle_informative _); auto.
- contradict n0.
destruct e0.
destruct x; simpl in *. omega.
exists x. rewrite iter_shift. assumption.
- contradict n0.
destruct e0.
exists (S x). simpl. rewrite iter_shift in H0. assumption.
Qed.
Lemma collatz_classical: forall n, classical_good n = true.
Proof. apply (collatz classical_good classical_good_eq). Qed.
```

The point of this is not so much to use this particular definition of `good`

, but merely to convince ourselves that the assumptions of the `collatz`

theorem above encompass “the” Collatz series, and thus constitutes a proof of the Collatz conjecture.

The main take-away so far is that **existence and termination of a function** are two separate issues, and it is possible to assume the former, prove the latter, and not have done a vacuous proof.

### The ice gets thinner

#### Sections

Starting with the above `Theorem collatz`

, there is another train of thought I invite to to follow along.

Probably the “genius idea” proof will be more than a few lines long, and we probably to be able to declare helper lemmas and other things along the way. Doing all that in the body of the `collatz`

proof is not very convenient, so instead of using assumptions, we might write

```
Section collatz:
Variable good : nat -> bool.
Variable good_eq : forall n,
good n = if n <=? 1 then true else good (next n)
Theorem collatz2 : forall n, good n = true.
Proof. (* Insert genius idea here.*) Qed.
End collatz.
```

So far so good: Clearly, I just refactored my code a bit, but did not make any significant change. The theorems `collatz2`

and `collatz`

are equivalent.

#### Sound axioms

But note that we do not really intend to instantiate `collatz2`

. We know that the assumptions are satisfiable (e.g. since we can define `trivial`

or `classical_good`

). So maybe, we would rather avoid the `Section`

mechanism and simply write

```
Axiom good : nat -> bool.
Axiom good_eq : forall n,
good n = if n <=? 1 then true else good (next n)
Theorem collatz3 : forall n, good n = true.
Proof. (* Insert genius idea here.*) Qed.
```

I assume this will make a few of my readers’ eyebrows go up: How can I dare to start with such Axioms? Do they not invalidate my whole development?

On the other hand, all that a Coq axiom is doing is saying “the following theorems are under the assumption that the axiom holds”. In that sense, `collatz3`

and `collatz2`

are essentially equivalent.

#### Unsound axioms

Let me take it one step further, and change that to:

```
Axiom unsafeFix : forall a, (a -> a) -> a.
Axiom unsafeFix_eq : forall f, unsafeFix f = f (unsafeFix f).
Definition good : nat -> bool :=
unsafeFix (fun good n => if n <=? 1 then true else good (next n)).
Theorem collatz4 : forall n, good n = true.
Proof. (* Insert genius idea here.*) Qed.
```

At this point, the majority of my readers *will* cringe. The axiom `unsafeFix`

is so blatantly unsound (in Coq), how do I even dare to think of using it. But bear with me for a moment: I did not change the proof. So maybe the `collatz4`

theorem is still worth something?

I want to argue that it is: Both `unsafeFix`

and `unsafeFix_eq`

are unsound in their full generality. But as long as I instantiate them only with functions `f`

which have a fixpoint, then I cannot prove `False`

this way. So while “Coq + `unsafeFix`

” is unsound, “Coq + `unsafeFix`

+ `unsafeFix_eq`

+ metarule that these axioms are only called with permissible `f`

” is not.

In that light, my `collatz4`

proof carries the same meaning as the `collatz3`

proof, it is just less convenient to check: If I were to check the validity of `collatz3`

, I have to maybe look for uses of `admit`

, or some misleading use of syntax or other tricks, or other smells. When I have to check the validity of `collatz4`

, I also have to additionally check the meta-rule – tedious, but certainly possible (e.g. by inspecting the proof term).

### Beyond Collatz

The questions discussed here did not come up in the context of the Collatz series (for which I unfortunately do not have a proof), but rather the verification of Haskell code in Coq using `hs-to-coq`

. I started with the idiomatic Haskell definition of “Quicksort”:

```
quicksort :: Ord a => [a] -> [a]
= []
quicksort [] :xs) = quicksort lesser ++ [p] ++ quicksort greater
quicksort (pwhere (lesser, greater) = partition (<p) xs
```

This function is not terminating in a way that is obvious to the Coq type checker. Conveniently, `hs-to-coq`

can optionally create the Coq code using the `unsafeFix`

axiom above, producing (roughly):

```
Definition quicksort {a} `{Ord a} : list a -> list a :=
unsafeFix (fun quicksort xs =>
match xs with
| nil => nil
| p :: xs => match partition (fun x => x <? p) xs with
| (lesser, greater) => quicksort lesser ++ [p] ++ quicksort greater
end
end).
```

I then proved (roughly)

```
Theorem quicksort_sorted:
forall a `(Ord a) (xs : list a), StronglySorted (quicksort xs).
```

and

```
Theorem quicksort_permutation:
forall a `(Ord a) (xs : list a), Permutation (quicksort xs) xs.
```

These proofs proceed by well-founded induction on the length of the argument `xs`

, and hence encompass a termination proof of `quicksort`

. Note that with a only *partially* correct but non-terminating definition of `quicksort`

(e.g. `quicksort := unsafeFix (fun quicksort xs => quicksort xs)`

) I would not be able to conclude these proofs.

My (not undisputed) claim about the meaning of these theorems is therefore

If the Haskell equations for

`quicksort`

actually have a fixed point, then the use of`unsafeFix`

in its definition does not introduce any inconsistency. Under this assumption, we showed that`quicksort`

always terminates and produces a sorted version of the input list.

Do you agree?

## Comments

congrats to the POPL paper!

Now of course I wonder how hard it would be to prove “safe encapsulation” of unsafe Coq axioms.

In my case, I did a form of factorization. Thinking graphically (e.g. in the sense of The Incredible Proof Machine: If you can draw an “abstraction boundary” around all uses of the unsafe axioms such that every edge crossing the boundary is a true statement, then the axioms are used safely.

For `quicksort`

, the two axoims and their instantiations to the `quicksort`

equations are inside this region, so that only the existence of a function with the type and equation escapes the unsafe region, and we can prove the safety of that by implementing (any!) sorting function.

(I really like thinking about proofs as graphs, it feels just so much more natural to me than linear proofs of lambda terms.)

Have something to say? You can post a comment by sending an e-Mail to me at <mail@joachim-breitner.de>, and I will include it here.

Thanks a lot for this blog post, which I enjoyed a lot. :)

One thing that came to my mind when you talked about unsafeFix and how it is sound if used carefully is the relation to “unsafe code” in (other) programming languages. Rust, for example, is a type-safe language that however provides “unsafe blocks” where programmers can use features that the compiler cannot check for safety. Typically, library developers then design the API of their library such that the unsafety is “safely encapsulated”, so that well-typed (safe) clients cannot suffer from any type-safety issues. This sounds a lot like

`unsafeFix`

, beginning with the name. ;) And of course, this is far from unique to Rust. OCaml has`obj.magic`

, Haskell has`unsafePerformIO`

, and the list goes on.I have been working on proving the “safe encapsulation” of safe Rust code, but have not thought much about this in the context of theorem provers. Curry-Howard strikes again. ;) Now of course I wonder how hard it would be to prove “safe encapsulation” of unsafe Coq axioms.