Inductively Defined Propositions

In the Logic chapter, we looked at several ways of writing propositions, including conjunction, disjunction, and existential quantification. In this chapter, we bring yet another new tool into the mix: inductively defined propositions. Note: For the sake of simplicity, most of this chapter uses an inductive definition of "evenness" as a running example. This is arguably a bit confusing, since we already have a perfectly good way of defining evenness as a proposition ("n is even if it is equal to the result of doubling some number"). Rest assured that we will see many more compelling examples of inductively defined propositions toward the end of this chapter and in future chapters.

We've already seen two ways of stating a proposition that a number n is even: We can say (1) even n = true, or (2) ∃ k, n = double k. A third possibility that we'll explore here 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.

Such definitions are often presented informally using inference rules, consisting of a line separating some premises above from a conclusion below:

	(ev_0)
ev 0

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

We can use a proof tree to display the reasoning steps demonstrating that 4 is even:
                             -------- (ev_0)
                              ev 0
                             -------- (ev_SS)
                              ev 2
                             -------- (ev_SS)
                              ev 4

Inductive Definition of Evenness

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:

We can think of this as defining a Coq property ev : nat → Prop, together with "evidence constructors" ev_0 : ev 0 and ev_SS : ∀ n, ev n → ev (S (S n)).

These evidence constructors can be thought of as "primitive evidence of evenness", and they can be used just like proven theorems. In particular, we can use Coq's apply tactic with the constructor names to obtain evidence for ev of particular numbers...

... or we can use function application syntax to combine several constructors:

In this way, we can also prove theorems that have hypotheses involving ev.

Using Evidence in Proofs

Besides constructing evidence that numbers are even, we can also destruct such evidence, which amounts to reasoning about how it could have been built. 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 ev, but also that these two constructors are the only ways to build evidence that numbers are ev.

In other words, if someone gives us evidence E for the assertion ev n, then we know that E must be one of two things:

• 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 do case analysis and even induction on evidence of evenness...

Inversion on Evidence

We can prove our characterization of evidence for ev n, using destruct.

Facts like this are often called "inversion lemmas" because they allow us to "invert" some given information to reason about all the different ways it could have been derived. Here, there are two ways to prove that a number is ev, and the inversion lemma makes this explicit.

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

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

Tactic destruct replaced S (S n) with 0 in E, because that's what ev_0 proves.

So let's remember that term S (S n).

Alternatively, the proof is straightforward using the inversion lemma that we proved above.

Coq provides a handy tactic called inversion, which does the work of our inversion lemma and more besides.

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:

We can use inversion to re-prove some theorems from Tactics.v.

The tactic inversion actually works on any H : P where P is defined to be Inductive:

• For each constructor of P, make a subgoal where H is constrained by the form of this constructor.
• Discard contradictory subgoals (such as ev_0 above).
• Generate auxiliary equalities (as with ev_SS above).

Let's try to show that our new notion of evenness implies our earlier notion based on double. (The other direction is left as an exercise.)

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! Let's try our current lemma again:

As we will see in later chapters, induction on evidence is a recurring technique across many areas, and in particular when formalizing the semantics of programming languages, where many properties of interest are defined inductively.

Inductive Relations

Just as a single-argument proposition defines a property, a two-argument proposition defines a relation.

... And, just like properties, relations can be defined inductively. One useful example is the "less than or equal to" relation on numbers.

Some sanity checks...

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

Here are a few more simple relations on numbers:

Case Study: Regular Expressions

Regular expressions are a simple language for describing sets of strings. Their syntax is defined as follows:

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.
  In particular, 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. We use the notation s =~ re in place of exp_match s re. (By "reserving" the notation before defining the Inductive, we can use it in the definition.)

Again, for readability, we can also display this definition using inference-rule 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

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:

Something more interesting:

Naturally, proofs about exp_match often require induction. For example, suppose that we wanted to prove the following intuitive result: If a regular expression re matches some string s, then all elements of s must occur as character literals somewhere in re. To state this theorem, we first define a function re_chars that lists all characters that occur in a regular expression:

The remember Tactic

One potentially confusing feature of the induction tactic is that it will let you try to perform an induction over a term that isn't sufficiently general. The effect of this is to lose information (much as destruct without an eqn: clause can do), and leave you unable to complete the proof. Here's an example:

A naive first attempt at setting up the induction. Note that we are performing induction on evidence! (We can begin by generalizing s₂, since it's pretty clear that we are going to have to walk over both s₁ and s₂ in parallel.)

We can get through the first case...

... but most cases get stuck. For MChar, for instance, we must show that
    s₂ =~ Char x' → x' :: s₂ =~ Char x', which is clearly impossible.

The problem is that induction over a Prop hypothesis only works properly with hypotheses that are completely general, i.e., ones in which all the arguments are variables, as opposed to more complex expressions, such as Star re. An awkward way to solve this problem is "manually generalizing" over the problematic expressions by adding explicit equality hypotheses to the lemma:

This works, but it requires making the statement of the lemma a bit ugly. Fortunately, there is a better way:

As we saw above, The tactic remember e as x causes Coq to (1) replace all occurrences of the expression e by the variable x, and (2) add an equation x = e to the context. Here's how we can use it to show the above result:

We now have Heqre' : re' = Star re.

The Heqre' is contradictory in most cases, allowing us to conclude immediately.

The interesting cases are those that correspond to Star. Note that the induction hypothesis IH₂ on the MStarApp case mentions an additional premise Star re'' = Star re, which results from the equality generated by remember.

Case Study: Improving Reflection

We've seen that we often need to relate boolean computations to statements in Prop. However, this can result in some tedium in proof scripts. Consider:

The first subcase (where n =? m = true) is awkward because we have to explicitly "switch worlds." It would be annoying to have to do this kind of thing all the time.

We can streamline this by defining an inductive proposition that yields a better case-analysis principle for n =? m. Instead of generating an equation such as (n =? m) = true, which is generally not directly useful, this principle gives us right away the assumption we really need: n = m. Following the terminology introduced in Logic, we call this the "reflection principle for equality (between numbers)," and we say that the boolean n =? m is reflected in the proposition n = m.

Notice that the only way to produce evidence for reflect P true is by showing P and then using the ReflectT constructor. If we "invert" this reasoning, it says we can extract evidence for P from evidence for reflect P true. To put this observation to work, we first prove that the statements P ↔ b = true and reflect P b are indeed equivalent. First, the left-to-right implication:

(The right-to-left implication is left as an exercise.)

The advantage of reflect over the normal "if and only if" connective is that, by destructing a hypothesis or lemma of the form reflect P b, we can perform case analysis on b while at the same time generating appropriate hypothesis in the two branches (P in the first subgoal and ¬ P in the second).

To use reflect to produce a better proof of filter_not_empty_In, we begin by recasting the eqb_eq lemma in terms of reflect:

A smoother proof of filter_not_empty_In now goes as follows. Notice how the calls to destruct and rewrite are combined into a single call to destruct.

This small example shows reflection giving us a small gain in convenience; in larger developments, using reflect consistently can often lead to noticeably shorter and clearer proof scripts. We'll see many more examples in later chapters and in Programming Language Foundations. The use of the reflect property has been popularized by SSReflect, a Coq library that has been used to formalize important results in mathematics, including as the 4-color theorem and the Feit-Thompson theorem. The name SSReflect stands for small-scale reflection, i.e., the pervasive use of reflection to simplify small proof steps with boolean computations.