Coq's built-in logic is very small: the only primitives are Inductive definitions, universal quantification (∀), and implication (→), while all the other familiar logical connectives — conjunction, disjunction, negation, existential quantification, even equality — can be encoded using just these. This chapter explains the encodings and shows how the tactics we've seen can be used to carry out standard forms of logical reasoning involving these connectives.

Conjunction

Logical conjunction is a binary operator on propositions:

Intuition: To construct evidence for and P Q, we must provide evidence for P and evidence for Q. Conversely, evidence for and P Q must be of the form conj p q, where p is evidence for P and q is evidence for Q. More familiar syntax:

Consider the "type" of the constructor conj:

The tactics we already know can be used prove things involving conjunctions.

Just for convenience, we can use the tactic split as a shorthand for apply conj.

Conversely, the inversion tactic can be used to take a conjunction hypothesis in the context, calculate what evidence must have been used to build it, and add variables representing this evidence to the proof context.

Iff

The handy "if and only if" connective is just the conjunction of two implications.

Disjunction

Intuitively, there are two ways of giving evidence for P ∨ Q:

• give evidence for P (and say that it is P you are giving evidence for — this is the function of the or_introl constructor), or
• give evidence for Q, tagged with the or_intror constructor.

Since P ∨ Q has two constructors, doing inversion on a hypothesis of type P ∨ Q yields two subgoals.

From here on, we'll use the shorthand tactics left and right in place of apply or_introl and apply or_intror.

Falsehood

Logical falsehood can be represented in Coq as an inductively defined proposition with no constructors.

Intuition: False is a proposition for which there is no way to give evidence.

How does this work? The inversion tactic breaks contra into each of its possible cases, and yields a subgoal for each case. As contra is evidence for False, it has no possible cases, hence, there are no possible subgoals and the proof is done. Conversely, the only way to prove False is if there is already something nonsensical or contradictory in the context:

Negation

Intuition: If we could prove P, then we could prove False (and hence we could prove anything at all).

Note that some theorems that are true in classical logic are not provable in Coq's (constructive) logic. E.g., let's look at how this proof gets stuck...

Inequality

Saying x ≠ y is just the same as saying ~(x = y).

A useful proof idiom: If you are trying to prove a goal that is nonsensical, apply the lemma ex_falso_quodlibet to change the goal to False. This makes it easier to use assumptions of the form ¬P that are available in the context.

Existential Quantification

Another critical logical connective is existential quantification. We can express it with the following definition:

That is, ex is a family of propositions indexed by a type X and a property P over X. In order to give evidence for the assertion "there exists an x for which the property P holds" we must actually name a witness — a specific value x — and then give evidence for P x, i.e., evidence that x has the property P. Standard notations for existentials:

The details of how these notations work are not too important: the critical point is that they allow us to write ∃ x, P or ∃ x:X, P, just as we do with the ∀ quantifier. To prove an existential statement, use apply ex_intro.

Note that we have to explicitly give the witness. Or, instead of writing apply ex_intro with (witness:=e) all the time, we can use the convenient shorthand ∃ e, which means the same thing.

Conversely, if we have an existential hypothesis in the context, we can eliminate it with inversion. Note the use of the as... pattern to name the variable that Coq introduces to name the witness value and get evidence that the hypothesis holds for the witness. (If we don't explicitly choose one, Coq will just call it witness, which makes proofs confusing.)

Equality

Even Coq's equality relation is not built in. It has (roughly) the following inductive definition.

Standard infix notation:

The definition of = is a bit subtle. The way to think about it is that, given a set X, it defines a family of propositions "x is equal to y," indexed by pairs of values (x and y) from X. There is just one way of constructing evidence for members of this family: applying the constructor refl_equal to a type X and a value x : X yields evidence that x is equal to x. We can use refl_equal to construct evidence that, for example, 2 = 2. Can we also use it to construct evidence that 1 + 1 = 2? Yes: indeed, it is the very same piece of evidence! The reason is that Coq treats as "the same" any two terms that are convertible according to a simple set of computation rules. These rules, which are similar to those used by Eval compute, include evaluation of function application, inlining of definitions, and simplification of matches.

The reflexivity tactic that we have used to prove equalities up to now is essentially just short-hand for apply refl_equal.

Evidence-carrying booleans.

So far we've seen two different forms of equality predicates: eq, which produces a Prop, and the type-specific forms, like beq_nat, that produce boolean values. The former are more convenient to reason about, but we've relied on the latter to let us use equality tests in computations. While it is straightforward to write lemmas (e.g. beq_nat_true and beq_nat_false) that connect the two forms, using these lemmas quickly gets tedious. It turns out that we can get the benefits of both forms at once by using a construct called sumbool.

Think of sumbool as being like the boolean type, but instead of its values being just true and false, they carry evidence of truth or falsity. This means that when we destruct them, we are left with the relevant evidence as a hypothesis — just as with or. (In fact, the definition of sumbool is almost the same as for or. The only difference is that values of sumbool are declared to be in Set rather than in Prop; this is a technical distinction that allows us to compute with them.) Here's how we can define a sumbool for equality on nats

Read as a theorem, this says that equality on nats is decidable: that is, given two nat values, we can always produce either evidence that they are equal or evidence that they are not. Read computationally, eq_nat_dec takes two nat values and returns a sumbool constructed with left if they are equal and right if they are not; this result can be tested with a match or, better, with an if-then-else, just like a regular boolean. (Notice that we ended this proof with Defined rather than Qed. The only difference this makes is that the proof becomes transparent, meaning that its definition is available when Coq tries to do reductions, which is important for the computational interpretation.) Here's a simple example illustrating the advantages of the sumbool form.

Compare this to the more laborious proof (in MoreCoq.v) for the version of override defined using beq_nat, where we had to use the auxiliary lemma beq_nat_true to convert a fact about booleans to a Prop.

Inversion, Again (Advanced)

We've seen inversion used with both equality hypotheses and hypotheses about inductively defined propositions. Now that we've seen that these are actually the same thing, we're in a position to take a closer look at how inversion behaves... In general, the inversion tactic

• takes a hypothesis H whose type P is inductively defined, and
• for each constructor C in P's definition,
  • generates a new subgoal in which we assume H was built with C,
  • adds the arguments (premises) of C to the context of the subgoal as extra hypotheses,
  • matches the conclusion (result type) of C against the current goal and calculates a set of equalities that must hold in order for C to be applicable,
  • adds these equalities to the context (and, for convenience, rewrites them in the goal), and
  • if the equalities are not satisfiable (e.g., they involve things like S n = O), immediately solves the subgoal.

Example: If we invert a hypothesis built with or, there are two constructors, so two subgoals get generated. The conclusion (result type) of the constructor (P ∨ Q) doesn't place any restrictions on the form of P or Q, so we don't get any extra equalities in the context of the subgoal. Example: If we invert a hypothesis built with and, there is only one constructor, so only one subgoal gets generated. Again, the conclusion (result type) of the constructor (P ∧ Q) doesn't place any restrictions on the form of P or Q, so we don't get any extra equalities in the context of the subgoal. The constructor does have two arguments, though, and these can be seen in the context in the subgoal. Example: If we invert a hypothesis built with eq, there is again only one constructor, so only one subgoal gets generated. Now, though, the form of the refl_equal constructor does give us some extra information: it tells us that the two arguments to eq must be the same! The inversion tactic adds this fact to the context.