Gérard Huet, Gilles Kahn and Christine Paulin-Mohring
π r2 Project (formerly LogiCal, then TypiCal)
©INRIA 1999-2004 (Coq versions 7.x)
©INRIA 2004-2017 (Coq versions 8.x)
Coq is a Proof Assistant for a Logical Framework known as the Calculus of Inductive Constructions. It allows the interactive construction of formal proofs, and also the manipulation of functional programs consistently with their specifications. It runs as a computer program on many architectures.
It is available with a variety of user interfaces. The present document does not attempt to present a comprehensive view of all the possibilities of Coq, but rather to present in the most elementary manner a tutorial on the basic specification language, called Gallina, in which formal axiomatisations may be developed, and on the main proof tools. For more advanced information, the reader could refer to the Coq Reference Manual or the Coq’Art, a book by Y. Bertot and P. Castéran on practical uses of the Coq system.
Instructions on installation procedures, as well as more comprehensive documentation, may be found in the standard distribution of Coq, which may be obtained from Coq web site https://coq.inria.fr/1. Coq is distributed together with a graphical user interface called CoqIDE. Alternative interfaces exist such as Proof General2.
In the following examples, lines preceded by the prompt Coq <
represent user input, terminated by a period.
The following lines usually show Coq’s answer.
When used from a graphical user interface such as
CoqIDE, the prompt is not displayed: user input is given in one window
and Coq’s answers are displayed in a different window.
A formal development in Gallina consists in a sequence of declarations and definitions.
A declaration associates a name with a specification.
A name corresponds roughly to an identifier in a programming
language, i.e. to a string of letters, digits, and a few ASCII symbols like
underscore (_) and prime ('), starting with a letter.
We use case distinction, so that the names A and a are distinct.
Certain strings are reserved as key-words of Coq, and thus are forbidden
as user identifiers.
A specification is a formal expression which classifies the notion which is
being declared. There are basically three kinds of specifications:
logical propositions, mathematical collections, and
abstract types. They are classified by the three basic sorts
of the system, called respectively Prop, Set, and
Type, which are themselves atomic abstract types.
Every valid expression e in Gallina is associated with a specification,
itself a valid expression, called its type τ(E). We write
e:τ(E) for the judgment that e is of type E.
You may request Coq to return to you the type of a valid expression by using
the command Check:
Thus we know that the identifier O (the name ‘O’, not to be
confused with the numeral ‘0’ which is not a proper identifier!) is
known in the current context, and that its type is the specification
nat. This specification is itself classified as a mathematical
collection, as we may readily check:
The specification Set is an abstract type, one of the basic
sorts of the Gallina language, whereas the notions nat and O are
notions which are defined in the arithmetic prelude,
automatically loaded when running the Coq system.
We start by introducing a so-called section name. The role of sections is to structure the modelisation by limiting the scope of parameters, hypotheses and definitions. It will also give a convenient way to reset part of the development.
With what we already know, we may now enter in the system a declaration, corresponding to the informal mathematics let n be a natural number.
If we want to translate a more precise statement, such as
let n be a positive natural number,
we have to add another declaration, which will declare explicitly the
hypothesis Pos_n, with specification the proper logical
proposition:
Indeed we may check that the relation gt is known with the right type
in the current context:
which tells us that gt is a function expecting two arguments of type nat in order to build a logical proposition. What happens here is similar to what we are used to in a functional programming language: we may compose the (specification) type nat with the (abstract) type Prop of logical propositions through the arrow function constructor, in order to get a functional type nat -> Prop:
which may be composed once more with nat in order to obtain the
type nat -> nat -> Prop of binary relations over natural numbers.
Actually the type nat -> nat -> Prop is an abbreviation for
nat -> (nat -> Prop).
Functional notions may be composed in the usual way. An expression f
of type A→ B may be applied to an expression e of type A in order
to form the expression (f e) of type B. Here we get that
the expression (gt n) is well-formed of type nat -> Prop,
and thus that the expression (gt n O), which abbreviates
((gt n) O), is a well-formed proposition.
The initial prelude contains a few arithmetic definitions: nat is defined as a mathematical collection (type Set), constants O, S, plus, are defined as objects of types respectively nat, nat -> nat, and nat -> nat -> nat. You may introduce new definitions, which link a name to a well-typed value. For instance, we may introduce the constant one as being defined to be equal to the successor of zero:
We may optionally indicate the required type:
Actually Coq allows several possible syntaxes:
Here is a way to define the doubling function, which expects an
argument m of type nat in order to build its result as
(plus m m):
This introduces the constant double defined as the expression fun m : nat => plus m m. The abstraction introduced by fun is explained as follows. The expression fun x : A => e is well formed of type A -> B in a context whenever the expression e is well-formed of type B in the given context to which we add the declaration that x is of type A. Here x is a bound, or dummy variable in the expression fun x : A => e. For instance we could as well have defined double as fun n : nat => (plus n n).
Bound (local) variables and free (global) variables may be mixed.
For instance, we may define the function which adds the constant n
to its argument as
However, note that here we may not rename the formal argument m into n without capturing the free occurrence of n, and thus changing the meaning of the defined notion.
Binding operations are well known for instance in logic, where they are called quantifiers. Thus we may universally quantify a proposition such as m>0 in order to get a universal proposition ∀ m· m>0. Indeed this operator is available in Coq, with the following syntax: forall m : nat, gt m O. Similarly to the case of the functional abstraction binding, we are obliged to declare explicitly the type of the quantified variable. We check:
In the following, we are going to consider various propositions, built
from atomic propositions A, B, C. This may be done easily, by
introducing these atoms as global variables declared of type Prop.
It is easy to declare several names with the same specification:
We shall consider simple implications, such as A→ B, read as “A implies B”. Note that we overload the arrow symbol, which has been used above as the functionality type constructor, and which may be used as well as propositional connective:
Let us now embark on a simple proof. We want to prove the easy tautology
((A→ (B→ C))→ (A→ B)→ (A→ C).
We enter the proof engine by the command
Goal, followed by the conjecture we want to verify:
The system displays the current goal below a double line, local hypotheses
(there are none initially) being displayed above the line. We call
the combination of local hypotheses with a goal a judgment.
We are now in an inner
loop of the system, in proof mode.
New commands are available in this
mode, such as tactics, which are proof combining primitives.
A tactic operates on the current goal by attempting to construct a proof
of the corresponding judgment, possibly from proofs of some
hypothetical judgments, which are then added to the current
list of conjectured judgments.
For instance, the intro tactic is applicable to any judgment
whose goal is an implication, by moving the proposition to the left
of the application to the list of local hypotheses:
Several introductions may be done in one step:
We notice that C, the current goal, may be obtained from hypothesis
H, provided the truth of A and B are established.
The tactic apply implements this piece of reasoning:
We are now in the situation where we have two judgments as conjectures
that remain to be proved. Only the first is listed in full, for the
others the system displays only the corresponding subgoal, without its
local hypotheses list. Note that apply has kept the local
hypotheses of its father judgment, which are still available for
the judgments it generated.
In order to solve the current goal, we just have to notice that it is exactly available as hypothesis HA:
Now H′ applies:
And we may now conclude the proof as before, with exact HA.
Actually, we may not bother with the name HA, and just state that
the current goal is solvable from the current local assumptions:
The proof is now finished. We are now going to ask Coq’s kernel to check and save the proof.
Let us redo the same proof with a few variations. First of all we may name the initial goal as a conjectured lemma:
Next, we may omit the names of local assumptions created by the introduction tactics, they can be automatically created by the proof engine as new non-clashing names.
The intros tactic, with no arguments, effects as many individual
applications of intro as is legal.
Then, we may compose several tactics together in sequence, or in parallel, through tacticals, that is tactic combinators. The main constructions are the following:
We may thus complete the proof of distr_impl with one composite tactic:
You should be aware however that relying on automatically generated names is not robust to slight updates to this proof script. Consequently, it is discouraged in finished proof scripts. As for the composition of tactics with : it may hinder the readability of the proof script and it is also harder to see what’s going on when replaying the proof because composed tactics are evaluated in one go.
Actually, such an easy combination of tactics intro, apply
and assumption may be found completely automatically by an automatic
tactic, called auto, without user guidance:
Let us now save lemma distr_impl:
We have seen how intro and apply tactics could be combined
in order to prove implicational statements. More generally, Coq favors a style
of reasoning, called Natural Deduction, which decomposes reasoning into
so called introduction rules, which tell how to prove a goal whose main
operator is a given propositional connective, and elimination rules,
which tell how to use an hypothesis whose main operator is the propositional
connective. Let us show how to use these ideas for the propositional connectives
/\ and \/.
We make use of the conjunctive hypothesis H with the elim tactic,
which breaks it into its components:
We now use the conjunction introduction tactic split, which splits the
conjunctive goal into the two subgoals:
and the proof is now trivial. Indeed, the whole proof is obtainable as follows:
The tactic auto succeeded here because it knows as a hint the
conjunction introduction operator conj
Actually, the tactic split is just an abbreviation for apply conj.
What we have just seen is that the auto tactic is more powerful than
just a simple application of local hypotheses; it tries to apply as well
lemmas which have been specified as hints. A
Hint Resolve command registers a
lemma as a hint to be used from now on by the auto tactic, whose power
may thus be incrementally augmented.
In a similar fashion, let us consider disjunction:
Let us prove the first subgoal in detail. We use intro in order to
be left to prove B\/A from A:
Here the hypothesis H is not needed anymore. We could choose to
actually erase it with the tactic clear; in this simple proof it
does not really matter, but in bigger proof developments it is useful to
clear away unnecessary hypotheses which may clutter your screen.
The tactic destruct combines the effects of elim, intros,
and clear:
The disjunction connective has two introduction rules, since P\/Q
may be obtained from P or from Q; the two corresponding
proof constructors are called respectively or_introl and
or_intror; they are applied to the current goal by tactics
left and right respectively. For instance:
The tactic trivial works like auto with the hints
database, but it only tries those tactics that can solve the goal in one
step.
As before, all these tedious elementary steps may be performed automatically, as shown for the second symmetric case:
However, auto alone does not succeed in proving the full lemma, because
it does not try any elimination step.
It is a bit disappointing that auto is not able to prove automatically
such a simple tautology. The reason is that we want to keep
auto efficient, so that it is always effective to use.
A complete tactic for propositional
tautologies is indeed available in Coq as the tauto tactic.
It is possible to inspect the actual proof tree constructed by tauto,
using a standard command of the system, which prints the value of any notion
currently defined in the context:
It is not easy to understand the notation for proof terms without some
explanations. The fun prefix, such as fun H : A\/B =>,
corresponds
to intro H, whereas a subterm such as
(or_intror B H0)
corresponds to the sequence of tactics apply or_intror; exact H0.
The generic combinator or_intror needs to be instantiated by
the two properties B and A. Because A can be
deduced from the type of H0, only B is printed.
The two instantiations are effected automatically by the tactic
apply when pattern-matching a goal. The specialist will of course
recognize our proof term as a λ-term, used as notation for the
natural deduction proof term through the Curry-Howard isomorphism. The
naive user of Coq may safely ignore these formal details.
Let us exercise the tauto tactic on a more complex example:
The tactic tauto always comes back with an answer. Here is an example where it
fails:
Note the use of the try tactical, which does nothing if its tactic
argument fails.
This may come as a surprise to someone familiar with classical reasoning.
Peirce’s lemma is true in Boolean logic, i.e. it evaluates to true for
every truth-assignment to A and B. Indeed the double negation
of Peirce’s law may be proved in Coq using tauto:
In classical logic, the double negation of a proposition is equivalent to this
proposition, but in the constructive logic of Coq this is not so. If you
want to use classical logic in Coq, you have to import explicitly the
Classical module, which will declare the axiom classic
of excluded middle, and classical tautologies such as de Morgan’s laws.
The Require command is used to import a module from Coq’s library:
and it is now easy (although admittedly not the most direct way) to prove a classical law such as Peirce’s:
Here is one more example of propositional reasoning, in the shape of a Scottish puzzle. A private club has the following rules:
Now, we show that these rules are so strict that no one can be accepted.
At that point NoMember is a proof of the absurdity depending on
hypotheses.
We may end the section, in that case, the variables and hypotheses
will be discharged, and the type of NoMember will be
generalised.
Let us now move into predicate logic, and first of all into first-order predicate calculus. The essence of predicate calculus is that to try to prove theorems in the most abstract possible way, without using the definitions of the mathematical notions, but by formal manipulations of uninterpreted function and predicate symbols.
Usually one works in some domain of discourse, over which range the individual
variables and function symbols. In Coq, we speak in a language with a rich
variety of types, so we may mix several domains of discourse, in our
multi-sorted language. For the moment, we just do a few exercises, over a
domain of discourse D axiomatised as a Set, and we consider two
predicate symbols P and R over D, of arities
1 and 2, respectively.
We start by assuming a domain of
discourse D, and a binary relation R over D:
As a simple example of predicate calculus reasoning, let us assume
that relation R is symmetric and transitive, and let us show that
R is reflexive in any point x which has an R successor.
Since we do not want to make the assumptions about R global axioms of
a theory, but rather local hypotheses to a theorem, we open a specific
section to this effect.
Note the syntax forall x : D, which stands for universal quantification
∀ x : D.
We now state our lemma, and enter proof mode.
The hypotheses that are local to the currently opened sections are listed as local hypotheses to the current goals. That is because these hypotheses are going to be discharged, as we shall see, when we shall close the corresponding sections.
Note the functional syntax for existential quantification. The existential
quantifier is built from the operator ex, which expects a
predicate as argument:
and the notation (exists x : D, P x) is just concrete syntax for
the expression (ex D (fun x : D => P x)).
Existential quantification is handled in Coq in a similar
fashion to the connectives /\ and \/: it is introduced by
the proof combinator ex_intro, which is invoked by the specific
tactic exists, and its elimination provides a witness a : D to
P, together with an assumption h : (P a) that indeed a
verifies P. Let us see how this works on this simple example.
Note that intros treats universal quantification in the same way
as the premises of implications. Renaming of bound variables occurs
when it is needed; for instance, had we started with intro y,
we would have obtained the goal:
Let us now use the existential hypothesis x_Rlinked to
exhibit an R-successor y of x. This is done in two steps, first with
elim, then with intros
Now we want to use R_transitive. The apply tactic will know
how to match x with x, and z with x, but needs
help on how to instantiate y, which appear in the hypotheses of
R_transitive, but not in its conclusion. We give the proper hint
to apply in a with clause, as follows:
The rest of the proof is routine:
Let us now close the current section.
All the local hypotheses have been
discharged in the statement of refl_if, which now becomes a general
theorem in the first-order language declared in section
Predicate_calculus. In this particular example, section
R_sym_trans has not been really useful, since we could have
instead stated theorem refl_if in its general form, and done
basically the same proof, obtaining R_symmetric and
R_transitive as local hypotheses by initial intros rather
than as global hypotheses in the context. But if we had pursued the
theory by proving more theorems about relation R,
we would have obtained all general statements at the closing of the section,
with minimal dependencies on the hypotheses of symmetry and transitivity.
Let us illustrate this feature by pursuing our Predicate_calculus
section with an enrichment of our language: we declare a unary predicate
P and a constant d:
We shall now prove a well-known fact from first-order logic: a universal predicate is non-empty, or in other terms existential quantification follows from universal quantification.
First of all, notice the pair of parentheses around
forall x : D, P x in
the statement of lemma weird.
If we had omitted them, Coq’s parser would have interpreted the
statement as a truly trivial fact, since we would
postulate an x verifying (P x). Here the situation is indeed
more problematic. If we have some element in Set D, we may
apply UnivP to it and conclude, otherwise we are stuck. Indeed
such an element d exists, but this is just by virtue of our
new signature. This points out a subtle difference between standard
predicate calculus and Coq. In standard first-order logic,
the equivalent of lemma weird always holds,
because such a rule is wired in the inference rules for quantifiers, the
semantic justification being that the interpretation domain is assumed to
be non-empty. Whereas in Coq, where types are not assumed to be
systematically inhabited, lemma weird only holds in signatures
which allow the explicit construction of an element in the domain of
the predicate.
Let us conclude the proof, in order to show the use of the exists
tactic:
Another fact which illustrates the sometimes disconcerting rules of
classical
predicate calculus is Smullyan’s drinkers’ paradox: “In any non-empty
bar, there is a person such that if she drinks, then everyone drinks”.
We modelize the bar by Set D, drinking by predicate P.
We shall need classical reasoning. Instead of loading the Classical
module as we did above, we just state the law of excluded middle as a
local hypothesis schema at this point:
The proof goes by cases on whether or not
there is someone who does not drink. Such reasoning by cases proceeds
by invoking the excluded middle principle, via elim of the
proper instance of EM:
We first look at the first case. Let Tom be the non-drinker.
The following combines at once the effect of intros and
destruct:
We conclude in that case by considering Tom, since his drinking leads to a contradiction:
There are several ways in which we may eliminate a contradictory case;
in this case, we use contradiction to let Coq find out the
two contradictory hypotheses:
We now proceed with the second case, in which actually any person will do;
such a John Doe is given by the non-emptiness witness d:
Now we consider any Dick in the bar, and reason by cases according to its drinking or not:
The only non-trivial case is again treated by contradiction:
Now, let us close the main section and look at the complete statements we proved:
Note how the three theorems are completely generic in the most general
fashion;
the domain D is discharged in all of them, R is discharged in
refl_if only, P is discharged only in weird and
drinker, along with the hypothesis that D is inhabited.
Finally, the excluded middle hypothesis is discharged only in
drinker.
Note, too, that the name d has vanished from
the statements of weird and drinker,
since Coq’s pretty-printer replaces
systematically a quantification such as forall d : D, E,
where d does not occur in E,
by the functional notation D -> E.
Similarly the name EM does not appear in drinker.
Actually, universal quantification, implication, as well as function formation, are all special cases of one general construct of type theory called dependent product. This is the mathematical construction corresponding to an indexed family of functions. A function f∈ Π x:D· Cx maps an element x of its domain D to its (indexed) codomain Cx. Thus a proof of ∀ x:D· Px is a function mapping an element x of D to a proof of proposition Px.
Very often during the course of a proof we want to retrieve a local
assumption and reintroduce it explicitly in the goal, for instance
in order to get a more general induction hypothesis. The tactic
generalize is what is needed here:
Sometimes it may be convenient to state an intermediate fact.
The tactic assert does this and introduces a new subgoal
for this fact to be proved first. The tactic enough does
the same while keeping this goal for later.
We clean the goal by doing an Abort command.
The basic equality provided in Coq is Leibniz equality, noted infix like x = y, when x and y are two expressions of type the same Set. The replacement of x by y in any term is effected by a variety of tactics, such as rewrite and replace.
Let us give a few examples of equality replacement. Let us assume that
some arithmetic function f is null in zero:
We want to prove the following conditional equality:
As usual, we first get rid of local assumptions with intro:
Let us now use equation E as a left-to-right rewriting:
This replaced both occurrences of k by O.
Now apply foo will finish the proof:
When one wants to rewrite an equality in a right to left fashion, we should
use rewrite <- E rather than rewrite E or the equivalent
rewrite -> E.
Let us now illustrate the tactic replace.
What happened here is that the replacement left the first subgoal to be
proved, but another proof obligation was generated by the replace
tactic, as the second subgoal. The first subgoal is solved immediately
by applying lemma foo; the second one transitivity and then
symmetry of equality, for instance with tactics transitivity and
symmetry:
In case the equality t=u generated by replace u with
t is an assumption
(possibly modulo symmetry), it will be automatically proved and the
corresponding goal will not appear. For instance:
The development of mathematics does not simply proceed by logical argumentation from first principles: definitions are used in an essential way. A formal development proceeds by a dual process of abstraction, where one proves abstract statements in predicate calculus, and use of definitions, which in the contrary one instantiates general statements with particular notions in order to use the structure of mathematical values for the proof of more specialised properties.
Assume that we want to develop the theory of sets represented as characteristic
predicates over some universe U. For instance:
Now, assume that we have loaded a module of general properties about
relations over some abstract type T, such as transitivity:
We want to prove that subset is a transitive
relation.
In order to make any progress, one needs to use the definition of
transitive. The unfold tactic, which replaces all
occurrences of a defined notion by its definition in the current goal,
may be used here.
Now, we must unfold subset:
Now, unfolding element would be a mistake, because indeed a simple proof
can be found by auto, keeping element an abstract predicate:
Many variations on unfold are provided in Coq. For instance,
instead of unfolding all occurrences of subset, we may want to
unfold only one designated occurrence:
One may also unfold a definition in a given local hypothesis, using the
in notation:
Finally, the tactic red does only unfolding of the head occurrence
of the current goal:
Even though in principle the proof term associated with a verified lemma corresponds to a defined value of the corresponding specification, such definitions cannot be unfolded in Coq: a lemma is considered an opaque definition. This conforms to the mathematical tradition of proof irrelevance: the proof of a logical proposition does not matter, and the mathematical justification of a logical development relies only on provability of the lemmas used in the formal proof.
Conversely, ordinary mathematical definitions can be unfolded at will, they are transparent.
All the notions which were studied until now pertain to traditional mathematical logic. Specifications of objects were abstract properties used in reasoning more or less constructively; we are now entering the realm of inductive types, which specify the existence of concrete mathematical constructions.
Let us start with the collection of booleans, as they are specified
in the Coq’s Prelude module:
Such a declaration defines several objects at once. First, a new
Set is declared, with name bool. Then the constructors
of this Set are declared, called true and false.
Those are analogous to introduction rules of the new Set bool.
Finally, a specific elimination rule for bool is now available, which
permits to reason by cases on bool values. Three instances are
indeed defined as new combinators in the global context: bool_ind,
a proof combinator corresponding to reasoning by cases,
bool_rec, an if-then-else programming construct,
and bool_rect, a similar combinator at the level of types.
Indeed:
Let us for instance prove that every Boolean is true or false.
We use the knowledge that b is a bool by calling tactic
elim, which is this case will appeal to combinator bool_ind
in order to split the proof according to the two cases:
It is easy to conclude in each case:
Indeed, the whole proof can be done with the combination of the
destruct, which combines intro and elim,
with good old auto:
Similarly to Booleans, natural numbers are defined in the Prelude
module with constructors S and O:
The elimination principles which are automatically generated are Peano’s induction principle, and a recursion operator:
Let us start by showing how to program the standard primitive recursion
operator prim_rec from the more general nat_rec:
That is, instead of computing for natural i an element of the indexed
Set (P i), prim_rec computes uniformly an element of
nat. Let us check the type of prim_rec:
Oops! Instead of the expected type nat->(nat->nat->nat)->nat->nat we
get an apparently more complicated expression.
In fact, the two types are convertible and one way of having the proper
type would be to do some computation before actually defining prim_rec
as such:
Let us now show how to program addition with primitive recursion:
That is, we specify that (addition n m) computes by cases on n
according to its main constructor; when n = O, we get m;
when n = S p, we get (S rec), where rec is the result
of the recursive computation (addition p m). Let us verify it by
asking Coq to compute for us say 2+3:
Actually, we do not have to do all explicitly. Coq provides a special syntax Fixpoint/match for generic primitive recursion, and we could thus have defined directly addition as:
Let us now show how to do proofs by structural induction. We start with easy
properties of the plus function we just defined. Let us first
show that n=n+0.
What happened was that elim n, in order to construct a Prop (the initial goal) from a nat (i.e. n), appealed to the corresponding induction principle nat_ind which we saw was indeed exactly Peano’s induction scheme. Pattern-matching instantiated the corresponding predicate P to fun n : nat => n = n + 0, and we get as subgoals the corresponding instantiations of the base case (P O), and of the inductive step forall y : nat, P y -> P (S y). In each case we get an instance of function plus in which its second argument starts with a constructor, and is thus amenable to simplification by primitive recursion. The Coq tactic simpl can be used for this purpose:
We proceed in the same way for the base step:
Here auto succeeded, because it used as a hint lemma eq_S,
which say that successor preserves equality:
Actually, let us see how to declare our lemma plus_n_O as a hint
to be used by auto:
We now proceed to the similar property concerning the other constructor
S:
We now go faster, using the tactic induction, which does the
necessary intros before applying elim. Factoring simplification
and automation in both cases thanks to tactic composition, we prove this
lemma in one line:
Let us end this exercise with the commutativity of plus:
Here we have a choice on doing an induction on n or on m, the
situation being symmetric. For instance:
Here auto succeeded on the base case, thanks to our hint
plus_n_O, but the induction step requires rewriting, which
auto does not handle:
It is also possible to define new propositions by primitive recursion.
Let us for instance define the predicate which discriminates between
the constructors O and S: it computes to False
when its argument is O, and to True when its argument is
of the form (S n):
Now we may use the computational power of Is_S to prove
trivially that (Is_S (S n)):
But we may also use it to transform a False goal into
(Is_S O). Let us show a particularly important use of this feature;
we want to prove that O and S construct different values, one
of Peano’s axioms:
First of all, we replace negation by its definition, by reducing the
goal with tactic red; then we get contradiction by successive
intros:
Now we use our trick:
Now we use equality in order to get a subgoal which computes out to
True, which finishes the proof:
Actually, a specific tactic discriminate is provided
to produce mechanically such proofs, without the need for the user to define
explicitly the relevant discrimination predicates:
In the same way as we defined standard data-types above, we
may define inductive families, and for instance inductive predicates.
Here is the definition of predicate ≤ over type nat, as
given in Coq’s Prelude module:
This definition introduces a new predicate
le : nat -> nat -> Prop,
and the two constructors le_n and le_S, which are the
defining clauses of le. That is, we get not only the “axioms”
le_n and le_S, but also the converse property, that
(le n m) if and only if this statement can be obtained as a
consequence of these defining clauses; that is, le is the
minimal predicate verifying clauses le_n and le_S. This is
insured, as in the case of inductive data types, by an elimination principle,
which here amounts to an induction principle le_ind, stating this
minimality property:
Let us show how proofs may be conducted with this principle. First we show that n≤ m ⇒ n+1≤ m+1:
What happens here is similar to the behaviour of elim on natural
numbers: it appeals to the relevant induction principle, here le_ind,
which generates the two subgoals, which may then be solved easily
with the help of the defining clauses of le.
Now we know that it is a good idea to give the defining clauses as hints,
so that the proof may proceed with a simple combination of
induction and auto. Hint Constructors le
is just an abbreviation for Hint Resolve le_n le_S.
We have a slight problem however. We want to say “Do an induction on
hypothesis (le n m)”, but we have no explicit name for it. What we
do in this case is to say “Do an induction on the first unnamed hypothesis”,
as follows.
Here is a more tricky problem. Assume we want to show that
n≤ 0 ⇒ n=0. This reasoning ought to follow simply from the
fact that only the first defining clause of le applies.
However, here trying something like induction 1 would lead
nowhere (try it and see what happens).
An induction on n would not be convenient either.
What we must do here is analyse the definition of le in order
to match hypothesis (le n O) with the defining clauses, to find
that only le_n applies, whence the result.
This analysis may be performed by the “inversion” tactic
inversion_clear as follows:
When you start Coq without further requirements in the command line,
you get a bare system with few libraries loaded. As we saw, a standard
prelude module provides the standard logic connectives, and a few
arithmetic notions. If you want to load and open other modules from
the library, you have to use the Require command, as we saw for
classical logic above. For instance, if you want more arithmetic
constructions, you should request:
Such a command looks for a (compiled) module file Arith.vo in
the libraries registered by Coq. Libraries inherit the structure of
the file system of the operating system and are registered with the
command Add LoadPath. Physical directories are mapped to
logical directories. Especially the standard library of Coq is
pre-registered as a library of name Coq. Modules have absolute
unique names denoting their place in Coq libraries. An absolute
name is a sequence of single identifiers separated by dots. E.g. the
module Arith has full name Coq.Arith.Arith and because
it resides in eponym subdirectory Arith of the standard
library, it can be as well required by the command
This may be useful to avoid ambiguities if somewhere, in another branch
of the libraries known by Coq, another module is also called
Arith. Notice that by default, when a library is registered,
all its contents, and all the contents of its subdirectories recursively are
visible and accessible by a short (relative) name as Arith.
Notice also that modules or definitions not explicitly registered in
a library are put in a default library called Top.
The loading of a compiled file is quick, because the corresponding development is not type-checked again.
You may create your own module files, by writing Coq commands in a file,
say my_module.v. Such a module may be simply loaded in the current
context, with command Load my_module. It may also be compiled,
in “batch” mode, using the UNIX command
coqc. Compiling the module my_module.v creates a
file my_module.vo that can be reloaded with command
Require Import my_module.
If a required module depends on other modules then the latters are
automatically required beforehand. However their contents is not
automatically visible. If you want a module M required in a
module N to be automatically visible when N is required,
you should use Require Export M in your module N.
It is often difficult to remember the names of all lemmas and
definitions available in the current context, especially if large
libraries have been loaded. A convenient Search command
is available to lookup all known facts
concerning a given predicate. For instance, if you want to know all the
known lemmas about both the successor and the less or equal relation, just ask:
Another command SearchHead displays only lemmas where the searched
predicate appears at the head position in the conclusion.
The Search commands also allows finding the theorems
containing a given pattern, where _ can be used in
place of an arbitrary term. As shown in this example, Coq
provides usual infix notations for arithmetic operators.
This tutorial is necessarily incomplete. If you wish to pursue serious proving in Coq, you should now get your hands on Coq’s Reference Manual, which contains a complete description of all the tactics we saw, plus many more. You also should look in the library of developed theories which is distributed with Coq, in order to acquaint yourself with various proof techniques.
This document was translated from LATEX by HEVEA.