PropPropositions and Evidence

RequireExportMoreCoq.

In previous chapters, we have seen many examples of factual
claims (propositions) and ways of presenting evidence of their
truth (proofs). In particular, we have worked extensively with
equality propositions of the form e1=e2, with
implications (P→Q), and with quantified propositions
(∀x,P).

In this chapter we take a deeper look at the way propositions are
expressed in Coq and at the structure of the logical evidence that
we construct when we carry out proofs.

Some of the concepts in this chapter may seem a bit abstract on a
first encounter. We've included a lot of exercises, most of
which should be quite approachable even if you're still working on
understanding the details of the text. Try to work as many of
them as you can, especially the one-starred exercises.

Inductively Defined Propositions

This chapter will take us on a first tour of the
propositional (logical) side of Coq. As a running example, let's
define a simple property of natural numbers — we'll call it
"beautiful."

Informally, a number is beautiful if it is 0, 3, 5, or the
sum of two beautiful numbers.

More pedantically, we can define beautiful numbers by giving four
rules:

Rule b_0: The number 0 is beautiful.

Rule b_3: The number 3 is beautiful.

Rule b_5: The number 5 is beautiful.

Rule b_sum: If n and m are both beautiful, then so is
their sum.

We will see many definitions like this one during the rest
of the course, and 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:

(b_0)

beautiful 0

(b_3)

beautiful 3

(b_5)

beautiful 5

beautiful n beautiful m

(b_sum)

beautiful (n+m)

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 b_sum says that, if n and m
are both beautiful numbers, then it follows that n+m is
beautiful too. The rules with no premises above the line are
called axioms.

These rules define the property beautiful. That is, if we
want to convince someone that some particular number is beautiful,
our argument must be based on these rules. For a simple example,
suppose we claim that the number 5 is beautiful. To support
this claim, we just need to point out that rule b_5 says so.
Or, if we want to claim that 8 is beautiful, we can support our
claim by first observing that 3 and 5 are both beautiful (by
rules b_3 and b_5) and then pointing out that their sum, 8,
is therefore beautiful by rule b_sum. This argument can be
expressed graphically with the following proof tree:

