Inductive propositions

We've seen several ways of writing propositions, including conjunction, disjunction, and quantifiers. In this chapter, we bring a new tool into the mix: inductively defined propositions. Inductive propositions are a powerful tool: they offer an alternative way of defining "evidence" of a proposition, while avoiding direct computation. Doing so lets us reason more directly, without reference to any particular implementation. In the early parts of the course, we defined many invariants: e.g., natsets that have no duplicates, or are sorted strictly ascending, or binary trees with the strict search invariant. Inductively defined propositions are perfect for this: we don't want to actually run code to check validity of our sets (it'd be slow!), but we do want to prove things about them!

Evenness

Recall that we have seen two ways of stating that a number n is even: We can say (1) evenb n = true, or (2) ∃ k, n = double k. Yet another possibility is to say that n is even if we can establish its evenness from the following rules:

• Rule ev_0: The number 0 is even.
• Rule ev_SS: If n is even, then S (S n) is even.

To illustrate how this definition of evenness works, let's imagine using it to show that 4 is even. By rule ev_SS, it suffices to show that 2 is even. This, in turn, is again guaranteed by rule ev_SS, as long as we can show that 0 is even. But this last fact follows directly from the ev_0 rule. We will see many definitions like this one during the rest of the course. For purposes of informal discussions, it is helpful to have a lightweight notation that makes them easy to read and write. Inference rules are one such notation:

	(ev_0)
ev 0

ev n	(ev_SS)
ev (S (S n))

Each of the textual rules above is reformatted here as an inference rule; the intended reading is that, if the premises above the line all hold, then the conclusion below the line follows. For example, the rule ev_SS says that, if n satisfies ev, then S (S n) also does. If a rule has no premises above the line, then its conclusion holds unconditionally. We can represent a proof using these rules by combining rule applications into a proof tree. Here's how we might transcribe the above proof that 4 is even:
                             ------ (ev_0)
                              ev 0
                             ------ (ev_SS)
                              ev 2
                             ------ (ev_SS)
                              ev 4

Why call this a "tree" (rather than a "stack", for example)? Because, in general, inference rules can have multiple premises. We will see examples of this below. Putting all of this together, we can translate the definition of evenness into a formal Coq definition using an Inductive declaration, where each constructor corresponds to an inference rule:

This definition is different in one crucial respect from previous uses of Inductive: its result is not a Type, but rather a function from nat to Prop -- that is, a property of numbers. Note that we've already seen other inductive definitions that result in functions, such as list, whose type is Type → Type. What is new here is that, because the nat argument of ev appears unnamed, to the right of the colon, it is allowed to take different values in the types of different constructors: 0 in the type of ev_0 and S (S n) in the type of ev_SS. In contrast, the definition of list names the X parameter globally, to the left of the colon, forcing the result of nil and cons to be the same (list X). Had we tried to bring nat to the left in defining ev, we would have seen an error:

("Parameter" here is Coq jargon for an argument on the left of the colon in an Inductive definition; "index" is used to refer to arguments on the right of the colon.) We can think of the definition of ev as defining a Coq property ev : nat → Prop, together with primitive theorems ev_0 : ev 0 and ev_SS : ∀ n, ev n → ev (S (S n)). Such "constructor theorems" have the same status as proven theorems. In particular, we can use Coq's apply tactic with the rule names to prove ev for particular numbers...

... or we can use function application syntax:

We can also prove theorems that have hypotheses involving ev.

More generally, we can show that any number multiplied by 2 is even:

Exercise: 1 star, standard (ev_double)

Using Evidence in Proofs

Besides constructing evidence that numbers are even, we can also reason about such evidence. Introducing ev with an Inductive declaration tells Coq not only that the constructors ev_0 and ev_SS are valid ways to build evidence that some number is even, but also that these two constructors are the only ways to build evidence that numbers are even (in the sense of ev). In other words, if someone gives us evidence E for the assertion ev n, then we know that E must have one of two shapes:

• E is ev_0 (and n is O), or
• E is ev_SS n' E' (and n is S (S n'), where E' is evidence for ev n').

This suggests that it should be possible to analyze a hypothesis of the form ev n much as we do inductively defined data structures; in particular, it should be possible to argue by induction and case analysis on such evidence. Let's look at a few examples to see what this means in practice.

Inversion on Evidence

Suppose we are proving some fact involving a number n, and we are given ev n as a hypothesis. We already know how to perform case analysis on n using the inversion tactic, generating separate subgoals for the case where n = O and the case where n = S n' for some n'. But for some proofs we may instead want to analyze the evidence that ev n directly. By the definition of ev, there are two cases to consider:

• If the evidence is of the form ev_0, we know that n = 0.
• Otherwise, the evidence must have the form ev_SS n' E', where n = S (S n') and E' is evidence for ev n'.

The following theorem can easily be proved using destruct on evidence.

However, this variation cannot easily be handled with just destruct.

Intuitively, we know that evidence for the hypothesis cannot consist just of the ev_0 constructor, since O and S are different constructors of the type nat; hence, ev_SS is the only case that applies. Unfortunately, destruct is not smart enough to realize this, and it still generates two subgoals. Even worse, in doing so, it keeps the final goal unchanged, failing to provide any useful information for completing the proof.

What happened, exactly? Calling destruct has the effect of replacing all occurrences of the property argument by the values that correspond to each constructor. This is enough in the case of ev_minus2 because that argument n is mentioned directly in the final goal. However, it doesn't help in the case of evSS_ev since the term that gets replaced (S (S n)) is not mentioned anywhere. But the proof is straightforward using our inversion lemma.

Note how both proofs produce two subgoals, which correspond to the two ways of proving ev. The first subgoal is a contradiction that is discharged with discriminate. The second subgoal makes use of injection and rewrite. Coq provides a handy tactic called inversion that factors out that common pattern. The inversion tactic can detect (1) that the first case (n = 0) does not apply and (2) that the n' that appears in the ev_SS case must be the same as n. It has an "as" variant similar to destruct, allowing us to assign names rather than have Coq choose them.

We used an as pattern with inversion above, but it can be very hard to predict what variables and hypothesis inversion will produce. There's nothing wrong with running inversion, seeing what gets produced, and then going back and naming it using as. An alternative approach is to use some tactics to clean up your context.

• The subst tactic tries to minimize the number of variables you have. To try to get rid of a particular variable, write subst ....
• The clear tactic drops a variable or a hypothesis. But don't drop things you'll need!
• The rename ... into ... tactic renames a variable.

Here's an example:

The inversion tactic can apply the principle of explosion to "obviously contradictory" hypotheses involving inductively defined properties, something that takes a bit more work using our inversion lemma. For example:

Exercise: 1 star, standard (SSSSev__even)

Prove the following result using inversion.

Exercise: 1 star, standard (ev5_nonsense)

Prove the following result using inversion.

The inversion tactic does quite a bit of work. For example, when applied to an equality assumption, it does the work of both discriminate and injection. In addition, it carries out the intros and rewrites that are typically necessary in the case of injection. It can also be applied, more generally, to analyze evidence for inductively defined propositions. As examples, we'll use it to reprove some theorems from day 12. (Here we are being a bit lazy by omitting the as clause from inversion, thereby asking Coq to choose names for the variables and hypotheses that it introduces.)

Here's how inversion works in general. Suppose the name H refers to an assumption P in the current context, where P has been defined by an Inductive declaration. Then, for each of the constructors of P, inversion H generates a subgoal in which H has been replaced by the exact, specific conditions under which this constructor could have been used to prove P. Some of these subgoals will be self-contradictory; inversion throws these away. The ones that are left represent the cases that must be proved to establish the original goal. For those, inversion adds all equations into the proof context that must hold of the arguments given to P (e.g., S (S n') = n in the proof of evSS_ev). The ev_double exercise above shows that our new notion of evenness is implied by the two earlier ones (since, by even_bool_prop in Day 14, we already know that those are equivalent to each other). To show that all three coincide, we just need the following lemma:

We could try to proceed by case analysis or induction on n. But since ev is mentioned in a premise, this strategy would probably lead to a dead end, as in the previous section. Thus, it seems better to first try inversion on the evidence for ev. Indeed, the first case can be solved trivially.

Unfortunately, the second case is harder. We need to show ∃ k, S (S n') = double k, but the only available assumption is E', which states that ev n' holds. Since this isn't directly useful, it seems that we are stuck and that performing case analysis on E was a waste of time. If we look more closely at our second goal, however, we can see that something interesting happened: By performing case analysis on E, we were able to reduce the original result to an similar one that involves a different piece of evidence for ev: E'. More formally, we can finish our proof by showing that
        ∃ k', n' = double k',

which is the same as the original statement, but with n' instead of n. Indeed, it is not difficult to convince Coq that this intermediate result suffices.

Induction on Evidence

If this looks familiar, it is no coincidence: We've encountered similar problems early on, when trying to use case analysis to prove results that required induction. And once again the solution is... induction! The behavior of induction on evidence is the same as its behavior on data: It causes Coq to generate one subgoal for each constructor that could have used to build that evidence, while providing an induction hypotheses for each recursive occurrence of the property in question. Just like for induction on ordinary data---naturals, lists, etc.---it takes some practice to predict what induction means for an inductive proposition. Let's try our current lemma again:

Here, we can see that Coq produced an IH that corresponds to E', the single recursive occurrence of ev in its own definition. Since E' mentions n', the induction hypothesis talks about n', as opposed to n or some other number. The equivalence between the second and third definitions of evenness now follows.

As we will see in the case studies that follow, induction on evidence is a recurring technique across many areas. The following exercises provide simple examples of this technique, to help you familiarize yourself with it.

Exercise: 2 stars, standard (ev_sum)

Exercise: 3 stars, advanced, recommended (ev_ev__ev)

Finding the appropriate thing to do induction on is a bit tricky here:

Exercise: 3 stars, standard, optional (ev_plus_plus)

This exercise just requires applying existing lemmas. No induction or even case analysis is needed, though some of the rewriting may be tedious.

Inductive Relations

A proposition parameterized by a number (such as ev) can be thought of as a property -- i.e., it defines a subset of nat, namely those numbers for which the proposition is provable. In the same way, a two-argument proposition can be thought of as a relation -- i.e., it defines a set of pairs for which the proposition is provable.

One useful example is the "less than or equal to" relation on numbers. The following definition should be fairly intuitive. It says that there are two ways to give evidence that one number is less than or equal to another: either observe that they are the same number, or give evidence that the first is less than or equal to the predecessor of the second.

Proofs of facts about ≤ using the constructors le_n and le_S follow the same patterns as proofs about properties, like ev above. We can apply the constructors to prove ≤ goals (e.g., to show that 3<=3 or 3<=6), and we can use tactics like inversion to extract information from ≤ hypotheses in the context (e.g., to prove that (2 ≤ 1) → 2+2=5.) Here are some sanity checks on the definition. (Notice that, although these are the same kind of simple "unit tests" as we gave for the testing functions we wrote in the first few lectures, we must construct their proofs explicitly -- simpl and reflexivity don't do the job, because the proofs aren't just a matter of simplifying computations.)

The "strictly less than" relation n < m can now be defined in terms of le.

Here are a few more simple relations on numbers:

Here's a heterogeneous relation, relating lists to numbers. What is it doing?

Resist peeking at the next theorem... think about it!

Here's a relation on arbitrary values and binary trees. What is it doing?

Don't peek!

Last one. Here's a relation on DNA bases and binary trees. What is it doing?

Exercise: 3 stars, standard (sums_to)

Define an relation sums_to that relates a list nat to its sum, i.e.,
     sums_to [] 0

and
     sums_to [10] 10

and
     sums_to [1;2;3;4;5] 15

should all be provable. Prove that sums_to l (sum l).

We can define three-place relations, four-place relations, etc., in just the same way as binary relations. For example, consider the following three-place relation on numbers:

Exercise: 3 stars, standard (R_fact)

The relation R above actually encodes a familiar function. Figure out which function; then state and prove this equivalence in Coq?

Reasoning about minima

As practice with ≤, we'll prove some properties about min3 and argmin3. We'll need these properties to show that some edit functions are 'better' than others. To do so, we'll need a bunch of other results. These are great practice problems. We won't grade them, but if you're having trouble understanding inductive propositions, doing some of these will defiitely help.

Exercise: 3 stars, standard, optional (le_exercises)

Here are a number of facts about the ≤ and < relations that we are going to need later in the course. The proofs make good practice exercises. Even if you don't do these proofs, look carefully at the properties... these are very useful facts!

Hint: The next one may be easiest to prove by induction on m.

Hint: This theorem can easily be proved without using induction.

Exercise: 1 star, standard, optional (leb_iff)

Same here: just reuse some results.

Okay: let's get down to business. This lemma is the linchpin. You'll want to use leb_spec to get things right here.

Exercise: 2 stars, standard (min3_min)

These next three lemmas should all follow from min3_min and previous lemmas.

Exercise: 3 stars, standard, optional (min3_leb)

A hint.

Case study: getting natset right

There's an important set of properties that we haven't proved about our no-duplicates invariant for list-based sets of naturals: that we maintain the natset invariant that each element appears at most once! Before we begin, we'll insert our own definitions of some operations you defined a while back.

We can characterize those natsets which are setlike using an inductive predicate.

Exercise: 2 stars, standard (setlike_egs)

Let's get a feel for the setlike predicate. It's always important to have positive examples---things that should satisfy the property, like setlike_eg₁---as well as negative examples---things that should not satisfy the property, like setlike_eg₂.

Exercise: 3 stars, standard, optional (In_member_iff)

The member function returns true exactly when the In predicate holds. This is good practice about inductive proof; it's needed for the next few exercises (but you can do them without doing this proof!).

Exercise: 2 stars, standard, optional (is_setlike__setlike)

We should, as always, double check our ideas. We have a setlike predicate on sets defined inductively and an is_setlike function defined recursively. Do these notions coincide?

Exercise: 2 stars, standard (insert_preserves_setlike)

Exercise: 2 stars, standard (union_preserves_setlike)

Exercise: 4 stars, standard, optional (union_intersection_dist)

The setlike predicate isn't just useful for checking that we've implemented our operations correctly---sometimes we need to use setlike in proofs! Prove that intersection distributes over union. (You may be more familiar with distributivity from arithmetic: x × (y + z) = (x × y) + (x × z).) You'll need several helper lemmas to prove this! A useful tip for helper lemmas: don't prove them right away, just use Admitted to see if they would let you finish your proof. If you prove them right away, you might spend a long time proving a helper lemma that isn't so... helpful.