Induction Principles

This is a good point to pause and take a deeper look at induction principles. Every time we declare a new Inductive datatype, Coq automatically generates an induction principle for this type. The induction principle for a type t is called t_ind. Here is the one for natural numbers:

The induction tactic is a straightforward wrapper that, at its core, simply performs apply t_ind. To see this more clearly, let's experiment a little with using apply nat_ind directly, instead of the induction tactic, to carry out some proofs. Here, for example, is an alternate proof of a theorem that we saw in the Basics chapter.

This proof is basically the same as the earlier one, but a few minor differences are worth noting. First, in the induction step of the proof (the "S" case), we have to do a little bookkeeping manually (the intros) that induction does automatically. Second, we do not introduce n into the context before applying nat_ind — the conclusion of nat_ind is a quantified formula, and apply needs this conclusion to exactly match the shape of the goal state, including the quantifier. The induction tactic works either with a variable in the context or a quantified variable in the goal. Third, the apply tactic automatically chooses variable names for us (in the second subgoal, here), whereas induction lets us specify (with the as... clause) what names should be used. The automatic choice is actually a little unfortunate, since it re-uses the name n for a variable that is different from the n in the original theorem. This is why the Case annotation is just S — if we tried to write it out in the more explicit form that we've been using for most proofs, we'd have to write n = S n, which doesn't make a lot of sense! All of these conveniences make induction nicer to use in practice than applying induction principles like nat_ind directly. But it is important to realize that, modulo this little bit of bookkeeping, applying nat_ind is what we are really doing.

