The Gallina specification language¶
This chapter describes Gallina, the specification language of Coq. It allows developing mathematical theories and to prove 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 Terms. The language of commands, called The Vernacular is described in Section The Vernacular.
In Coq, logical objects are typed to ensure their logical correctness. The rules implemented by the typing algorithm are described in Chapter Calculus of Inductive Constructions.
About the grammars in the manual¶
Grammars are presented in Backus-Naur form (BNF). Terminal symbols are
set in black 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.
At the end, the notation “[entry sep … sep entry]
” stands for a
possibly empty sequence of expressions parsed by the “entry
” entry,
separated by the literal “sep
”.
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 ∣ _ ∣ unicode-letter subsequent_letter ::= a..z ∣ A..Z ∣ 0..9 ∣ _ ∣ ' ∣ unicode-letter ∣ unicode-id-part ident ::=
first_letter
[subsequent_letter
…subsequent_letter
] access_ident ::= .ident
All characters are meaningful. In particular, identifiers are case- sensitive. The entry
unicode-letter
non-exhaustively includes Latin, Greek, Gothic, Cyrillic, Arabic, Hebrew, Georgian, Hangul, Hiragana and Katakana characters, CJK ideographs, mathematical letter-like symbols, hyphens, non-breaking space, … The entryunicode-id-part
non- exhaustively 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 isstring
. - 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.
Terms¶
Syntax of terms¶
The following grammars 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 Calculus of Inductive Constructions. Extensions of this syntax are given in Chapter Extensions of Gallina. How to customize the syntax is described in Chapter Syntax extensions and interpretation scopes.
term ::= forallbinders
,term
| funbinders
=>term
| fixfix_bodies
| cofixcofix_bodies
| letident
[binders
] [:term
] :=term
interm
| let fixfix_body
interm
| let cofixcofix_body
interm
| let ( [name
, … ,name
] ) [dep_ret_type
] :=term
interm
| let 'pattern
[interm
] :=term
[return_type
] interm
| ifterm
[dep_ret_type
] thenterm
elseterm
|term
:term
|term
<:term
|term
:> |term
->term
|term
arg … arg | @qualid
[term
…term
] |term
%ident
| matchmatch_item
, … ,match_item
[return_type
] with [[|]equation
| … |equation
] end |qualid
|sort
| num | _ | (term
) arg ::=term
| (ident
:=term
) binders ::=binder
…binder
binder ::=name
| (name
…name
:term
) | (name
[:term
] :=term
) name ::=ident
| _ qualid ::=ident
|qualid
access_ident
sort ::= Prop | Set | Type fix_bodies ::=fix_body
|fix_body
withfix_body
with … withfix_body
forident
cofix_bodies ::=cofix_body
|cofix_body
withcofix_body
with … withcofix_body
forident
fix_body ::=ident
binders
[annotation] [:term
] :=term
cofix_body ::=ident
[binders
] [:term
] :=term
annotation ::= { structident
} match_item ::=term
[asname
] [inqualid
[pattern
…pattern
]] dep_ret_type ::= [asname
]return_type
return_type ::= returnterm
equation ::=mult_pattern
| … |mult_pattern
=>term
mult_pattern ::=pattern
, … ,pattern
pattern ::=qualid
pattern
…pattern
| @qualid
pattern
…pattern
|pattern
asident
|pattern
%ident
|qualid
| _ | num | (or_pattern
, … ,or_pattern
) or_pattern ::=pattern
| … |pattern
Types¶
Coq terms are typed. Coq types are recognized by the same syntactic
class as :token`term`. We denote by type
the semantic subclass
of types inside the syntactic class term
.
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.
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 Syntax extensions and interpretation scopes for details). Initially, numerals are bound to Peano’s representation of natural numbers (see Datatypes).
Note
negative integers are not at the same level as num
, for this
would make precedence unnatural.
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 classterm
.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 classterm
.Type
is the type ofProp
andSet
More on sorts can be found in Section Sorts.
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 “let-binder”. The entry binder
of the grammar accepts
either an assumption binder as defined above or a let-binder. The notation in
the latter case is (ident:=term)
. In a let-binder, 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
).
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 Binders. Functions over
several variables are equivalent to an iteration of one-variable
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 let-binder occurs in
the list of binders, it is expanded to a let-in definition (see
Section Let-in definitions).
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 one-variable
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
\(\Pi_{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.
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 Explicit applications).
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
.
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.
Let-in 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 let-in
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\).
Definition by case analysis¶
Objects of inductive types can be destructurated by a case-analysis construction called pattern-matching expression. A pattern-matching expression is used to analyze the structure of an inductive objects and to apply specific treatments accordingly.
This paragraph describes the basic form of pattern-matching. See
Section Multiple and nested pattern-matching and Chapter Extended pattern-matching for the description
of the general form. The basic form of pattern-matching is characterized
by a single match_item
expression, a mult_pattern
restricted to a
single pattern
and pattern
restricted to the form
qualid
ident
.
The expression match term
\(_0\) return_type
with
pattern
\(_1\) => term
\(_1\) \(|\) … \(|\)
pattern
\(_n\) => term
\(_n\) end, denotes a
pattern-matching
over the term term
\(_0\) (expected to be
of an inductive type \(I\)). The terms term
\(_1\)…term
\(_n\) are the branches
of the pattern-matching
expression. Each of pattern
\(_i\) has a form qualid
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 pattern-matching 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:
- Inductive bool : Type := true : bool | false : bool.
- bool is defined bool_rect is defined bool_ind is defined bool_rec is defined
- Inductive eq (A:Type) (x:A) : A -> Prop := eq_refl : eq A x x.
- eq is defined eq_rect is defined eq_ind is defined eq_rec is defined
- Inductive or (A:Prop) (B:Prop) : Prop := | or_introl : A -> or A B | or_intror : B -> or A B.
- or is defined or_ind is defined
- 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.
- bool_case is defined
the branches have respective types or eq bool true true :g:`eq bool true
false
and or eq bool false true
eq bool false false
while the whole
pattern-matching 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.
- Definition bool_case (b:bool) : or (eq bool b true) (eq bool b false) := 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.
- Toplevel input, characters 0-315: > Definition bool_case (b:bool) : or (eq bool b true) (eq bool b false) := 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: bool_case already exists.
The second subcase is only relevant for annotated inductive types such
as the equality predicate (see Section Equality),
the order predicate on natural numbers or the type of lists of a given
length (see Section Matching objects of dependent types). In this configuration, the
type of each branch can depend on the type dependencies specific to the
branch and the whole pattern-matching 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
_
are matching the parameters of the inductive type: the return type is not dependent on them. - the
pattern
\(_i\) 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 nameident
\(_i\); see Patterns in in for the general case
For instance, in the following example:
- Definition eq_sym (A:Type) (x y:A) (H:eq A x y) : eq A y x := match H in eq _ _ z return eq A z x with | eq_refl _ => eq_refl A x end.
- Toplevel input, characters 105-114: > Definition eq_sym (A:Type) (x y:A) (H:eq A x y) : eq A y x := match H in eq _ _ z return eq A z x with | eq_refl _ => eq_refl A x end. > ^^^^^^^^^ Error: The constructor eq_refl (in type eq) expects 2 arguments.
the type of the branch has type eq A x x
because the third argument of
g:eq is g:x in the type of the pattern refl_equal
. On the contrary, the
type of the whole pattern-matching 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 g:z in the
return type.
Finally, the third subcase is a combination of the first and second subcase. In particular, it only applies to pattern-matching 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 (…, ” (see Sections Pattern-matching on boolean values: the if expression and Let-in definitions).
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\)component of a block of functions defined by mutual well-founded
recursion. It is the local counterpart of the Fixpoint
command. 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\)component of a block of terms defined by a mutual guarded
co-recursion. It is the local counterpart of the CoFixpoint
command. See
Section Definitions of recursive objects in co-inductive types 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 co-fixpoints.
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] Definitionident
[binders
] [:term
] :=term
. | Letident
[binders
] [:term
] :=term
. inductive ::= Inductiveind_body
with … withind_body
. | CoInductiveind_body
with … withind_body
. ind_body ::=ident
[binders
] :term
:= [[|]ident
[binders
] [:term
] | … |ident
[binders
] [:term
]] fixpoint ::= Fixpointfix_body
with … withfix_body
. | CoFixpointcofix_body
with … withcofix_body
. assertion ::=assertion_keyword
ident
[binders
] :term
. assertion_keyword ::= Theorem | Lemma | Remark | Fact | Corollary | Proposition | Definition | Example proof ::= Proof . … Qed . | Proof . … Defined . | Proof . … Admitted .
This grammar 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 well-typed.
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
.
-
Command
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.
-
Variant
Local Axiom ident : term.
Such axioms are never made accessible through their unqualified name by
Import
and its variants. You have to explicitly give their fully qualified name to refer to them.
This command links term
to the name ident
in the context of
the current section (see Section Section mechanism 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
.
Synonyms of Variable
.
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).
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 \(\delta\)-conversion (see Section δ-reduction). A definition is accepted by the system if and only if the defined term is well-typed 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 Typing rules.
-
Command
Definition ident := term.
¶ This command binds
term
to the nameident
in the environment, provided thatterm
is well-typed.
-
Variant
Definition ident : term := term.
It checks that the type of
term
\(_2\) is definitionally equal toterm
\(_1\), and registersident
as being of typeterm
\(_1\), and bound to valueterm
\(_2\).
-
Variant
Definition ident binder* : term := term.
This is equivalent to
Definition
ident
:forall
binder
\(_1\) …binder
\(_n\),term
\(_1\) := funbinder
\(_1\) …binder
\(_n\) =>term
\(_2\).
-
Variant
Local Definition ident := term.
Such definitions are never made accessible through their unqualified name by
Import
and its variants. You have to explicitly give their fully qualified name to refer to them.
These are synonyms of the Definition forms.
See also Opaque
, Transparent
, unfold
.
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 let-in definition let
ident
:=
term
in
. Using the Let
command out of any section is equivalent to using
Local Definition
.
-
Variant
Let CoFixpoint ident cofix_body with cofix_body*.
See also Sections Section mechanism, commands Opaque
,
Transparent
, and tactic unfold
.
Inductive definitions¶
We gradually explain simple inductive types, simple annotated inductive types, simple parametric inductive types, mutually inductive types. We explain also co-inductive types.
Simple inductive types¶
The definition of a simple inductive type has the following form:
The name ident
is the name of the inductively defined type and
sort
is the universes where it lives. The ident
are the names
of its constructors and type
their respective types. The types of the
constructors have to satisfy a positivity condition (see Section
Positivity Condition) for ident
. This condition ensures the soundness of
the inductive definition. If this is the case, the ident
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:
- Inductive nat : Set := | 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:
- Check nat_ind.
- 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 second-order 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).
- Inductive nat : Set := O | S (_:nat).
- Toplevel input, characters 0-37: > Inductive nat : Set := O | S (_:nat). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: nat already exists.
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:
- Inductive even : nat -> Prop := | 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:
- Check even_ind.
- 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
.
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
invoke the inductive type with
the same values of parameters as its specification.
A typical example is the definition of polymorphic lists:
- Inductive list (A:Set) : Set := | nil : list A | cons : A -> list A -> list A.
- list is defined list_rect is defined list_ind is defined list_rec is defined
Note
In the type of nil
and cons
, we write (list A)
and not
just list
. The constructors nil
and cons
will have respectively
types:
- Check nil.
- nil : forall A : Set, list A
- Check cons.
- cons : forall A : Set, A -> list A -> list A
Types of destructors are also quantified with (A:Set)
.
Variants¶
- Inductive list (A:Set) : Set := nil | cons (_:A) (_:list A).
- Toplevel input, characters 0-60: > Inductive list (A:Set) : Set := nil | cons (_:A) (_:list A). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: list already exists.
This is an alternative definition of lists where we specify the arguments of the constructors rather than their full type.
- Variant sum (A B:Set) : Set := left : A -> sum A B | right : B -> sum A B.
- sum is defined
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 Nonrecursive Elimination Schemes
is set.
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 :
- Inductive list2 (A:Set) : Set := | 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:
- Inductive list2 (A:Set) : Set := nil2 | cons2 (_:A) (_:list2 (A*A)).
- list2 is defined list2_rect is defined list2_ind is defined list2_rec is defined
But the following definition will give an error:
- Fail Inductive listw (A:Set) : Set := | 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 Section Inductive Definitions and the induction
tactic.
Mutually defined inductive types¶
The definition of a block of mutually inductive types has the form:
-
Variant
Inductive ident : term := |? ident : type | ident : type* with ident : term := |? ident : type | ident : type**.
It has the same semantics as the above Inductive
definition for each
ident
All ident
are simultaneously added to the environment.
Then well-typing of constructors can be checked. Each one of the ident
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:
-
Variant
Inductive ident binder+ : term := |? ident : type | ident : type* with ident binder+ : term := |? ident : type | ident : type**.
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.
- Variables A B : Set.
- Toplevel input, characters 0-20: > Variables A B : Set. > ^^^^^^^^^^^^^^^^^^^^ Warning: A is declared as a local axiom [local-declaration,scope] A is declared Toplevel input, characters 0-20: > Variables A B : Set. > ^^^^^^^^^^^^^^^^^^^^ Warning: B is declared as a local axiom [local-declaration,scope] B is declared
- Inductive tree : Set := node : A -> forest -> tree with forest : Set := | leaf : B -> forest | cons : tree -> forest -> forest.
- tree, forest are defined tree_rect is defined tree_ind is defined tree_rec is defined forest_rect is defined forest_ind is defined forest_rec is defined
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
.
- Check tree_rec.
- tree_rec : forall P : tree -> Set, (forall (a : A) (f : forest), P (node a f)) -> forall t : tree, P t
- 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:
- Inductive tree (A B:Set) : Set := 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.
- Toplevel input, characters 0-177: > Inductive tree (A B:Set) : Set := 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error: forest already exists.
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 Section mechanism.
Co-inductive types¶
The objects of an inductive type are well-founded with respect to the constructors of the type. In other words, such objects contain only a finite number of constructors. Co-inductive types arise from relaxing this condition, and admitting types whose objects contain an infinity of constructors. Infinite objects are introduced by a non-ending (but effective) process of construction, defined in terms of the constructors of the type.
An example of a co-inductive type is the type of infinite sequences of
natural numbers, usually called streams. It can be introduced in
Coq using the CoInductive
command:
- CoInductive Stream : Set := Seq : nat -> Stream -> Stream.
- Stream is defined
The syntax of this command is the same as the command Inductive
. Notice
that no principle of induction is derived from the definition of a co-inductive
type, since such principles only make sense for inductive ones. For co-inductive
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:
- Definition hd (x:Stream) := let (a,s) := x in a.
- hd is defined
- Definition tl (x:Stream) := let (a,s) := x in s.
- tl is defined
Definition of co-inductive predicates and blocks of mutually co-inductive definitions are also allowed. An example of a co-inductive predicate is the extensional equality on streams:
- CoInductive EqSt : Stream -> Stream -> Prop := 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 s1
and s2
we have to construct an infinite proof of equality, that is, an infinite object
of type (EqSt s1 s2)
. We will see how to introduce infinite objects in
Section Definitions of recursive objects in co-inductive types.
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 the Function
command for more advanced
constructions.
This command allows defining functions by pattern-matching 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 :
- Fixpoint add (n m:nat) {struct n} : nat := 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
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 type-checking 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
The match … with … end construction.
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:
- Fail Fixpoint wrongplus (n m:nat) {struct n} : nat := match m with | O => n | S p => S (wrongplus n p) end.
- The command has indeed failed with message: Recursive definition of wrongplus is ill-formed. 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:
- Fixpoint plus (n m:nat) {struct m} : nat := match m with | O => n | S p => S (plus n p) end.
- plus is defined plus is recursively defined (decreasing on 2nd argument)
Example
The ordinary match operation on natural numbers can be mimicked in the following way.
- Fixpoint nat_match (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.
- nat_match is defined nat_match is recursively defined (decreasing on 4th argument)
Example
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.
- Fixpoint mod2 (n:nat) : nat := match n with | O => O | S p => match p with | O => S O | S q => mod2 q end end.
- mod2 is defined mod2 is recursively defined (decreasing on 1st argument)
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.
allows to define simultaneously fixpoints.
The size of trees and forests can be defined the following way:
- Fixpoint tree_size (t:tree) : nat := 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.
- tree_size is defined forest_size is defined tree_size, forest_size are recursively defined (decreasing respectively on 1st, 1st arguments)
A generic command Scheme is useful to build automatically various mutual induction principles. It is described in Section Generation of induction principles with Scheme.
Definitions of recursive objects in co-inductive types¶
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 Co-inductive types for the definition of Stream
, hd
and
tl
):
- CoFixpoint from (n:nat) : Stream := Seq n (from (S n)).
- from is defined from is corecursively defined
Oppositely to recursive ones, there is no decreasing argument in a
co-recursive 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 co-recursive
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:
- Fail CoFixpoint filter (p:nat -> bool) (s:Stream) : Stream := 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 ill-formed. 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 co-recursive 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:
- Eval compute in (from 0).
- = (cofix from (n : nat) : Stream := Seq n (from (S n))) 0 : Stream
- Eval compute in (hd (from 0)).
- = 0 : nat
- Eval compute in (tl (from 0)).
- = (cofix from (n : nat) : Stream := Seq n (from (S n))) 1 : Stream
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 Proof handling and the tactics in Chapter Tactics. The basic assertion command is:
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 , type
and
the theorem is bound to the name ident
in the environment.
-
Error
ident already exists (Theorem)
¶ The name you provided is already defined. You have then to choose another name.
-
Variant
Theorem ident : type with ident : 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 co-inductive type. It is equivalent to
Fixpoint
orCoFixpoint
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 co-inductive 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
orCoFixpoint
definition, the induction hypotheses have to be used on structurally smaller arguments (for aFixpoint
) or be guarded by a constructor (for aCoFixpoint
). 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 commandGuarded
.The command can be used also with
Lemma
,Remark
, etc. instead ofTheorem
.
-
Variant
Definition ident : 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 withDefined
in order to define a constant of which the computational behavior is relevant.The command can be used also with
Example
instead ofDefinition
.See also
Opaque
,Transparent
,unfold
.
-
Variant
Let ident : type.
Like Definition
ident
:type
. except that the definition is turned into a let-in definition generalized over the declarations depending on it after closing the current section.
-
Variant
Fixpoint ident binders with .
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.
-
Variant
CoFixpoint ident with.
This generalizes the syntax of CoFixpoint so that one or more bodies can be defined interactively using the proof editing mode.
-
Command
Proof
¶ 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 Tactics. Besides tactics, there are commands to manage the proof editing mode. They are described in Chapter Proof handling.
-
Command
Qed
¶ When the proof is completed it should be validated and put in the environment using the keyword Qed.
Note
- 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 Performing computations), thus realizing some form of proof-irrelevance. To be able to unfold a proof, the proof should be ended by Defined (see below).
-
Variant
Defined
¶ Same as
Qed
but the proof is then declared transparent, which means that its content can be explicitly used for type-checking and that it can be unfolded in conversion tactics (see Performing computations,Opaque
,Transparent
).
-
Variant
Admitted.
¶ Turns the current asserted statement into an axiom and exits the proof mode.
[1] | This is similar to the expression “entry \(\{\) sep entry \(\}\)” in standard BNF, or “entry \((\) sep entry \()\)*” in the syntax of regular expressions. |
[2] | Except if the inductive type is empty in which case there is no equation that can be used to infer the return type. |