Inductively Defined Propositions

In the Logic chapter, we looked at several ways of writing propositions, including conjunction, disjunction, and quantifiers. In this chapter, we bring a new tool into the mix: inductive definitions. 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: 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 (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'.

We can perform this kind of reasoning in Coq, again using the inversion tactic. Besides allowing us to reason about equalities involving constructors, inversion provides a case-analysis principle for inductively defined propositions. When used in this way, its syntax is similar to destruct: We pass it a list of identifiers separated by | characters to name the arguments to each of the possible constructors.

In words, here is how the inversion reasoning works in this proof:

• If the evidence is of the form ev_0, we know that n = 0. Therefore, it suffices to show that ev (pred (pred 0)) holds. By the definition of pred, this is equivalent to showing that ev 0 holds, which directly follows from ev_0.
• Otherwise, the evidence must have the form ev_SS n' E', where n = S (S n') and E' is evidence for ev n'. We must then show that ev (pred (pred (S (S n')))) holds, which, after simplification, follows directly from E'.

This particular proof also works if we replace inversion by destruct:

The difference between the two forms is that inversion is more convenient when used on a hypothesis that consists of an inductive property applied to a complex expression (as opposed to a single variable). Here's is a concrete example. Suppose that we wanted to prove the following variation of ev_minus2:

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. The inversion tactic, on the other hand, can detect (1) that the first case does not apply, and (2) that the n' that appears on the ev_SS case must be the same as n. This allows us to complete the proof:

By using inversion, we can also apply the principle of explosion to "obviously contradictory" hypotheses involving inductive properties. For example:

Exercise: 1 star (SSSSev__even)

Prove the following result using inversion.

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 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 in the Induction chapter, 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. 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 later chapters, 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 (ev_sum)

Prove that this definition is logically equivalent to the old one. (You may want to look at the previous theorem when you get to the induction step.)

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:

Exercise: 2 stars (total_relation)

Define (in Coq) an inductive binary relation total_relation that holds between every pair of natural numbers.

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

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

Exercise: 3 stars, recommended (R_provability)

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:

• Which of the following propositions are provable?
  • R 1 1 2
  • R 2 2 6
• If we dropped constructor c₅ from the definition of R, would the set of provable propositions change? Briefly (1 sentence) explain your answer.
• If we dropped constructor c₄ from the definition of R, would the set of provable propositions change? Briefly (1 sentence) explain your answer.

(* FILL IN HERE *)
☐

Exercise: 3 stars (R_fact)

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

Exercise: 4 stars, advanced (subsequence)

A list is a subsequence of another list if all of the elements in the first list occur in the same order in the second list, possibly with some extra elements in between. For example, is a subsequence of each of the lists but it is not a subsequence of any of the lists

• Define an inductive proposition subseq on list nat that captures what it means to be a subsequence. (Hint: You'll need three cases.)
• Prove subseq_refl that subsequence is reflexive, that is, any list is a subsequence of itself.
• Prove subseq_app that for any lists l₁, l₂, and l₃, if l₁ is a subsequence of l₂, then l₁ is also a subsequence of l₂ ++ l₃.
• (Optional, harder) Prove subseq_trans that subsequence is transitive — that is, if l₁ is a subsequence of l₂ and l₂ is a subsequence of l₃, then l₁ is a subsequence of l₃. Hint: choose your induction carefully!

Aside: Strong Induction

So far, we've worked with a conventional induction principle on naturals:

That is, to prove P n for any n, we need to show that:

• P 0 holds (the base case), and
• if P n' holds, then P (S n') holds (the inductive case).

But there are other ways of doing induction on the naturals! The most common alternative is what's called strong induction or course of values induction.

That is, to prove P n for any n, we:

• assume that P m holds for all m < n, and then
• show that P n holds.