Exercise: 2 stars, optional (plus_one_r')

Complete this proof as we did mult_0_r' above, without using the induction tactic.

☐ The induction principles that Coq generates for other datatypes defined with Inductive follow a similar pattern. If we define a type t with constructors c1 ... cn, Coq generates a theorem with this shape: The specific shape of each case depends on the arguments to the corresponding constructor. Before trying to write down a general rule, let's look at some more examples. First, an example where the constructors take no arguments:

Exercise: 1 star, optional (rgb)

Write out the induction principle that Coq will generate for the following datatype. Write down your answer on paper or type it into a comment, and then compare it with what Coq prints.

☐ Here's another example, this time with one of the constructors taking some arguments.

Exercise: 1 star, optional (natlist1)

Suppose we had written the above definition a little differently:

Now what will the induction principle look like? ☐ From these examples, we can extract this general rule:

• The type declaration gives several constructors; each corresponds to one clause of the induction principle.
• Each constructor c takes argument types a1...an.
• Each ai can be either t (the datatype we are defining) or some other type s.
• The corresponding case of the induction principle says (in English):
  • "for all values x1...xn of types a1...an, if P holds for each of the inductive arguments (each xi of type t), then P holds for c x1 ... xn".

Exercise: 1 star, optional (False_ind_principle)

Can you predict the induction principle for falsehood?

☐

Exercise: 1 star, optional (byntree_ind)

Write out the induction principle that Coq will generate for the following datatype. Write down your answer on paper or type it into a comment, and then compare it with what Coq prints.

☐

Exercise: 1 star, optional (ex_set)

Here is an induction principle for an inductively defined set. Give an Inductive definition of ExSet:

☐ What about polymorphic datatypes? The inductive definition of polymorphic lists is very similar to that of natlist. The main difference is that, here, the whole definition is parameterized on a set X: that is, we are defining a family of inductive types list X, one for each X. (Note that, wherever list appears in the body of the declaration, it is always applied to the parameter X.) The induction principle is likewise parameterized on X: Note the wording here (and, accordingly, the form of list_ind): The whole induction principle is parameterized on X. That is, list_ind can be thought of as a polymorphic function that, when applied to a type X, gives us back an induction principle specialized to the type list X.

Exercise: 1 star, optional (tree)

Write out the induction principle that Coq will generate for the following datatype. Compare your answer with what Coq prints.

☐

Exercise: 1 star, optional (mytype)

Find an inductive definition that gives rise to the following induction principle: ☐

Exercise: 1 star, optional (foo)

Find an inductive definition that gives rise to the following induction principle: ☐

Exercise: 1 star, optional (foo')

Consider the following inductive definition:

What induction principle will Coq generate for foo'? Fill in the blanks, then check your answer with Coq.) ☐

Induction Hypotheses

Where does the phrase "induction hypothesis" fit into this story? The induction principle for numbers is a generic statement that holds for all propositions P (strictly speaking, for all families of propositions P indexed by a number n). Each time we use this principle, we are choosing P to be a particular expression of type nat→Prop. We can make the proof more explicit by giving this expression a name. For example, instead of stating the theorem mult_0_r as "∀ n, n * 0 = 0," we can write it as "∀ n, P_m0r n", where P_m0r is defined as...

... or equivalently...

Now when we do the proof it is easier to see where P_m0r appears.

This extra naming step isn't something that we'll do in normal proofs, but it is useful to do it explicitly for an example or two, because it allows us to see exactly what the induction hypothesis is. If we prove ∀ n, P_m0r n by induction on n (using either induction or apply nat_ind), we see that the first subgoal requires us to prove P_m0r 0 ("P holds for zero"), while the second subgoal requires us to prove ∀ n', P_m0r n' → P_m0r n' (S n') (that is "P holds of S n' if it holds of n'" or, more elegantly, "P is preserved by S"). The induction hypothesis is the premise of this latter implication — the assumption that P holds of n', which we are allowed to use in proving that P holds for S n'.

Informal Proofs (Advanced)

Q: What is the relation between a formal proof of a proposition P and an informal proof of the same proposition P? A: The latter should teach the reader how to produce the former. Q: How much detail is needed?? Unfortunately, There is no single right answer; rather, there is a range of choices. At one end of the spectrum, we can essentially give the reader the whole formal proof (i.e., the informal proof amounts to just transcribing the formal one into words). This gives the reader the ability to reproduce the formal one for themselves, but it doesn't teach them anything. At the other end of the spectrum, we can say "The theorem is true and you can figure out why for yourself if you think about it hard enough." This is also not a good teaching strategy, because usually writing the proof requires some deep insights into the thing we're proving, and most readers will give up before they rediscover all the same insights as we did. In the middle is the golden mean — a proof that includes all of the essential insights (saving the reader the hard part of work that we went through to find the proof in the first place) and clear high-level suggestions for the more routine parts to save the reader from spending too much time reconstructing these parts (e.g., what the IH says and what must be shown in each case of an inductive proof), but not so much detail that the main ideas are obscured. Another key point: if we're comparing a formal proof of a proposition P and an informal proof of P, the proposition P doesn't change. That is, formal and informal proofs are talking about the same world and they must play by the same rules.

Informal Proofs by Induction

Since we've spent much of this chapter looking "under the hood" at formal proofs by induction, now is a good moment to talk a little about informal proofs by induction. In the real world of mathematical communication, written proofs range from extremely longwinded and pedantic to extremely brief and telegraphic. The ideal is somewhere in between, of course, but while you are getting used to the style it is better to start out at the pedantic end. Also, during the learning phase, it is probably helpful to have a clear standard to compare against. With this in mind, we offer two templates below — one for proofs by induction over data (i.e., where the thing we're doing induction on lives in Type) and one for proofs by induction over evidence (i.e., where the inductively defined thing lives in Prop). In the rest of this course, please follow one of the two for all of your inductive proofs.

Induction Over an Inductively Defined Set

Template:

• Theorem: <Universally quantified proposition of the form "For all n:S, P(n)," where S is some inductively defined set.>
  Proof: By induction on n.
  <one case for each constructor c of S...>
  • Suppose n = c a1 ... ak, where <...and here we state the IH for each of the a's that has type S, if any>. We must show <...and here we restate P(c a1 ... ak)>.
    <go on and prove P(n) to finish the case...>
  • <other cases similarly...> ☐

Example:

