Chapter 1 The Gallina specification language
This chapter describes Gallina, the specification language of Coq. It allows developing mathematical theories and proofs of specifications of programs. The theories are built from axioms, hypotheses, parameters, lemmas, theorems and definitions of constants, functions, predicates and sets. The syntax of logical objects involved in theories is described in Section 1.2. The language of commands, called The Vernacular is described in section 1.3.
In Coq, logical objects are typed to ensure their logical correctness. The rules implemented by the typing algorithm are described in Chapter 4.
About the grammars in the manual
Grammars are presented in BackusNaur form (BNF). Terminal symbols are set in typewriter font. In addition, there are special notations for regular expressions.
An expression enclosed in square brackets […] means at most one occurrence of this expression (this corresponds to an optional component).
The notation “entry sep … sep entry” stands for a non empty sequence of expressions parsed by entry and separated by the literal “sep”^{1}.
Similarly, the notation “entry … entry” stands for a non empty sequence of expressions parsed by the “entry” entry, without any separator between.
Finally, the notation “[entry sep … sep entry]” stands for a possibly empty sequence of expressions parsed by the “entry” entry, separated by the literal “sep”.
1.1 Lexical conventions
Blanks
Space, newline and horizontal tabulation are considered as blanks. Blanks are ignored but they separate tokens.
Comments
Comments in Coq are enclosed between (* and *), and can be nested. They can contain any character. However, string literals must be correctly closed. Comments are treated as blanks.
Identifiers and access identifiers
Identifiers, written ident, are sequences of letters, digits,
_
and '
, that do not start with a digit or '
.
That is, they are recognized by the following lexical class:
first_letter  ::=  a..z ∣ A..Z ∣ _ ∣ unicodeletter 
subsequent_letter  ::=  a..z ∣ A..Z ∣ 0..9 ∣ _ ∣ ’ ∣ unicodeletter ∣ unicodeidpart 
ident  ::=  first_letter [subsequent_letter…subsequent_letter] 
All characters are meaningful. In particular, identifiers are casesensitive. The entry unicodeletter nonexhaustively includes Latin, Greek, Gothic, Cyrillic, Arabic, Hebrew, Georgian, Hangul, Hiragana and Katakana characters, CJK ideographs, mathematical letterlike symbols, hyphens, nonbreaking space, … The entry unicodeidpart nonexhaustively includes symbols for prime letters and subscripts.
Access identifiers, written access_ident, are identifiers prefixed
by .
(dot) without blank. They are used in the syntax of qualified
identifiers.
Natural numbers and integers
Numerals are sequences of digits. Integers are numerals optionally preceded by a minus sign.
digit  ::=  0..9 
num  ::=  digit…digit 
integer  ::=  []num 
Strings
Strings are delimited by "
(double quote), and enclose a
sequence of any characters different from "
or the sequence
""
to denote the double quote character. In grammars, the
entry for quoted strings is string.
Keywords
The following identifiers are reserved keywords, and cannot be employed otherwise:
_  as  at  cofix  else  end 
exists  exists2  fix  for  forall  fun 
if  IF  in  let  match  mod 
Prop  return  Set  then  Type  using 
where  with 
Special tokens
The following sequences of characters are special tokens:
!  %  &  &&  (  ()  ) 
*  +  ++  ,    >  . 
.(  ..  /  /\  :  ::  :< 
:=  :>  ;  <  <  <>  <: 
<=  <>  =  =>  =_D  >  >> 
>=  ?  ?=  @  [  \/  ] 
^  {        }  ~ 
Lexical ambiguities are resolved according to the “longest match” rule: when a sequence of non alphanumerical characters can be decomposed into several different ways, then the first token is the longest possible one (among all tokens defined at this moment), and so on.
1.2 Terms
1.2.1 Syntax of terms
Figures 1.1 and 1.2 describe the basic syntax of the terms of the Calculus of Inductive Constructions (also called Cic). The formal presentation of Cic is given in Chapter 4. Extensions of this syntax are given in chapter 2. How to customize the syntax is described in Chapter 12.
term ::= forall binders , term (1.2.8)  fun binders => term (1.2.7)  fix fix_bodies (1.2.14)  cofix cofix_bodies (1.2.14)  let ident [binders] [: term] := term in term (1.2.12)  let fix fix_body in term (1.2.14)  let cofix cofix_body in term (1.2.14)  let ( [name , … , name] ) [dep_ret_type] := term in term (1.2.13, 2.2.1)  let ’ pattern [in term] := term [return_type] in term (1.2.13, 2.2.1)  if term [dep_ret_type] then term else term (1.2.13, 2.2.1)  term : term (1.2.10)  term <: term (1.2.10)  term :> (24.1.1)  term > term (1.2.8)  term arg … arg (1.2.9)  @ qualid [term … term] (2.7.11)  term % ident (12.2.2)  match match_item , … , match_item [return_type] with [[] equation  …  equation] end (1.2.13)  qualid (1.2.3)  sort (1.2.5)  num (1.2.4)  _ (1.2.11)  ( term ) arg ::= term  ( ident := term ) (2.7.11) binders ::= binder … binder binder ::= name (1.2.6)  ( name … name : term )  ( name [: term] := term )  ’ pattern name ::= ident  _ qualid ::= ident  qualid access_ident sort ::= Prop  Set  Type
fix_bodies ::= fix_body  fix_body with fix_body with … with fix_body for ident cofix_bodies ::= cofix_body  cofix_body with cofix_body with … with cofix_body for ident fix_body ::= ident binders [annotation] [: term] := term cofix_body ::= ident [binders] [: term] := term annotation ::= { struct ident } match_item ::= term [as name] [in qualid[pattern … pattern]] dep_ret_type ::= [as name] return_type return_type ::= return term equation ::= mult_pattern  …  mult_pattern => term mult_pattern ::= pattern , … , pattern pattern ::= qualid pattern … pattern  @ qualid pattern … pattern  pattern as ident  pattern % ident  qualid  _  num  ( or_pattern , … , or_pattern ) or_pattern ::= pattern  …  pattern
1.2.2 Types
Coq terms are typed. Coq types are recognized by the same syntactic class as term. We denote by type the semantic subclass of types inside the syntactic class term.
1.2.3 Qualified identifiers and simple identifiers
Qualified identifiers (qualid) denote global constants (definitions, lemmas, theorems, remarks or facts), global variables (parameters or axioms), inductive types or constructors of inductive types. Simple identifiers (or shortly ident) are a syntactic subset of qualified identifiers. Identifiers may also denote local variables, what qualified identifiers do not.
1.2.4 Numerals
Numerals have no definite semantics in the calculus. They are mere notations that can be bound to objects through the notation mechanism (see Chapter 12 for details). Initially, numerals are bound to Peano’s representation of natural numbers (see 3.1.3).
Note: negative integers are not at the same level as num, for this would make precedence unnatural.
1.2.5 Sorts
There are three sorts Set, Prop and Type.
 Prop is the universe of logical propositions. The logical propositions themselves are typing the proofs. We denote propositions by form. This constitutes a semantic subclass of the syntactic class term.
 Set is is the universe of program types or specifications. The specifications themselves are typing the programs. We denote specifications by specif. This constitutes a semantic subclass of the syntactic class term.
 Type is the type of Set and Prop
More on sorts can be found in Section 4.1.1.
1.2.6 Binders
Various constructions such as fun, forall, fix and cofix bind variables. A binding is represented by an identifier. If the binding variable is not used in the expression, the identifier can be replaced by the symbol _. When the type of a bound variable cannot be synthesized by the system, it can be specified with the notation ( ident : type ). There is also a notation for a sequence of binding variables sharing the same type: ( ident_{1}…ident_{n} : type ). A binder can also be any pattern prefixed by a quote, e.g. ’(x,y).
Some constructions allow the binding of a variable to value. This is called a “letbinder”. The entry binder of the grammar accepts either an assumption binder as defined above or a letbinder. The notation in the latter case is ( ident := term ). In a letbinder, only one variable can be introduced at the same time. It is also possible to give the type of the variable as follows: ( ident : term := term ).
Lists of binder are allowed. In the case of fun and forall, it is intended that at least one binder of the list is an assumption otherwise fun and forall gets identical. Moreover, parentheses can be omitted in the case of a single sequence of bindings sharing the same type (e.g.: fun (x y z : A) => t can be shortened in fun x y z : A => t).
1.2.7 Abstractions
The expression “fun ident : type => term” defines the abstraction of the variable ident, of type type, over the term term. It denotes a function of the variable ident that evaluates to the expression term (e.g. fun x:A => x denotes the identity function on type A). The keyword fun can be followed by several binders as given in Section 1.2.6. Functions over several variables are equivalent to an iteration of onevariable functions. For instance the expression “fun ident_{1} … ident_{n} : type => term” denotes the same function as “fun ident_{1} : type => … fun ident_{n} : type => term”. If a letbinder occurs in the list of binders, it is expanded to a letin definition (see Section 1.2.12).
1.2.8 Products
The expression “forall ident : type, term” denotes the product of the variable ident of type type, over the term term. As for abstractions, forall is followed by a binder list, and products over several variables are equivalent to an iteration of onevariable products. Note that term is intended to be a type.
If the variable ident occurs in term, the product is called dependent product. The intention behind a dependent product forall x : A, B is twofold. It denotes either the universal quantification of the variable x of type A in the proposition B or the functional dependent product from A to B (a construction usually written Π_{x:A}.B in set theory).
Non dependent product types have a special notation: “A > B” stands for “forall _:A, B”. The non dependent product is used both to denote the propositional implication and function types.
1.2.9 Applications
The expression term_{0} term_{1} denotes the application of term_{0} to term_{1}.
The expression term_{0} term_{1} ... term_{n} denotes the application of the term term_{0} to the arguments term_{1} ... then term_{n}. It is equivalent to ( … ( term_{0} term_{1} ) … ) term_{n} : associativity is to the left.
The notation ( ident := term ) for arguments is used for making explicit the value of implicit arguments (see Section 2.7.11).
1.2.10 Type cast
The expression “term : type” is a type cast expression. It enforces the type of term to be type.
“term <: type” locally sets up the virtual machine for checking that term has type type.
1.2.11 Inferable subterms
Expressions often contain redundant pieces of information. Subterms that can be automatically inferred by Coq can be replaced by the symbol “_” and Coq will guess the missing piece of information.
1.2.12 Letin definitions
let ident := term_{1} in term_{2} denotes the local binding of term_{1} to the variable ident in term_{2}. There is a syntactic sugar for letin definition of functions: let ident binder_{1} … binder_{n} := term_{1} in term_{2} stands for let ident := fun binder_{1} … binder_{n} => term_{1} in term_{2}.
1.2.13 Definition by case analysis
Objects of inductive types can be destructurated by a caseanalysis construction called patternmatching expression. A patternmatching expression is used to analyze the structure of an inductive objects and to apply specific treatments accordingly.
This paragraph describes the basic form of patternmatching. See Section 2.2.1 and Chapter 17 for the description of the general form. The basic form of patternmatching is characterized by a single match_item expression, a mult_pattern restricted to a single pattern and pattern restricted to the form qualid ident … ident.
The expression match term_{0} return_type with pattern_{1} => term_{1}  …  pattern_{n} => term_{n} end, denotes a patternmatching over the term term_{0} (expected to be of an inductive type I). The terms term_{1}…term_{n} are the branches of the patternmatching expression. Each of pattern_{i} has a form qualid ident … ident where qualid must denote a constructor. There should be exactly one branch for every constructor of I.
The return_type expresses the type returned by the whole match expression. There are several cases. In the non dependent case, all branches have the same type, and the return_type is the common type of branches. In this case, return_type can usually be omitted as it can be inferred from the type of the branches^{2}.
In the dependent case, there are three subcases. In the first subcase, the type in each branch may depend on the exact value being matched in the branch. In this case, the whole patternmatching itself depends on the term being matched. This dependency of the term being matched in the return type is expressed with an “as ident” clause where ident is dependent in the return type. For instance, in the following example:
Coq < Inductive eq (A:Type) (x:A) : A > Prop := eq_refl : eq A x x.
Coq < Inductive or (A:Prop) (B:Prop) : Prop :=
 or_introl : A > or A B
 or_intror : B > or A B.
Coq < Definition bool_case (b:bool) : or (eq bool b true) (eq bool b false)
:= match b as x return or (eq bool x true) (eq bool x false) with
 true => or_introl (eq bool true true) (eq bool true false)
(eq_refl bool true)
 false => or_intror (eq bool false true) (eq bool false false)
(eq_refl bool false)
end.
the branches have respective types or (eq bool true true) (eq bool true false) and or (eq bool false true) (eq bool false false) while the whole patternmatching expression has type or (eq bool b true) (eq bool b false), the identifier x being used to represent the dependency. Remark that when the term being matched is a variable, the as clause can be omitted and the term being matched can serve itself as binding name in the return type. For instance, the following alternative definition is accepted and has the same meaning as the previous one.
:= match b return or (eq bool b true) (eq bool b false) with
 true => or_introl (eq bool true true) (eq bool true false)
(eq_refl bool true)
 false => or_intror (eq bool false true) (eq bool false false)
(eq_refl bool false)
end.
The second subcase is only relevant for annotated inductive types such as the equality predicate (see Section 3.1.2), the order predicate on natural numbers or the type of lists of a given length (see Section 17.3). In this configuration, the type of each branch can depend on the type dependencies specific to the branch and the whole patternmatching expression has a type determined by the specific dependencies in the type of the term being matched. This dependency of the return type in the annotations of the inductive type is expressed using a “in I _ … _ pattern_{1} … pattern_{n}” clause, where
 I is the inductive type of the term being matched;
 the _’s are matching the parameters of the inductive type: the return type is not dependent on them.
 the pattern_{i}’s are matching the annotations of the inductive type: the return type is dependent on them
 in the basic case which we describe below, each pattern_{i} is a name ident_{i}; see 17.3.2 for the general case
For instance, in the following example:
match H in eq _ _ z return eq A z x with
 eq_refl _ _ => eq_refl A x
end.
the type of the branch has type eq A x x because the third argument of eq is x in the type of the pattern refl_equal. On the contrary, the type of the whole patternmatching expression has type eq A y x because the third argument of eq is y in the type of H. This dependency of the case analysis in the third argument of eq is expressed by the identifier z in the return type.
Finally, the third subcase is a combination of the first and second subcase. In particular, it only applies to patternmatching on terms in a type with annotations. For this third subcase, both the clauses as and in are available.
There are specific notations for case analysis on types with one or two constructors: “if … then … else …” and “let (… , … , …) := … in …” (see Sections 2.2.2 and 2.2.3).
1.2.14 Recursive functions
The expression “fix ident_{1} binder_{1} : type_{1} := term_{1} with … with ident_{n} binder_{n} : type_{n} := term_{n} for ident_{i}” denotes the i^{th}component of a block of functions defined by mutual wellfounded recursion. It is the local counterpart of the Fixpoint command. See Section 1.3.4 for more details. When n=1, the “for ident_{i}” clause is omitted.
The expression “cofix ident_{1} binder_{1} : type_{1} with … with ident_{n} binder_{n} : type_{n} for ident_{i}” denotes the i^{th}component of a block of terms defined by a mutual guarded corecursion. It is the local counterpart of the CoFixpoint command. See Section 1.3.4 for more details. When n=1, the “for ident_{i}” clause is omitted.
The association of a single fixpoint and a local definition have a special syntax: “let fix f … := … in …” stands for “let f := fix f … := … in …”. The same applies for cofixpoints.
1.3 The Vernacular
sentence ::= assumption  definition  inductive  fixpoint  assertion proof assumption ::= assumption_keyword assums . assumption_keyword ::= Axiom  Conjecture  Parameter  Parameters  Variable  Variables  Hypothesis  Hypotheses assums ::= ident … ident : term  ( ident … ident : term ) … ( ident … ident : term ) definition ::= [Local] Definition ident [binders] [: term] := term .  Let ident [binders] [: term] := term . inductive ::= Inductive ind_body with … with ind_body .  CoInductive ind_body with … with ind_body . ind_body ::= ident [binders] [: term] := [[] ident [binders] [: term]  …  ident [binders] [: term]] fixpoint ::= Fixpoint fix_body with … with fix_body .  CoFixpoint cofix_body with … with cofix_body . assertion ::= assertion_keyword ident [binders] : term . assertion_keyword ::= Theorem  Lemma  Remark  Fact  Corollary  Proposition  Definition  Example proof ::= Proof . … Qed .  Proof . … Defined .  Proof . … Admitted .
Figure 1.3 describes The Vernacular which is the language of commands of Gallina. A sentence of the vernacular language, like in many natural languages, begins with a capital letter and ends with a dot.
The different kinds of command are described hereafter. They all suppose that the terms occurring in the sentences are welltyped.
1.3.1 Assumptions
Assumptions extend the environment with axioms, parameters, hypotheses or variables. An assumption binds an ident to a type. It is accepted by Coq if and only if this type is a correct type in the environment preexisting the declaration and if ident was not previously defined in the same module. This type is considered to be the type (or specification, or statement) assumed by ident and we say that ident has type type.
Axiom ident :term .
This command links term to the name ident as its specification in the global context. The fact asserted by term is thus assumed as a postulate.
Error messages:
Variants:

Parameter ident :term.
Is equivalent to Axiom ident : term  Parameter ident_{1} … ident_{n} :term.
Adds n parameters with specification term  Parameter ( ident_{1,1} … ident_{1,k1} : term_{1} ) … ( ident_{n,1}…ident_{n,kn} : term_{n} ).
Adds n blocks of parameters with different specifications.  Local Axiom ident : term.
Such axioms are never made accessible through their unqualified name by Import and its variants (see 2.5.8). You have to explicitly give their fully qualified name to refer to them. 
Conjecture ident :term.
Is equivalent to Axiom ident : term.
Remark: It is possible to replace Parameter by Parameters.
Variable ident :term.
This command links term to the name ident in the context of the current section (see Section 2.4 for a description of the section mechanism). When the current section is closed, name ident will be unknown and every object using this variable will be explicitly parametrized (the variable is discharged). Using the Variable command out of any section is equivalent to using Local Parameter.
Error messages:
Variants:

Variable ident_{1} … ident_{n} :term.
Links term to names ident_{1} … ident_{n}.  Variable ( ident_{1,1} … ident_{1,k1} : term_{1} ) … ( ident_{n,1} …ident_{n,kn} : term_{n} ).
Adds n blocks of variables with different specifications. 
Hypothesis ident :term.
Hypothesis is a synonymous of Variable
Remark: It is possible to replace Variable by Variables and Hypothesis by Hypotheses.
It is advised to use the keywords Axiom
and Hypothesis
for logical postulates (i.e. when the assertion term is of sort
Prop
), and to use the keywords Parameter
and
Variable
in other cases (corresponding to the declaration of an
abstract mathematical entity).
1.3.2 Definitions
Definitions extend the environment with associations of names to terms. A definition can be seen as a way to give a meaning to a name or as a way to abbreviate a term. In any case, the name can later be replaced at any time by its definition.
The operation of unfolding a name into its definition is called δconversion (see Section 4.3). A definition is accepted by the system if and only if the defined term is welltyped in the current context of the definition and if the name is not already used. The name defined by the definition is called a constant and the term it refers to is its body. A definition has a type which is the type of its body.
A formal presentation of constants and environments is given in Section 4.2.
Definition ident := term.
This command binds term to the name ident in the environment, provided that term is welltyped.
Error messages:
Variants:

Definition ident : term_{1} := term_{2}.
It checks that the type of term_{2} is definitionally equal to term_{1}, and registers ident as being of type term_{1}, and bound to value term_{2}.  Definition ident binder_{1} … binder_{n}
: term_{1} := term_{2}.
This is equivalent to
Definition ident : forallbinder_{1} … binder_{n}, term_{1} := fun binder_{1} … binder_{n} => term_{2} .  Local Definition ident := term.
Such definitions are never made accessible through their unqualified name by Import and its variants (see 2.5.8). You have to explicitly give their fully qualified name to refer to them.  Example ident := term.
Example ident : term_{1} := term_{2}.
Example ident binder_{1} … binder_{n} : term_{1} := term_{2}.
These are synonyms of the Definition forms.
Error messages:
See also: Sections 6.10.1, 6.10.2, 8.7.5.
Let ident := term.
This command binds the value term to the name ident in the environment of the current section. The name ident disappears when the current section is eventually closed, and, all persistent objects (such as theorems) defined within the section and depending on ident are prefixed by the letin definition let ident := term in. Using the Let command out of any section is equivalent to using Local Definition.
Error messages:
Variants:
 Let ident : term_{1} := term_{2}.
 Let Fixpoint ident fix_body with … with fix_body ..
 Let CoFixpoint ident cofix_body with … with cofix_body ..
See also: Sections 2.4 (section mechanism), 6.10.1,
6.10.2 (opaque/transparent constants), 8.7.5 (tactic
unfold).
1.3.3 Inductive definitions
We gradually explain simple inductive types, simple annotated inductive types, simple parametric inductive types, mutually inductive types. We explain also coinductive types.
Simple inductive types
The definition of a simple inductive type has the following form:
Inductive ident : sort :=  

The name ident is the name of the inductively defined type and sort is the universes where it lives. The names ident_{1}, …, ident_{n} are the names of its constructors and type_{1}, …, type_{n} their respective types. The types of the constructors have to satisfy a positivity condition (see Section 4.5.2) for ident. This condition ensures the soundness of the inductive definition. If this is the case, the names ident, ident_{1}, …, ident_{n} are added to the environment with their respective types. Accordingly to the universe where the inductive type lives (e.g. its type sort), Coq provides a number of destructors for ident. Destructors are named ident_ind, ident_rec or ident_rect which respectively correspond to elimination principles on Prop, Set and Type. The type of the destructors expresses structural induction/recursion principles over objects of ident. We give below two examples of the use of the Inductive definitions.
The set of natural numbers is defined as:
 O : nat
 S : nat > nat.
nat is defined
nat_rect is defined
nat_ind is defined
nat_rec is defined
The type nat is defined as the least Set
containing O and closed by the S constructor. The names nat,
O and S are added to the environment.
Now let us have a look at the elimination principles. They are three of them: nat_ind, nat_rec and nat_rect. The type of nat_ind is:
nat_ind
: forall P : nat > Prop,
P O > (forall n : nat, P n > P (S n)) > forall n : nat, P n
This is the well known structural induction principle over natural numbers, i.e. the secondorder form of Peano’s induction principle. It allows proving some universal property of natural numbers (forall n:nat, P n) by induction on n.
The types of nat_rec and nat_rect are similar, except
that they pertain to (P:nat>Set) and (P:nat>Type)
respectively . They correspond to primitive induction principles
(allowing dependent types) respectively over sorts Set
and
Type
. The constant ident_ind is always provided,
whereas ident_rec and ident_rect can be impossible
to derive (for example, when ident is a proposition).
Variants:

Coq < Inductive nat : Set := O  S (_:nat).In the case where inductive types have no annotations (next section gives an example of such annotations), a constructor can be defined by only giving the type of its arguments.
Simple annotated inductive types
In an annotated inductive types, the universe where the inductive type is defined is no longer a simple sort, but what is called an arity, which is a type whose conclusion is a sort.
As an example of annotated inductive types, let us define the even predicate:
 even_0 : even O
 even_SS : forall n:nat, even n > even (S (S n)).
even is defined
even_ind is defined
The type nat>Prop means that even is a unary predicate (inductively defined) over natural numbers. The type of its two constructors are the defining clauses of the predicate even. The type of even_ind is:
even_ind
: forall P : nat > Prop,
P O >
(forall n : nat, even n > P n > P (S (S n))) >
forall n : nat, even n > P n
From a mathematical point of view it asserts that the natural numbers satisfying the predicate even are exactly in the smallest set of naturals satisfying the clauses even_0 or even_SS. This is why, when we want to prove any predicate P over elements of even, it is enough to prove it for O and to prove that if any natural number n satisfies P its double successor (S (S n)) satisfies also P. This is indeed analogous to the structural induction principle we got for nat.
Error messages:
 Non strictly positive occurrence of ident in type
 The conclusion of type is not valid; it must be built from ident
Parametrized inductive types
In the previous example, each constructor introduces a different instance of the predicate even. In some cases, all the constructors introduces the same generic instance of the inductive definition, in which case, instead of an annotation, we use a context of parameters which are binders shared by all the constructors of the definition.
The general scheme is:
Parameters differ from inductive type annotations in the fact that the conclusion of each type of constructor term_{i} invoke the inductive type with the same values of parameters as its specification.
A typical example is the definition of polymorphic lists:
 nil : list A
 cons : A > list A > list A.
Note that in the type of nil and cons, we write (list A) and not just list.
The constructors nil and
cons will have respectively types:
nil
: forall A : Set, list A
Coq < Check cons.
cons
: forall A : Set, A > list A > list A
Types of destructors are also quantified with (A:Set).
Variants:

Coq < Inductive list (A:Set) : Set := nil  cons (_:A) (_:list A).This is an alternative definition of lists where we specify the arguments of the constructors rather than their full type.

Coq < Variant sum (A B:Set) : Set := left : A > sum A B  right : B > sum A B.The Variant keyword is identical to the Inductive keyword, except that it disallows recursive definition of types (in particular lists cannot be defined with the Variant keyword). No induction scheme is generated for this variant, unless the option Nonrecursive Elimination Schemes is set (see 13.1.1).
Error messages:
New from Coq V8.1
The condition on parameters for inductive definitions has been relaxed since Coq V8.1. It is now possible in the type of a constructor, to invoke recursively the inductive definition on an argument which is not the parameter itself.
One can define :
 nil2 : list2 A
 cons2 : A > list2 (A*A) > list2 A.
list2 is defined
list2_rect is defined
list2_ind is defined
list2_rec is defined
that can also be written by specifying only the type of the arguments:
But the following definition will give an error:
 nilw : listw (A*A)
 consw : A > listw (A*A) > listw (A*A).
The command has indeed failed with message:
Last occurrence of "listw" must have "A" as 1st argument in
"listw (A * A)%type".
Because the conclusion of the type of constructors should be listw A in both cases.
A parametrized inductive definition can be defined using annotations instead of parameters but it will sometimes give a different (bigger) sort for the inductive definition and will produce a less convenient rule for case elimination.
See also: Sections 4.5 and 8.5.2.
Mutually defined inductive types
The definition of a block of mutually inductive types has the form:
Inductive ident_{1} : type_{1} :=  
 
with  
…  
with ident_{m} : type_{m} :=  

It has the same semantics as the above Inductive definition for each ident_{1}, …, ident_{m}. All names ident_{1}, …, ident_{m} and ident_{1}^{1}, …, ident_{nm}^{m} are simultaneously added to the environment. Then welltyping of constructors can be checked. Each one of the ident_{1}, …, ident_{m} can be used on its own.
It is also possible to parametrize these inductive definitions. However, parameters correspond to a local context in which the whole set of inductive declarations is done. For this reason, the parameters must be strictly the same for each inductive types The extended syntax is:
Inductive ident_{1} params : type_{1} :=  
 
with  
…  
with ident_{m} params : type_{m} :=  

Example: The typical example of a mutual inductive data type is the one for
trees and forests. We assume given two types A and B as variables.
It can be declared the following way.
Coq < Inductive tree : Set :=
node : A > forest > tree
with forest : Set :=
 leaf : B > forest
 cons : tree > forest > forest.
This declaration generates automatically six induction principles. They are respectively called tree_rec, tree_ind, tree_rect, forest_rec, forest_ind, forest_rect. These ones are not the most general ones but are just the induction principles corresponding to each inductive part seen as a single inductive definition.
To illustrate this point on our example, we give the types of tree_rec and forest_rec.
tree_rec
: forall P : tree > Set,
(forall (a : A) (f : forest), P (node a f)) > forall t : tree, P t
Coq < Check forest_rec.
forest_rec
: forall P : forest > Set,
(forall b : B, P (leaf b)) >
(forall (t : tree) (f0 : forest), P f0 > P (cons t f0)) >
forall f1 : forest, P f1
Assume we want to parametrize our mutual inductive definitions with the two type variables A and B, the declaration should be done the following way:
node : A > forest A B > tree A B
with forest (A B:Set) : Set :=
 leaf : B > forest A B
 cons : tree A B > forest A B > forest A B.
Assume we define an inductive definition inside a section. When the section is closed, the variables declared in the section and occurring free in the declaration are added as parameters to the inductive definition.
See also: Section 2.4.
Coinductive types
The objects of an inductive type are wellfounded with respect to the constructors of the type. In other words, such objects contain only a finite number of constructors. Coinductive types arise from relaxing this condition, and admitting types whose objects contain an infinity of constructors. Infinite objects are introduced by a nonending (but effective) process of construction, defined in terms of the constructors of the type.
An example of a coinductive type is the type of infinite sequences of natural numbers, usually called streams. It can be introduced in Coq using the CoInductive command:
Seq : nat > Stream > Stream.
Stream is defined
The syntax of this command is the same as the command Inductive (see Section 1.3.3). Notice that no principle of induction is derived from the definition of a coinductive type, since such principles only make sense for inductive ones. For coinductive ones, the only elimination principle is case analysis. For example, the usual destructors on streams hd:Stream>nat and tl:Str>Str can be defined as follows:
hd is defined
Coq < Definition tl (x:Stream) := let (a,s) := x in s.
tl is defined
Definition of coinductive predicates and blocks of mutually coinductive definitions are also allowed. An example of a coinductive predicate is the extensional equality on streams:
eqst :
forall s1 s2:Stream,
hd s1 = hd s2 > EqSt (tl s1) (tl s2) > EqSt s1 s2.
EqSt is defined
In order to prove the extensionally equality of two streams s_{1} and s_{2} we have to construct an infinite proof of equality, that is, an infinite object of type (EqSt s_{1} s_{2}). We will see how to introduce infinite objects in Section 1.3.4.
1.3.4 Definition of recursive functions
Definition of functions by recursion over inductive objects
This section describes the primitive form of definition by recursion over inductive objects. See Section 2.3 for more advanced constructions. The command:
allows defining functions by patternmatching over inductive objects using a fixed point construction. The meaning of this declaration is to define ident a recursive function with arguments specified by the binders in params such that ident applied to arguments corresponding to these binders has type type_{0}, and is equivalent to the expression term_{0}. The type of the ident is consequently forall params , type_{0} and the value is equivalent to fun params => term_{0}.
To be accepted, a Fixpoint definition has to satisfy some syntactical constraints on a special argument called the decreasing argument. They are needed to ensure that the Fixpoint definition always terminates. The point of the {struct ident} annotation is to let the user tell the system which argument decreases along the recursive calls. For instance, one can define the addition function as :
match n with
 O => m
 S p => S (add p m)
end.
add is defined
add is recursively defined (decreasing on 1st argument)
The {struct ident} annotation may be left implicit, in this case the system try successively arguments from left to right until it finds one that satisfies the decreasing condition. Note that some fixpoints may have several arguments that fit as decreasing arguments, and this choice influences the reduction of the fixpoint. Hence an explicit annotation must be used if the leftmost decreasing argument is not the desired one. Writing explicit annotations can also speed up typechecking of large mutual fixpoints.
The match operator matches a value (here n
) with the
various constructors of its (inductive) type. The remaining arguments
give the respective values to be returned, as functions of the
parameters of the corresponding constructor. Thus here when n
equals O
we return m
, and when n
equals
(S p)
we return (S (add p m))
.
The match operator is formally described in detail in Section 4.5.3. The system recognizes that in the inductive call (add p m) the first argument actually decreases because it is a pattern variable coming from match n with.
Example: The following definition is not correct and generates an
error message:
match m with
 O => n
 S p => S (wrongplus n p)
end.
The command has indeed failed with message:
Recursive definition of wrongplus is illformed.
In environment
wrongplus : nat > nat > nat
n : nat
m : nat
p : nat
Recursive call to wrongplus has principal argument equal to
"n" instead of a subterm of "n".
Recursive definition is:
"fun n m : nat => match m with
 0 => n
 S p => S (wrongplus n p)
end".
because the declared decreasing argument n actually does not decrease in the recursive call. The function computing the addition over the second argument should rather be written:
match m with
 O => n
 S p => S (plus n p)
end.
The ordinary match operation on natural numbers can be mimicked in the following way.
(C:Set) (f0:C) (fS:nat > C > C) (n:nat) {struct n} : C :=
match n with
 O => f0
 S p => fS p (nat_match C f0 fS p)
end.
The recursive call may not only be on direct subterms of the recursive variable n but also on a deeper subterm and we can directly write the function mod2 which gives the remainder modulo 2 of a natural number.
match n with
 O => O
 S p => match p with
 O => S O
 S q => mod2 q
end
end.
In order to keep the strong normalization property, the fixed point reduction will only be performed when the argument in position of the decreasing argument (which type should be in an inductive definition) starts with a constructor.
The Fixpoint construction enjoys also the with extension to define functions over mutually defined inductive types or more generally any mutually recursive definitions.
Variants:

Fixpoint ident_{1} params_{1} : type_{1} := term_{1}
with …
with ident_{m} params_{m} : type_{m} := term_{m}
Allows to define simultaneously ident_{1}, …, ident_{m}.
Example: The size of trees and forests can be defined the following way:
match t with
 node a f => S (forest_size f)
end
with forest_size (f:forest) : nat :=
match f with
 leaf b => 1
 cons t f' => (tree_size t + forest_size f')