The first line declares that beautiful is a proposition — or,
more formally, a family of propositions "indexed by" natural
numbers. (That is, for each number n, the claim that "n is
beautiful" is a proposition.) Such a family of propositions is
often called a property of numbers. Each of the remaining lines
embodies one of the rules for beautiful numbers.

We can use Coq's tactic scripting facility to assemble proofs that
particular numbers are beautiful.

Theoremeight_is_beautiful: beautiful 8.Proof.(* First we use the rule b_sum, telling Coq how to
instantiate n and m. *)applyb_sumwith (n:=3) (m:=5).(* To solve the subgoals generated by b_sum, we must provide
evidence of beautiful3 and beautiful5. Fortunately we
have axioms for both. *)applyb_3.applyb_5.Qed.

Proof Objects

Look again at the formal definition of the beautiful
property. The opening keyword, Inductive, has been used up to
this point to declare new types of data, such as numbers and
lists. Does this interpretation also make sense for the Inductive
definition of beautiful? That is, can we view evidence of
beauty as some kind of data structure? Yes, we can!

The trick is to introduce an alternative pronunciation of ":".
Instead of "has type," we can also say "is a proof of." For
example, the second line in the definition of beautiful declares
that b_0:beautiful0. Instead of "b_0 has type
beautiful0," we can say that "b_0 is a proof of beautiful0."
Similarly for b_3 and b_5.

This pun between types and propositions (between : as "has type"
and : as "is a proof of" or "is evidence for") is called the
Curry-Howard correspondence. It proposes a deep connection
between the world of logic and the world of computation.

propositions ~ types
proofs ~ data values

Many useful insights follow from this connection. To begin with, it
gives us a natural interpretation of the type of b_sum constructor:

This can be read "b_sum is a constructor that takes four
arguments — two numbers, n and m, and two values, of types
beautifuln and beautifulm — and yields evidence for the
proposition beautiful(n+m)."

In view of this, we might wonder whether we can write an
expression of type beautiful8 by applying b_sum to
appropriate arguments. Indeed, we can:

Check (b_sum 3 5 b_3b_5).(* ===> beautiful (3 + 5) *)

The expression b_sum35b_3b_5 can be thought of as
instantiating the parameterized constructor b_sum with the
specific arguments 35 and the corresponding proof objects for
its premises beautiful3 and beautiful5 (Coq is smart enough
to figure out that 3+5=8). Alternatively, we can think of b_sum
as a primitive "evidence constructor" that, when applied to two
particular numbers, wants to be further applied to evidence that
those two numbers are beautiful; its type,
[∀nm,beautifuln→beautifulm→beautiful(n+m),]
expresses this functionality, in the same way that the polymorphic
type ∀X,listX in the previous chapter expressed the fact
that the constructor nil can be thought of as a function from
types to empty lists with elements of that type.

This gives us an alternative way to write the proof that 8 is
beautiful:

Notice that we're using apply here in a new way: instead of just
supplying the name of a hypothesis or previously proved theorem
whose type matches the current goal, we are supplying an
expression that directly builds evidence with the required
type.

Proof Scripts and Proof Objects

These proof objects lie at the core of how Coq operates.

When Coq is following a proof script, what is happening internally
is that it is gradually constructing a proof object — a term
whose type is the proposition being proved. The tactics between
the Proof command and the Qed instruct Coq how to build up a
term of the required type. To see this process in action, let's
use the ShowProof command to display the current state of the
proof tree at various points in the following tactic proof.

At any given moment, Coq has constructed a term with some
"holes" (indicated by ?1, ?2, and so on), and it knows what
type of evidence is needed at each hole. In the ShowProof
output, lines of the form ?1→beautifuln record these
requirements. (The → here has nothing to do with either
implication or function types — it is just an unfortunate choice
of concrete syntax for the output!)

Each of the holes corresponds to a subgoal, and the proof is
finished when there are no more subgoals. At this point, the
Theorem command gives a name to the evidence we've built and
stores it in the global context.

Tactic proofs are useful and convenient, but they are not
essential: in principle, we can always construct the required
evidence by hand. Indeed, we don't even need the Theorem
command: we can instead use Definition to directly give a global
name to a piece of evidence.

Definitioneight_is_beautiful''' : beautiful 8 :=b_sum 3 5 b_3b_5.

All these different ways of building the proof lead to exactly the
same evidence being saved in the global environment.

Implications and Functions

In Coq's computational universe (where we've mostly been living
until this chapter), there are two sorts of values with arrows in
their types: constructors introduced by Inductive-ly defined
data types, and functions.

Similarly, in Coq's logical universe, there are two ways of giving
evidence for an implication: constructors introduced by
Inductive-ly defined propositions, and... functions!

We're looking for an expression whose type is ∀n,beautifuln→beautiful(3+n) — that is, a function that
takes two arguments (one number and a piece of evidence) and
returns a piece of evidence! Here it is:

Exercise: 2 stars (b_timesm)

Induction Over Proof Objects

Since we use the keyword Induction to define primitive
propositions together with their evidence, we might wonder whether
there are some sort of induction principles associated with these
definitions. Indeed there are, and in this section we'll take a
look at how they can be used.

Besides constructing evidence that numbers are beautiful, we can
also reason about such evidence.

The fact that we introduced beautiful with an Inductive
declaration tells us not only that the constructors b_0, b_3,
b_5 and b_sum are ways to build evidence, but also that these
two constructors are the only ways to build evidence that
numbers are beautiful.

In other words, if someone gives us evidence E for the assertion
beautifuln, then we know that E must have one of four shapes:

E is b_0 (and n is O),

E is b_3 (and n is 3),

E is b_5 (and n is 5), or

E is b_sumn1n2E1E2 (and n is n1+n2, where E1 is
evidence that n1 is beautiful and E2 is evidence that n2
is beautiful).

This gives rise to an induction principle for proofs — i.e., we
can use the induction tactic that we have already seen for
reasoning about inductively defined data to reason about
inductively defined evidence.

Exercise: 1 star (gorgeous_tree)

Write out the definition of gorgeous numbers using inference rule
notation.

(* FILL IN HERE *)☐

It seems intuitively obvious that, although gorgeous and
beautiful are presented using slightly different rules, they are
actually the same property in the sense that they are true of the
same numbers. Indeed, we can prove this.

The problem here is that doing induction on n doesn't yield a
useful induction hypothesis. Knowing how the property we are
interested in behaves on the predecessor of n doesn't help us
prove that it holds for n. Instead, we would like to be able to
have induction hypotheses that mention other numbers, such as n-3 and n-5. This is given precisely by the shape of the
constructors for gorgeous.

From Boolean Functions to Propositions

In chapter Basics we defined a functionevenb that tests a
number for evenness, yielding true if so. We can use this
function to define the proposition that some number n is
even:

Definitioneven (n:nat) : Prop := evenbn = true.

That is, we can define "n is even" to mean "the function evenb
returns true when applied to n."

Another alternative is to define the concept of evenness
directly. Instead of going via the evenb function ("a number is
even if a certain computation yields true"), we can say what the
concept of evenness means by giving two different ways of
presenting evidence that a number is even.

This definition says that there are two ways to give
evidence that a number m is even. First, 0 is even, and
ev_0 is evidence for this. Second, if m=S(Sn) for some
n and we can give evidence e that n is even, then m is
also even, and ev_SSne is the evidence.

Exercise: 1 star (double_even)

Exercise: 4 stars, optional (double_even_pfobj)

Try to predict what proof object is constructed by the above
tactic proof. (Before checking your answer, you'll want to
strip out any uses of Case, as these will make the proof
object look a bit cluttered.) ☐

Discussion: Computational vs. Inductive Definitions

We have seen that the proposition "n is even" can be
phrased in two different ways — indirectly, via a boolean testing
function evenb, or directly, by inductively describing what
constitutes evidence for evenness. These two ways of defining
evenness are about equally easy to state and work with. Which we
choose is basically a question of taste.

However, for many other properties of interest, the direct
inductive definition is preferable, since writing a testing
function may be awkward or even impossible.

One such property is beautiful. This is a perfectly sensible
definition of a set of numbers, but we cannot translate its
definition directly into a Coq Fixpoint (or into a recursive
function in any other common programming language). We might be
able to find a clever way of testing this property using a
Fixpoint (indeed, it is not too hard to find one in this case),
but in general this could require arbitrarily deep thinking. In
fact, if the property we are interested in is uncomputable, then
we cannot define it as a Fixpoint no matter how hard we try,
because Coq requires that all Fixpoints correspond to
terminating computations.

On the other hand, writing an inductive definition of what it
means to give evidence for the property beautiful is
straightforward.

Inversion on Proof Objects

Besides induction, we can use the other tactics in our toolkit
to reason about evidence. For example, this proof uses destruct
on evidence.

Could this proof also be carried out by induction on n instead
of E? If not, why not?

(* FILL IN HERE *)

☐

The induction principle for inductively defined propositions does
not follow quite the same form as that of inductively defined
sets. For now, you can take the intuitive view that induction on
evidence evn is similar to induction on n, but restricts our
attention to only those numbers for which evidence evn could be
generated. We'll look at the induction principle of ev in more
depth below, to explain what's really going on.

This use of inversion may seem a bit mysterious at first.
Until now, we've only used inversion on equality
propositions, to utilize injectivity of constructors or to
discriminate between different constructors. But we see here
that inversion can also be applied to analyzing evidence
for inductively defined propositions.

Here's how inversion works in general. Suppose the name
I 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, inversionI generates
a subgoal in which I 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.

In this particular case, the inversion analyzed the construction
ev(S(Sn)), determined that this could only have been
constructed using ev_SS, and generated a new subgoal with the
arguments of that constructor as new hypotheses. (It also
produced an auxiliary equality, which happens to be useless here.)
We'll begin exploring this more general behavior of inversion in
what follows.

We can generally use inversion on inductive propositions.
This illustrates that in general, we get one case for each
possible constructor. Again, we also get some auxiliary
equalities that are rewritten in the goal but not in the other
hypotheses.

Exercise: 3 stars, advanced (ev_ev__ev)

Exercise: 3 stars, optional (ev_plus_plus)

Here's an exercise that just requires applying existing lemmas. No
induction or even case analysis is needed, but some of the rewriting
may be tedious. You'll want the replace tactic used for plus_swap'
in Basics.v

Building Proof Objects Incrementally (Optional)

As you probably noticed while solving the exercises earlier in the
chapter, constructing proof objects is more involved than
constructing the corresponding tactic proofs. Fortunately, there
is a bit of syntactic sugar that we've already introduced to help
in the construction: the admit term, which we've sometimes used
to force Coq into accepting incomplete exercies. As an example,
let's walk through the process of constructing a proof object
demonstrating the beauty of 16.

Definitionb_16_atmpt_1 : beautiful 16 := admit.

Maybe we can use b_sum to construct a term of type beautiful16?
Recall that b_sum is of type

∀nm : nat, beautifuln→beautifulm→beautiful (n + m)

If we can demonstrate the beauty of 5 and 11, we should
be done.

Definitionb_16_atmpt_2 : beautiful 16 := b_sum 5 11 admitadmit.

In the attempt above, we've omitted the proofs of the propositions
that 5 and 11 are beautiful. But the first of these is already
axiomatized in b_5:

Definitionb_16_atmpt_3 : beautiful 16 := b_sum 5 11 b_5admit.

What remains is to show that 11 is beautiful. We repeat the
procedure:

To recap, we've been guided by an informal proof that we have in
our minds, and we check the high level details before completing
the intricacies of the proof. The admit term allows us to do
this.

Additional Exercises

Exercise: 4 stars (palindromes)

A palindrome is a sequence that reads the same backwards as
forwards.

Define an inductive proposition pal on listX that
captures what it means to be a palindrome. (Hint: You'll need
three cases. Your definition should be based on the structure
of the list; just having a single constructor

c : ∀l, l = revl→pall

may seem obvious, but will not work very well.)

Prove that

∀l, pal (l ++ revl).

Prove that

∀l, pall→l = revl.

(* FILL IN HERE *)

☐

Exercise: 5 stars, optional (palindrome_converse)

Using your definition of pal from the previous exercise, prove
that

∀l, l = revl→pall.

(* FILL IN HERE *)

☐

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,

[1,2,3]

is a subsequence of each of the lists

[1,2,3]
[1,1,1,2,2,3]
[1,2,7,3]
[5,6,1,9,9,2,7,3,8]

but it is not a subsequence of any of the lists

[1,2]
[1,3]
[5,6,2,1,7,3,8]

Define an inductive proposition subseq on listnat that
captures what it means to be a subsequence. (Hint: You'll need
three cases.)

Prove that subsequence is reflexive, that is, any list is a
subsequence of itself.

Prove that for any lists l1, l2, and l3, if l1 is a
subsequence of l2, then l1 is also a subsequence of l2++l3.

(Optional, harder) Prove that subsequence is transitive — that
is, if l1 is a subsequence of l2 and l2 is a subsequence
of l3, then l1 is a subsequence of l3. Hint: choose your
induction carefully!