• Theorem: For all sets X, lists l : list X, and numbers n, if length l = n then index (S n) l = None.
  Proof: By induction on l.
  • Suppose l = []. We must show, for all numbers n, that, if length [] = n, then index (S n) [] = None.
    This follows immediately from the definition of index.
  • Suppose l = x :: l' for some x and l', where length l' = n' implies index (S n') l' = None, for any number n'. We must show, for all n, that, if length (x::l') = n then index (S n) (x::l') = None.
    Let n be a number with length l = n. Since
      length l = length (x::l') = S (length l'),
    it suffices to show that
      index (S (length l')) l' = None.
    But this follows directly from the induction hypothesis, picking n' to be length l'. ☐

Induction Over an Inductively Defined Proposition

Since inductively defined proof objects are often called "derivation trees," this form of proof is also known as induction on derivations. Template:

• Theorem: <Proposition of the form "Q → P," where Q is some inductively defined proposition (more generally, "For all x y z, Q x y z → P x y z")>
  Proof: By induction on a derivation of Q. <Or, more generally, "Suppose we are given x, y, and z. We show that Q x y z implies P x y z, by induction on a derivation of Q x y z"...>
  <one case for each constructor c of Q...>
  • Suppose the final rule used to show Q is c. Then <...and here we state the types of all of the a's together with any equalities that follow from the definition of the constructor and the IH for each of the a's that has type Q, if there are any>. We must show <...and here we restate P>.
    <go on and prove P to finish the case...>
  • <other cases similarly...> ☐

Example

• Theorem: The <= relation is transitive — i.e., for all numbers n, m, and o, if n <= m and m <= o, then n <= o.
  Proof: By induction on a derivation of m <= o.
  • Suppose the final rule used to show m <= o is le_n. Then m = o and we must show that n <= m, which is immediate by hypothesis.
  • Suppose the final rule used to show m <= o is le_S. Then o = S o' for some o' with m <= o'. We must show that n <= S o'. By induction hypothesis, n <= o'.
    But then, by le_S, n <= S o'. ☐

Optional Material

This section offers some additional details on how induction works in Coq and the process of building proof trees. It can safely be skimmed on a first reading. (We recommend skimming rather than skipping over it outright: it answers some questions that occur to many Coq users at some point, so it is useful to have a rough idea of what's here.)

Induction Principles for = and <=

In Logic we have defined eq as:

In the Coq standard library, the definition of equality is slightly different:

The advantage of this definition is that the induction principle that Coq derives for it is precisely the familiar principle of Leibniz equality: what we mean when we say "x and y are equal" is that every property on P that is true of x is also true of y.

Similarly, we have defined <= as:

This definition can be streamlined a little by observing that the left-hand argument n is the same everywhere in the definition, so we can actually make it a "general parameter" to the whole definition, rather than an argument to each constructor.

The second one is better, even though it looks less symmetric. Why? Because it gives us a simpler induction principle. (The same was true of our second version of eq.)

By contrast, the induction principle that Coq calculates for the first definition has a lot of extra quantifiers, which makes it messier to work with when proving things by induction. Here is the induction principle for the first le:

Induction Principles in Prop

Earlier, we looked in detail at the induction principles that Coq generates for inductively defined sets. The induction principles for inductively defined propositions like gorgeous are a tiny bit more complicated. As with all induction principles, we want to use the induction principle on gorgeous to prove things by inductively considering the possible shapes that something in gorgeous can have — either it is evidence that 0 is gorgeous, or it is evidence that, for some n, 3+n is gorgeous, or it is evidence that, for some n, 5+n is gorgeous and it includes evidence that n itself is. Intuitively speaking, however, what we want to prove are not statements about evidence but statements about numbers. So we want an induction principle that lets us prove properties of numbers by induction on evidence. For example, from what we've said so far, you might expect the inductive definition of gorgeous... ...to give rise to an induction principle that looks like this... ... because:

• Since gorgeous is indexed by a number n (every gorgeous object e is a piece of evidence that some particular number n is gorgeous), the proposition P is parameterized by both n and e — that is, the induction principle can be used to prove assertions involving both a gorgeous number and the evidence that it is gorgeous.
• Since there are three ways of giving evidence of gorgeousness (gorgeous has three constructors), applying the induction principle generates three subgoals:
  • We must prove that P holds for O and b_0.
  • We must prove that, whenever n is a gorgeous number and e is an evidence of its gorgeousness, if P holds of n and e, then it also holds of 3+m and g_plus3 n e.
  • We must prove that, whenever n is a gorgeous number and e is an evidence of its gorgeousness, if P holds of n and e, then it also holds of 5+m and g_plus5 n e.
• If these subgoals can be proved, then the induction principle tells us that P is true for all gorgeous numbers n and evidence e of their gorgeousness.

But this is a little more flexibility than we actually need or want: it is giving us a way to prove logical assertions where the assertion involves properties of some piece of evidence of gorgeousness, while all we really care about is proving properties of numbers that are gorgeous — we are interested in assertions about numbers, not about evidence. It would therefore be more convenient to have an induction principle for proving propositions P that are parameterized just by n and whose conclusion establishes P for all gorgeous numbers n: For this reason, Coq actually generates the following simplified induction principle for gorgeous:

In particular, Coq has dropped the evidence term e as a parameter of the the proposition P, and consequently has rewritten the assumption ∀ (n : nat) (e: gorgeous n), ... to be ∀ (n : nat), gorgeous n → ...; i.e., we no longer require explicit evidence of the provability of gorgeous n. In English, gorgeous_ind says:

• Suppose, P is a property of natural numbers (that is, P n is a Prop for every n). To show that P n holds whenever n is gorgeous, it suffices to show:
  • P holds for 0,
  • for any n, if n is gorgeous and P holds for n, then P holds for 3+n,
  • for any n, if n is gorgeous and P holds for n, then P holds for 5+n.

We can apply gorgeous_ind directly instead of using induction.

Exercise: 3 stars, optional (p_provability)

Consider the following inductively defined proposition:

Describe, in English, the conditions under which the proposition p t n is provable. (* FILL IN HERE *)
☐

More on the induction Tactic

The induction tactic actually does even more low-level bookkeeping for us than we discussed above. Recall the informal statement of the induction principle for natural numbers:

• If P n is some proposition involving a natural number n, and we want to show that P holds for all numbers n, we can reason like this:
  • show that P O holds
  • show that, if P n' holds, then so does P (S n')
  • conclude that P n holds for all n.

So, when we begin a proof with intros n and then induction n, we are first telling Coq to consider a particular n (by introducing it into the context) and then telling it to prove something about all numbers (by using induction). What Coq actually does in this situation, internally, is to "re-generalize" the variable we perform induction on. For example, in the proof above that plus is associative...

It also works to apply induction to a variable that is quantified in the goal.

Note that induction n leaves m still bound in the goal — i.e., what we are proving inductively is a statement beginning with ∀ m. If we do induction on a variable that is quantified in the goal after some other quantifiers, the induction tactic will automatically introduce the variables bound by these quantifiers into the context.

Exercise: 1 star, optional (plus_explicit_prop)

Rewrite both plus_assoc' and plus_comm' and their proofs in the same style as mult_0_r'' above — that is, for each theorem, give an explicit Definition of the proposition being proved by induction, and state the theorem and proof in terms of this defined proposition.

☐

Additional Exercises

Exercise: 2 stars, optional (foo_ind_principle)

Suppose we make the following inductive definition: Fill in the blanks to complete the induction principle that will be generated by Coq. ☐

Exercise: 2 stars, optional (bar_ind_principle)

Consider the following induction principle: Write out the corresponding inductive set definition. ☐

Exercise: 2 stars, optional (no_longer_than_ind)

Given the following inductively defined proposition: write the induction principle generated by Coq. ☐

Optional Material

Induction Principles for ∧ and ∨

The induction principles for conjunction and disjunction are a good illustration of Coq's way of generating simplified induction principles for Inductively defined propositions, which we discussed in the last chapter. You try first:

Exercise: 1 star, optional (and_ind_principle)

See if you can predict the induction principle for conjunction.

☐

Exercise: 1 star, optional (or_ind_principle)

See if you can predict the induction principle for disjunction.

☐

From the inductive definition of the proposition and P Q we might expect Coq to generate this induction principle but actually it generates this simpler and more useful one: In the same way, when given the inductive definition of or P Q instead of the "maximal induction principle" what Coq actually generates is this:

Explicit Proof Objects for Induction

Although tactic-based proofs are normally much easier to work with, the ability to write a proof term directly is sometimes very handy, particularly when we want Coq to do something slightly non-standard. Recall the induction principle on naturals that Coq generates for us automatically from the Inductive declation for nat.

There's nothing magic about this induction lemma: it's just another Coq lemma that requires a proof. Coq generates the proof automatically too...

We can read this as follows: Suppose we have evidence f that P holds on 0, and evidence f0 that ∀ n:nat, P n → P (S n). Then we can prove that P holds of an arbitrary nat n via a recursive function F (here defined using the expression form Fix rather than by a top-level Fixpoint declaration). F pattern matches on n:

• If it finds 0, F uses f to show that P n holds.
• If it finds S n0, F applies itself recursively on n0 to obtain evidence that P n0 holds; then it applies f0 on that evidence to show that P (S n) holds.

F is just an ordinary recursive function that happens to operate on evidence in Prop rather than on terms in Set. Aside to those interested in functional programming: You may notice that the match in F requires an annotation as n0 return (P n0) to help Coq's typechecker realize that the two arms of the match actually return the same type (namely P n). This is essentially like matching over a GADT (generalized algebraic datatype) in Haskell. In fact, F has a dependent type: its result type depends on its argument; GADT's can be used to describe simple dependent types like this. We can adapt this approach to proving nat_ind to help prove non-standard induction principles too. Recall our desire to prove that ∀ n : nat, even n → ev n. Attempts to do this by standard induction on n fail, because the induction principle only lets us proceed when we can prove that even n → even (S n) — which is of course never provable. What we did earlier in this chapter was a bit of a hack: Theorem even__ev : ∀ n : nat, (even n → ev n) ∧ (even (S n) → ev (S n)). We can make a much better proof by defining and proving a non-standard induction principle that goes "by twos":

Once you get the hang of it, it is entirely straightforward to give an explicit proof term for induction principles like this. Proving this as a lemma using tactics is much less intuitive (try it!). The induction ... using tactic gives a convenient way to specify a non-standard induction principle like this.

The Coq Trusted Computing Base

One issue that arises with any automated proof assistant is "why trust it?": what if there is a bug in the implementation that renders all its reasoning suspect? While it is impossible to allay such concerns completely, the fact that Coq is based on the Curry-Howard correspondence gives it a strong foundation. Because propositions are just types and proofs are just terms, checking that an alleged proof of a proposition is valid just amounts to type-checking the term. Type checkers are relatively small and straightforward programs, so the "trusted computing base" for Coq — the part of the code that we have to believe is operating correctly — is small too. What must a typechecker do? Its primary job is to make sure that in each function application the expected and actual argument types match, that the arms of a match expression are constructor patterns belonging to the inductive type being matched over and all arms of the match return the same type, and so on. There are a few additional wrinkles:

• Since Coq types can themselves be expressions, the checker must normalize these (by using the conversion rules) before comparing them.
• The checker must make sure that match expressions are exhaustive. That is, there must be an arm for every possible constructor. To see why, consider the following alleged proof object:
  Definition or_bogus : ∀P Q, P ∨ Q → P :=
    fun (P Q : Prop) (A : P ∨ Q) =>
       match A with
       | or_introl H => H
       end.
  All the types here match correctly, but the match only considers one of the possible constructors for or. Coq's exhaustiveness check will reject this definition.
• The checker must make sure that each fix expression terminates. It does this using a syntactic check to make sure that each recursive call is on a subexpression of the original argument. To see why this is essential, consider this alleged proof:
      Definition nat_false : ∀(n:nat), False :=
         fix f (n:nat) : False := f n.
  Again, this is perfectly well-typed, but (fortunately) Coq will reject it.

Note that the soundness of Coq depends only on the correctness of this typechecking engine, not on the tactic machinery. If there is a bug in a tactic implementation (and this certainly does happen!), that tactic might construct an invalid proof term. But when you type Qed, Coq checks the term for validity from scratch. Only lemmas whose proofs pass the type-checker can be used in further proof developments.