end.
A generic command Scheme is useful to build automatically various mutual induction principles. It is described in Section 13.1.
Definitions of recursive objects in coinductive types
The command:
introduces a method for constructing an infinite object of a coinductive type. For example, the stream containing all natural numbers can be introduced applying the following method to the number O (see Section 1.3.3 for the definition of Stream, hd and tl):
from is defined
from is corecursively defined
Oppositely to recursive ones, there is no decreasing argument in a corecursive definition. To be admissible, a method of construction must provide at least one extra constructor of the infinite object for each iteration. A syntactical guard condition is imposed on corecursive definitions in order to ensure this: each recursive call in the definition must be protected by at least one constructor, and only by constructors. That is the case in the former definition, where the single recursive call of from is guarded by an application of Seq. On the contrary, the following recursive function does not satisfy the guard condition:
if p (hd s) then Seq (hd s) (filter p (tl s)) else filter p (tl s).
The command has indeed failed with message:
Recursive definition of filter is illformed.
In environment
filter : (nat > bool) > Stream > Stream
p : nat > bool
s : Stream
Unguarded recursive call in "filter p (tl s)".
Recursive definition is:
"fun (p : nat > bool) (s : Stream) =>
if p (hd s) then Seq (hd s) (filter p (tl s)) else filter p (tl s)".
The elimination of corecursive definition is done lazily, i.e. the definition is expanded only when it occurs at the head of an application which is the argument of a case analysis expression. In any other context, it is considered as a canonical expression which is completely evaluated. We can test this using the command Eval, which computes the normal forms of a term:
= (cofix from (n : nat) : Stream := Seq n (from (S n))) 0
: Stream
Coq < Eval compute in (hd (from 0)).
= 0
: nat
Coq < Eval compute in (tl (from 0)).
= (cofix from (n : nat) : Stream := Seq n (from (S n))) 1
: Stream
Variants:

CoFixpoint ident_{1} params :type_{1} :=
term_{1}
As for most constructions, arguments of cofixpoints expressions can be introduced before the := sign.  CoFixpoint ident_{1} : type_{1} := term_{1}
with
…
with ident_{m} : type_{m} := term_{m}
As in the Fixpoint command (see Section 1.3.4), it is possible to introduce a block of mutually dependent methods.
1.3.5 Assertions and proofs
An assertion states a proposition (or a type) of which the proof (or an inhabitant of the type) is interactively built using tactics. The interactive proof mode is described in Chapter 7 and the tactics in Chapter 8. The basic assertion command is:
Theorem ident [binders] : type.
After the statement is asserted, Coq needs a proof. Once a proof of type under the assumptions represented by binders is given and validated, the proof is generalized into a proof of forall [binders], type and the theorem is bound to the name ident in the environment.
Error messages:
 The term form has type … which should be Set, Prop or Type
 ident already exists
The name you provided is already defined. You have then to choose another name.
Variants:

Lemma ident [binders] : type.
Remark ident [binders] : type.
Fact ident [binders] : type.
Corollary ident [binders] : type.
Proposition ident [binders] : type.These commands are synonyms of Theorem ident [binders] : type.
 Theorem ident [binders]: type with … with ident [binders]: type.
