So far, we have seen...

• propositions: mathematical statements, so far only of 3 kinds:
  • equality propositions (e₁ = e₂)
  • implications (P → Q)
  • quantified propositions (∀ x, P)
• proofs: ways of presenting evidence for the truth of a proposition

In this chapter we will introduce several more flavors of both propositions and proofs.

The Prop Type

Like everything in Rocq, well-formed propositions have a type:

Note that all syntactically well-formed propositions have type Prop in Rocq, regardless of whether they are true or not. Simply being a proposition is one thing; being provable is a different thing!

So far, we've seen one primary place where propositions can appear: in Theorem (and Lemma and Example) declarations.

Propositions are first-class entities in Rocq, though. For example, we can name them:

We can also write parameterized propositions -- that is, functions that take arguments of some type and return a proposition.

In Rocq, functions that return propositions are said to define properties of their arguments. For instance, here's a (polymorphic) property defining the familiar notion of an injective function.

The familiar equality operator = is a (binary) function that returns a Prop. The expression n = m is syntactic sugar for eq n m (defined in Rocq's standard library using the Notation mechanism). Because eq can be used with elements of any type, it is also polymorphic:

Logical Connectives

Conjunction

The conjunction, or logical and, of propositions A and B is written A ∧ B; it represents the claim that both A and B are true.

To prove a conjunction, start with the split tactic. This will generate two subgoals, one for each part of the statement:

For any propositions A and B, if we assume that A and B are each true individually, we can conclude that A ∧ B is also true. The Rocq library provides a function conj that does this.

we can apply conj to achieve the same effect as split.

So much for proving conjunctive statements. To go in the other direction -- i.e., to use a conjunctive hypothesis to help prove something else -- we can use our good old destruct tactic.

As usual, we can also destruct H right at the point where we introduce it, instead of introducing and then destructing it:

The infix notation ∧ is actually just syntactic sugar for and A B. That is, and is a Rocq operator that takes two propositions as arguments and yields a proposition.

Disjunction

Another important connective is the disjunction, or logical or, of two propositions: A ∨ B is true when either A or B is. This infix notation stands for or A B, where or : Prop → Prop → Prop.

To use a disjunctive hypothesis in a proof, we proceed by case analysis -- which, as with other data types like nat, can be done explicitly with destruct or implicitly with an intros pattern:

Conversely, to show that a disjunction holds, it suffices to show that one of its sides holds. This can be done via the tactics left and right. As their names imply, the first one requires proving the left side of the disjunction, while the second requires proving the right side. Here is a trivial use...

... and here is a slightly more interesting example requiring both left and right:

Falsehood and Negation

Up to this point, we have mostly been concerned with proving "positive" statements -- addition is commutative, appending lists is associative, etc. We are sometimes also interested in negative results, demonstrating that some proposition is not true. Such statements are expressed with the logical negation operator ¬.

To see how negation works, recall the principle of explosion from the Tactics chapter, which asserts that, if we assume a contradiction, then any other proposition can be derived. Following this intuition, we could define ¬ P ("not P") as ∀ Q, P → Q.

Rocq actually makes an equivalent but slightly different choice, defining ¬ P as P → False, where False is a specific un-provable proposition defined in the standard library.

Since False is a contradictory proposition, the principle of explosion also applies to it. If we can get False into the context, we can use destruct on it to complete any goal:

Inequality is a very common form of negated statement, so there is a special notation for it:

For example:

It takes a little practice to get used to working with negation in Rocq. Even though you may see perfectly well why a claim involving negation holds, it can be a little tricky at first to see how to make Rocq understand it! Here are proofs of a few familiar facts to help get you warmed up.

Since inequality involves a negation, getting comfortable with it also often requires a little practice. A useful trick: if you are trying to prove a nonsensical goal, apply ex_falso_quodlibet to change the goal to False. This makes it easier to use assumptions of the form ¬P, and in particular of the form x≠y.

Truth

Besides False, Rocq's standard library also defines True, a proposition that is trivially true. To prove it, we use the constant I : True, which is also defined in the standard library:

Unlike False, which is used extensively, True is used relatively rarely: it is trivial (and therefore uninteresting) to prove as a goal, and it provides no useful information when it appears as a hypothesis.

Logical Equivalence

The handy "if and only if" connective, which asserts that two propositions have the same truth value, is simply the conjunction of two implications.
      Print "<->".

The apply tactic can also be used with ↔.

Setoids and Logical Equivalence

Some of Rocq's tactics treat iff statements specially, avoiding some low-level proof-state manipulation. In particular, rewrite and reflexivity can be used with iff statements, not just equalities. To enable this behavior, we have to import the Rocq library that supports it:

A "setoid" is a set equipped with an equivalence relation, such as = or ↔.

Here is a simple example demonstrating how these tactics work with iff. First, let's prove a couple of basic iff equivalences. (For these proofs we are not using setoids yet.)

We can now use these facts with rewrite and reflexivity to prove a ternary version of the mult_eq_0 fact above without splitting the top-level iff:

Existential Quantification

To prove a statement of the form ∃ x, P, we must show that P holds for some specific choice for x, known as the witness of the existential. This is done in two steps: First, we explicitly tell Rocq which witness t we have in mind by invoking the tactic ∃ t. Then we prove that P holds after all occurrences of x are replaced by t.

Conversely, if we have an existential hypothesis ∃ x, P in the context, we can destruct it to obtain a witness x and a hypothesis stating that P holds of x.

Recap -- Logical connectives in Rocq

Basic connectives:

• and : Prop → Prop → Prop (conjunction):
  • introduced with the split tactic
  • eliminated with destruct H as [H₁ H₂]
• or : Prop → Prop → Prop (disjunction):
  • introduced with left and right tactics
  • eliminated with destruct H as [H₁ | H₂]
• False : Prop
  • eliminated with destruct H as []
• True : Prop
  • introduced with apply I, but not as useful
• ex : ∀ A:Type, (A → Prop) → Prop (existential)
  • introduced with ∃ w
  • eliminated with destruct H as [x H]

Derived connectives:

• not : Prop → Prop (negation):
  • not P defined as P → False
• iff : Prop → Prop → Prop (logical equivalence):
  • iff P Q defined as (P → Q) ∧ (Q → P)

Fundamental connectives we've been using since the beginning:

• equality (e₁ = e₂)
• implication (P → Q)
• universal quantification (∀ x, P)

Programming with Propositions

What does it mean to say that "an element x occurs in a list l"?

• If l is the empty list, then x cannot occur in it, so the property "x appears in l" is simply false.

• Otherwise, l has the form x' :: l'. In this case, x occurs in l if it is equal to x' or it occurs in l'.

We can translate this directly into a straightforward recursive function taking an element and a list and returning... a proposition!

When In is applied to a concrete list, it expands into a concrete sequence of nested disjunctions.

We can also reason about more generic statements involving In.

Applying Theorems to Arguments

Rocq also treats proofs as first-class objects! We have seen that we can use Check to ask Rocq to check whether an expression has a given type:

We can also use it to check what theorem a particular identifier refers to:

Rocq checks the statements of the add_comm and plus_id_example theorems in the same way that it checks the type of any term (e.g., plus). If we leave off the colon and type, Rocq will print these types for us. Why?

The reason is that the identifier add_comm actually refers to a proof object -- a logical derivation establishing the truth of the statement ∀ n m : nat, n + m = m + n. The type of this object is the proposition that it is a proof of.

The type of an ordinary function tells us what we can do with it.

• If we have a term of type nat → nat → nat, we can give it two nats as arguments and get a nat back.

Similarly, the statement of a theorem tells us what we can use that theorem for.

• If we have a term of type ∀ n m, n = m → n + n = m + m and we provide it two numbers n and m and a third "argument" of type n = m, we get back a proof object of type n + n = m + m.

Rocq actually allows us to apply a theorem as if it were a function. This is often handy in proof scripts -- e.g., suppose we want too prove the following:

It appears at first sight that we ought to be able to prove this by rewriting with add_comm twice to make the two sides match. The problem is that the second rewrite will undo the effect of the first.

We can fix this by applying add_comm to the arguments we want it be to instantiated with. Then the rewrite is forced to happen exactly where we want it.

Here's another example of using a theorem about lists like a function. Suppose we have proved the following simple fact about lists...

Note that one quantified variable (x) does not appear in the conclusion (l ≠ []). Intuitively, we should be able to use this theorem to prove the special case where x is 42. However, simply invoking the tactic apply in_not_nil will fail because it cannot infer the value of x.

There are several ways to work around this: We can use apply ... with ...:

Or we can use apply ... in ...:

Or -- this is the new one -- we can explicitly apply the lemma to the value 42 for x:

We can also explicitly apply the lemma to a hypothesis, causing the values of the other parameters to be inferred:

Working with Decidable Properties

We've seen two different ways of expressing logical claims in Rocq: with booleans (of type bool), and with propositions (of type Prop). Here are the key differences between bool and Prop:

                                           bool     Prop
                                           ====     ====
           decidable?                      yes       no
           useable with match?             yes       no
           works with rewrite tactic?      no        yes

Since every function terminates on all inputs in Rocq, a function of type nat → bool is a decision procedure -- i.e., it yields true or false on all inputs.

• For example, even : nat → bool is a decision procedure for the property "is even".

It follows that there are some properties of numbers that we cannot express as functions of type nat → bool.

• For example, the property "is the code of a halting Turing machine" is undecidable, so there is no way to write it as a function of type nat → bool.

On the other hand, nat→Prop is the type of all properties of numbers that can be expressed in Rocq's logic, including both decidable and undecidable ones.

• For example, "is the code of a halting Turing machine" is a perfectly legitimate mathematical property, and we can absolutely represent it as a Rocq expression of type nat → Prop.

Since Prop includes both decidable and undecidable properties, we have two options when we want to formalize a property that happens to be decidable: we can express it either as a boolean computation or as a function into Prop. For instance, to claim that a number n is even, we can say either that even n evaluates to true...

... or that there exists some k such that n = double k.

Of course, it would be deeply strange if these two characterizations of evenness did not describe the same set of natural numbers! Fortunately, they do!

Now the main theorem:

In view of this theorem, we can say that the boolean computation even n is reflected in the truth of the proposition ∃ k, n = double k.

Similarly, to state that two numbers n and m are equal, we can say either

• (1) that n =? m returns true, or
• (2) that n = m.

Again, these two notions are equivalent:

So what should we do in situations where some claim could be formalized as either a proposition or a boolean computation? Which should we choose? In general, both can be useful. For example, booleans are more useful for defining functions. There is no effective way to test whether or not a Prop is true, so we cannot use Props in conditional expressions. The following definition is rejected:

Rather, we have to state this definition using a boolean equality test.

More generally, stating facts using booleans can often enable effective proof automation through computation with Rocq terms, a technique known as proof by reflection. Consider the following statement:

The most direct way to prove this is to give the value of k explicitly.

The proof of the corresponding boolean statement is simpler, because we don't have to invent the witness 500: Rocq's computation mechanism does it for us!

Now, the useful observation is that, since the two notions are equivalent, we can use the boolean formulation to prove the other one without mentioning the value 500 explicitly:

Although we haven't gained much in terms of proof-script line count in this case, larger proofs can often be made considerably simpler by the use of reflection. As an extreme example, a famous Rocq proof of the even more famous 4-color theorem uses reflection to reduce the analysis of hundreds of different cases to a boolean computation.

Another advantage of booleans is that the negation of a claim about booleans is straightforward to state and (when true) prove: simply flip the expected boolean result.

In contrast, propositional negation can be difficult to work with directly. For example, suppose we state the non-evenness of 1001 propositionally:

Proving this directly -- by assuming that there is some n such that 1001 = double n and then somehow reasoning to a contradiction -- would be rather complicated. But if we convert it to a claim about the boolean even function, we can let Rocq do the work for us.

Conversely, there are situations where it can be easier to work with propositions rather than booleans. In particular, knowing that (n =? m) = true is generally of little direct help in the middle of a proof involving n and m. But if we convert the statement to the equivalent form n = m, then we can easily rewrite with it.

Being able to cross back and forth between the boolean and propositional worlds will often be convenient in later chapters.

The Logic of Rocq

Rocq's logical core, the Calculus of Inductive Constructions, is a "metalanguage for mathematics" in the same sense as familiar foundations for paper-and-pencil math, like Zermelo-Fraenkel Set Theory (ZFC). Mostly, the differences are not too important, but a few points are useful to understand.

Functional Extensionality

Rocq's logic is quite minimalistic. This means that one occasionally encounters cases where translating standard mathematical reasoning into Rocq is cumbersome -- or even impossible -- unless we enrich its core logic with additional axioms. A first instance has to do with equality of functions. In certain cases Rocq can successfully prove equality propositions stating that two functions are equal to each other:

This works when Rocq can simplify the functions to the same expression, but this doesn't always happen.

These two functions are equal just by simplification, but in general functions can be equal for more interesting reasons. In common mathematical practice, two functions f and g are considered equal if they produce the same output on every input:
    (∀ x, f x = g x) → f = g This is known as the principle of functional extensionality. However, functional extensionality is not part of Rocq's built-in logic. This means that some intuitively obvious propositions are not provable.

However, if we like, we can add functional extensionality to Rocq using the Axiom command.

Defining something as an Axiom has the same effect as stating a theorem and skipping its proof using Admitted, but it alerts the reader that this isn't just something we're going to come back and fill in later!

We can now invoke functional extensionality in proofs:

Naturally, we need to be quite careful when adding new axioms into Rocq's logic, as this can render it inconsistent -- that is, it may become possible to prove every proposition, including False, 2+2=5, etc.! In general, there is no simple way of telling whether an axiom is safe to add: hard work by highly trained mathematicians is often required to establish the consistency of any particular combination of axioms. Fortunately, it is known that adding functional extensionality, in particular, is consistent.

To check whether a particular proof relies on any additional axioms, use the Print Assumptions command:
      Print Assumptions function_equality_ex₂.

Classical vs. Constructive Logic

The following reasoning principle is not derivable in Rocq (though, again, it can consistently be added as an axiom):

Logics like Rocq's, which do not assume the excluded middle, are referred to as constructive logics. Logical systems such as ZFC, in which the excluded middle does hold for arbitrary propositions, are referred to as classical.