This principle of induction is called "strong" induction because we get a stronger inductive hypothesis. In the "weak" induction we've been doing, our IH is that P n', which we use to prove P (S n'). In "strong" induction, to prove P (S n'), our IH is that P m for every m < (S n'). Metaphorically speaking, in weak induction we build a tower of proof just using the floor beneath us: to build the S nth floor, we assume that the nth floor is on solid ground. In strong induction, we build a tower of proof using all of the floors beneath us: to build the nth floor, we can rely on the mth floor for m < n. Suppose we define a function pow : nat → nat → nat as follows: We use strong induction to prove that the informal function pow defined above behaves the same as exp from Basics.v. We'll assume that exp (m*m) ((S n')/2), is equal to exp m (S n').

• Theorem: forall m and n, pow(m,n) = exp base power.

Proof: By strong induction on n, leaving m general. Our IH is that for all n' < n, we have pow(m, n') = exp m n'; we must show pow(m, n) = exp m n. We go by cases on n.

• If n=0, then we have exp m 0 = 1 and pow(m,0) = 1 by definition.
• If n = S n', then we have exp m (S n') = m * exp m n'. We go by cases on the parity of n.
  + If n is even, then we have pow(m, n) = pow(m*m, n/2). But by the IH on n/2 < n, pow(m*m, n/2) is equal to exp (m*m) (n/2), which is itself equal to exp m n.
  + If n is odd, then we have pow(m, S n') = m * pow(m, n'); by the IH on n' < n, we know that pow(m, n') = exp(m, n'), and we are done.

Qed. A few things to note about this proof:

• We get the IH immediately!
• We manually do a case analysis as the first step of our proof.
• When n=0, our IH is useless: there is no n' < 0!
• Whenever we apply the IH, we have to show we're applying it to a smaller number.

Strong induction is at least as strong as weak induction: we can prove the principle of weak induction using the principle of strong induction. Do NOT use the induction tactic: instead we apply the strong induction principle.

Exercise: 2 stars (strong_induction__weak_induction)

Case Study: Regular Expressions

The ev property provides a simple example for illustrating inductive definitions and the basic techniques for reasoning about them, but it is not terribly exciting — after all, it is equivalent to the two non-inductive definitions of evenness that we had already seen, and does not seem to offer any concrete benefit over them. To give a better sense of the power of inductive definitions, we now show how to use them to model a classic concept in computer science: regular expressions. Regular expressions are a simple language for describing strings, defined as follows:

Note that this definition is polymorphic: Regular expressions in reg_exp T describe strings with characters drawn from T — that is, lists of elements of T. (We depart slightly from standard practice in that we do not require the type T to be finite. This results in a somewhat different theory of regular expressions, but the difference is not significant for our purposes.) We connect regular expressions and strings via the following rules, which define when a regular expression matches some string:

• The expression EmptySet does not match any string.
• The expression EmptyStr matches the empty string [].
• The expression Char x matches the one-character string [x].
• If re₁ matches s₁, and re₂ matches s₂, then App re₁ re₂ matches s₁ ++ s₂.
• If at least one of re₁ and re₂ matches s, then Union re₁ re₂ matches s.
• Finally, if we can write some string s as the concatenation of a sequence of strings s = s_1 ++ ... ++ s_k, and the expression re matches each one of the strings s_i, then Star re matches s.
  As a special case, the sequence of strings may be empty, so Star re always matches the empty string [] no matter what re is.

We can easily translate this informal definition into an Inductive one as follows:

Again, for readability, we can also display this definition using inference-rule notation. At the same time, let's introduce a more readable infix notation.

	(MEmpty)
[] =~ EmptyStr

	(MChar)
[x] =~ Char x

s1 =~ re1    s2 =~ re2	(MApp)
s1 ++ s2 =~ App re1 re2

s1 =~ re1	(MUnionL)
s1 =~ Union re1 re2

s2 =~ re2	(MUnionR)
s2 =~ Union re1 re2

	(MStar0)
[] =~ Star re

s1 =~ re    s2 =~ Star re	(MStarApp)
s1 ++ s2 =~ Star re

Notice that these rules are not quite the same as the informal ones that we gave at the beginning of the section. First, we don't need to include a rule explicitly stating that no string matches EmptySet; we just don't happen to include any rule that would have the effect of some string matching EmptySet. (Indeed, the syntax of inductive definitions doesn't even allow us to give such a "negative rule.") Second, the informal rules for Union and Star correspond to two constructors each: MUnionL / MUnionR, and MStar0 / MStarApp. The result is logically equivalent to the original rules but more convenient to use in Coq, since the recursive occurrences of exp_match are given as direct arguments to the constructors, making it easier to perform induction on evidence. (The exp_match_ex₁ and exp_match_ex₂ exercises below ask you to prove that the constructors given in the inductive declaration and the ones that would arise from a more literal transcription of the informal rules are indeed equivalent.) Let's illustrate these rules with a few examples.

(Notice how the last example applies MApp to the strings [1] and [2] directly. Since the goal mentions [1; 2] instead of [1] ++ [2], Coq wouldn't be able to figure out how to split the string on its own.) Using inversion, we can also show that certain strings do not match a regular expression:

We can define helper functions for writing down regular expressions. The reg_exp_of_list function constructs a regular expression that matches exactly the list that it receives as an argument:

We can also prove general facts about exp_match. For instance, the following lemma shows that every string s that matches re also matches Star re.

(Note the use of app_nil_r to change the goal of the theorem to exactly the same shape expected by MStarApp.)

Exercise: 3 stars (exp_match_ex₁)

The following lemmas show that the informal matching rules given at the beginning of the chapter can be obtained from the formal inductive definition.

The next lemma is stated in terms of the fold function from the Poly chapter: If ss : list (list T) represents a sequence of strings s₁, ..., sn, then fold app ss [] is the result of concatenating them all together.

We can then phrase our theorem as follows:

Something interesting happens in the MStarApp case. We obtain two induction hypotheses: One that applies when x occurs in s₁ (which matches re), and a second one that applies when x occurs in s₂ (which matches Star re). This is a good illustration of why we need induction on evidence for exp_match, as opposed to re: The latter would only provide an induction hypothesis for strings that match re, which would not allow us to reason about the case In x s₂.

Exercise: 4 stars (re_not_empty)

Write a recursive function re_not_empty that tests whether, for a given regular expression re, there exists some string that matches re. Prove that your function is correct.

Additional Exercises

Exercise: 3 stars, recommended (nostutter_defn)

Formulating inductive definitions of properties is an important skill you'll need in this course. Try to solve this exercise without any help at all. We say that a list "stutters" if it repeats the same element consecutively. (This is different from the NoDup property in the exercise above: the sequence 1;4;1 repeats but does not stutter.) The property "nostutter mylist" means that mylist does not stutter. Formulate an inductive definition for nostutter.

Make sure each of these tests succeeds, but feel free to change the suggested proof (in comments) if the given one doesn't work for you. Your definition might be different from ours and still be correct, in which case the examples might need a different proof. (You'll notice that the suggested proofs use a number of tactics we haven't talked about, to make them more robust to different possible ways of defining nostutter. You can probably just uncomment and use them as-is, but you can also prove each example with more basic tactics.)

Your first task is to use In to define a proposition disjoint X l₁ l₂, which should be provable exactly when l₁ and l₂ are lists (with elements of type X) that have no elements in common.

Next, use In to define an inductive proposition NoDup X l, which should be provable exactly when l is a list (with elements of type X) where every member is different from every other. For example, NoDup nat [1;2;3;4] and NoDup bool [] should be provable, while NoDup nat [1;2;1] and NoDup bool [true;true] should not be.

Finally, state and prove one or more interesting theorems relating disjoint, NoDup and ++ (list append).

Now define a property repeats such that repeats X l asserts that l contains at least one repeated element (of type X).

Now, here's a way to formalize the pigeonhole principle. Suppose list l₂ represents a list of pigeonhole labels, and list l₁ represents the labels assigned to a list of items. If there are more items than labels, at least two items must have the same label — i.e., list l₁ must contain repeats. This proof is much easier if you use the excluded_middle hypothesis to show that In is decidable, i.e., ∀x l, (In x l) ∨ ¬ (In x l). However, it is also possible to make the proof go through without assuming that In is decidable; if you manage to do this, you will not need the excluded_middle hypothesis.