This command is useful for theorems that are proved by simultaneous induction over a mutually inductive assumption, or that assert mutually dependent statements in some mutual coinductive type. It is equivalent to Fixpoint or CoFixpoint (see Section 1.3.4) but using tactics to build the proof of the statements (or the body of the specification, depending on the point of view). The inductive or coinductive types on which the induction or coinduction has to be done is assumed to be non ambiguous and is guessed by the system.
Like in a Fixpoint or CoFixpoint definition, the induction hypotheses have to be used on structurally smaller arguments (for a Fixpoint) or be guarded by a constructor (for a CoFixpoint). The verification that recursive proof arguments are correct is done only at the time of registering the lemma in the environment. To know if the use of induction hypotheses is correct at some time of the interactive development of a proof, use the command Guarded (see Section 7.3.2).
The command can be used also with Lemma, Remark, etc. instead of Theorem.
 Definition ident [binders] : type.
This allows defining a term of type type using the proof editing mode. It behaves as Theorem but is intended to be used in conjunction with Defined (see 1) in order to define a constant of which the computational behavior is relevant.
The command can be used also with Example instead of Definition.
See also: Sections 6.10.1 and 6.10.2 (Opaque and Transparent) and 8.7.5 (tactic unfold).  Let ident [binders] : type.
Like Definition ident [binders] : type. except that the definition is turned into a letin definition generalized over the declarations depending on it after closing the current section.
 Fixpoint ident binders [annotation] [: term] [:= term] with … with ident binders [annotation] [: term] [:= term].
