1

This research was partly supported by IST working group “Types”

Getting started

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 new book by Y. Bertot and P. Castéran on practical uses of the Coq system.

Coq can be used from a standard teletype-like shell window but preferably through the graphical user interface CoqIde¹.

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 http://coq.inria.fr.

In the following, we assume that Coq  is called from a standard teletype-like shell window. All examples preceded by the prompting sequence Coq < represent user input, terminated by a period.

The following lines usually show Coq’s answer as it appears on the users screen. 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.

The sequence of such examples is a valid Coq  session, unless otherwise specified. This version of the tutorial has been prepared on a PC workstation running Linux. The standard invocation of Coq delivers a message such as:

unix:~> coqtop
Welcome to Coq 8.2 (January 2009)

Coq < 

The first line gives a banner stating the precise version of Coq  used. You should always return this banner when you report an anomaly to our bug-tracking system http://logical.futurs.inria.fr/coq-bugs

1

Alternative graphical interfaces exist: Proof General and Pcoq.

Chapter 1  Basic Predicate Calculus

1.1  An overview of the specification language Gallina

A formal development in Gallina consists in a sequence of declarations and definitions. You may also send Coq  commands which are not really part of the formal development, but correspond to information requests, or service routine invocations. For instance, the command:

Coq < Quit.

terminates the current session.

1.1.1  Declarations

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 one more times 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.

1.1.2  Definitions

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:

We may revert to the clean state of our initial session using the Coq  Reset command:

1.2  Introduction to the proof engine: Minimal Logic

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”. Remark 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. Remark 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 may either discard it, by using the command Abort which returns to the standard Coq  toplevel loop without further ado, or else save it as a lemma in the current context, under name say trivial_lemma:

As a comment, the system shows the proof script listing all tactic commands used in 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:

• T₁ ; T₂ (read T₁ then T₂) applies tactic T₁ to the current goal, and then tactic T₂ to all the subgoals generated by T₁.
• T; [T₁ | T₂ | ... | T_n] applies tactic T to the current goal, and then tactic T₁ to the first newly generated subgoal, ..., T_n to the nth.

We may thus complete the proof of distr_impl with one composite tactic:

Let us now save lemma distr_impl:

Here Save needs no argument, since we gave the name distr_impl in advance; it is however possible to override the given name by giving a different argument to command Save.

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:

This time, we do not save the proof, we just discard it with the Abort command:

At any point during a proof, we may use Abort to exit the proof mode and go back to Coq’s main loop. We may also use Restart to restart from scratch the proof of the same lemma. We may also use Undo to backtrack one step, and more generally Undo n to backtrack n steps.

We end this section by showing a useful command, Inspect n., which inspects the global Coq  environment, showing the last n declared notions:

The declarations, whether global parameters or axioms, are shown preceded by ***; definitions and lemmas are stated with their specification, but their value (or proof-term) is omitted.

1.3  Propositional Calculus

1.3.1  Conjunction

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.

1.3.2  Disjunction

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 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.

1.3.3  Tauto

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 a few 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:

1.3.4  Classical reasoning

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:

1. Every non-scottish member wears red socks
2. Every member wears a kilt or doesn’t wear red socks
3. The married members don’t go out on Sunday
4. A member goes out on Sunday if and only if he is Scottish
5. Every member who wears a kilt is Scottish and married
6. Every scottish member wears a kilt

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.

1.4  Predicate Calculus

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.

1.4.1  Sections and signatures

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 me 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 respectively 1 and 2. Such abstract entities may be entered in the context as global variables. But we must be careful about the pollution of our global environment by such declarations. For instance, we have already polluted our Coq  session by declaring the variables n, Pos_n, A, B, and C.

We shall now declare a new Section, which will allow us to define notions local to a well-delimited scope. 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.

Remark the syntax forall x:D, which stands for universal quantification ∀ x : D.

1.4.2  Existential quantification

We now state our lemma, and enter proof mode.

Remark that the hypotheses which are local to the currently opened sections are listed as local hypotheses to the current goals. The rationale is that 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.

Remark 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, the use of section R_sym_trans has not been really significant, 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.

1.4.3  Paradoxes of classical predicate calculus

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:

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; a simple one is to use the absurd tactic as follows:

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:

Remark 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 that the name d has vanished as well 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.

1.4.4  Flexible use of local assumptions

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 use a lemma, although we do not have a direct way to appeal to such an already proven fact. The tactic cut permits to use the lemma at this point, keeping the corresponding proof obligation as a new subgoal:

We clean the goal by doing an Abort command.

1.4.5  Equality

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: