Joachim Breitner's Homepage

The DeepSpec Summer School is almost over, and I have had a few good discussions. One revolved around coinduction: What is it, how does it differ from induction, and how do you actually prove something. In the course of the discussion, I came up with a very simple coinductive exercise, and solved it both in Coq and Isabelle

The task

Define the extended natural numbers coinductively. Define the min function and the ≤ relation. Show that min(n, m)≤n holds.

Coq

The definitions are straight forward. Note that in Coq, we use the same command to define a coinductive data type and a coinductively defined relation:

Effectively, as Coq is trying to figure out whether our proof is correct, i.e. type-checks, it stumbled on the equation min N N = N, and like a kid scared of coinduction, it did not dare to “run” the min function. The reason it does not just “run” a CoFixpoint is that doing so too daringly might simply not terminate. So, as Adam explains in a chapter of his book, Coq reduces a cofixpoint only when it is the scrutinee of a match statement.

So we need to get a match statement in place. We can do so with a helper function:

I chose to spell the proof out in the Isar proof language, where the outermost proof structure is done relatively explicity, and I proceed by case analysis mimiking the min function definition.

In the cases where one argument of min is N, Isabelle’s simplifier (a term rewriting tactic, so to say), can solve the goal automatically. This is because the primcorec command produces a bunch of lemmas, one of which states n = N ∨ m = N ⟹ min n m = N.

In the other case, we need to help Isabelle a bit to reduce the call to min (S n) (S m) using the unfolding methods, where min.code contains exactly the equation that we used to specify min. Using just unfolding min.code would send this method into a loop, so we restrict it to the concrete arguments n and m. Then auto can solve the remaining goal (despite all the existential quantifiers).

Summary

Both theorem provers are able to prove the desired result. To me it seems that it is slightly more convenient in Isabelle because a lot of Coq infrastructure relies on the type checker being able to effectively evaluate expressions, which is tricky with cofixpoints, wheras evaluation plays a much less central role in Isabelle, where rewriting is the crucial technique, and while one still cannot simply throw min.code into the simpset, so working with objects that do not evaluate easily or completely is less strange.

I will refrain from commenting it, because I do not really know what I have been doing here, but it typechecks, and refer you to the official documentation on coinduction in Agda. But let me note that I wrote this using plain inductive types and recursion, and added ∞, ♯ and ♭ until it worked.

Comments

FYI, "musical" coinduction is deprecated in Agda. Agda's new coinduction framework differs significantly from Coq's and solves a lot of issues, among them the one where you have to manually unfold cofixpoints everywhere. I can rewrite the example in the new style

The old coinductives presented in Coq are broken in the sense that using them breaks subject reduction because they are treated as positive types enjoying full dependent elimination which is wrong. To see, why, in your example you show:

This happens because one cannot "blindly" unfold cofixpoints during conversion, only a "match" on a cofixpoint value reduces, but there's no match here in the (evalN infS = infS) type so Coq compares only the codes (not the behavior) of the two cofixpoints and fails. The solution adopted in Agda can also be formalized in Coq using CoInductive primitive records, which treat coinductive values as "negative" connectives not subject to full dependent elimination, as they can now only be accessed through their projections (evalN cannot be defined on this type).

The negative consequence is that the system does not enjoy subject reduction anymore. Morally, equality of coonductive values should be bisimulation instead of the very intentional @eq type of Coq. OTT and HoTT are both leaning towards such a definition of equality. In that case the dependent elimination would be ok I think, as every construction of the language would respect bisimulation instead of the more restrictive intensional equality. The problem becomes that there’s not only eqrefl as an inhabitant of the equality type anymore so canonicity becomes more complicated (see canonicity for cubical TT for example).