This generalizes the syntax of Fixpoint so that one or more bodies can be defined interactively using the proof editing mode (when a body is omitted, its type is mandatory in the syntax). When the block of proofs is completed, it is intended to be ended by Defined.
 CoFixpoint ident [binders] [: term] [:= term] with … with ident [binders] [: term] [:= term].
This generalizes the syntax of CoFixpoint so that one or more bodies can be defined interactively using the proof editing mode.
Proof. … Qed.
A proof starts by the keyword Proof. Then Coq enters the
proof editing mode until the proof is completed. The proof editing
mode essentially contains tactics that are described in chapter
8. Besides tactics, there are commands to manage the proof
editing mode. They are described in Chapter 7. When
the proof is completed it should be validated and put in the
environment using the keyword Qed.
Error message:
Remarks:
 Several statements can be simultaneously asserted.
 Not only other assertions but any vernacular command can be given while in the process of proving a given assertion. In this case, the command is understood as if it would have been given before the statements still to be proved.
 Proof is recommended but can currently be omitted. On the opposite side, Qed (or Defined, see below) is mandatory to validate a proof.
 Proofs ended by Qed are declared opaque. Their content cannot be unfolded (see 8.7), thus realizing some form of proofirrelevance. To be able to unfold a proof, the proof should be ended by Defined (see below).
Variants:

Proof. … Defined.
Same as Proof. … Qed. but the proof is then declared transparent, which means that its content can be explicitly used for typechecking and that it can be unfolded in conversion tactics (see 8.7, 6.10.1, 6.10.2). 
Proof. … Admitted.
Turns the current asserted statement into an axiom and exits the proof mode.