This chapter describes Gallina, the specification language of Coq. It allows to develop 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 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.
Grammars are presented in Backus-Naur 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.
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”.
Space, newline and horizontal tabulation are considered as blanks. Blanks are ignored but they separate tokens.
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, 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] |
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 entry unicode-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.
Numerals are sequences of digits. Integers are numerals optionally preceded by a minus sign.
| digit | ::= | 0..9 |
| num | ::= | digit…digit |
| integer | ::= | [-]num |
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.
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 |
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.
Figures 1.1 and 1.2 describe the basic set of terms which form the Calculus of Inductive Constructions (also called pCic). The formal presentation of pCic is given in Chapter 4. Extensions of this syntax are given in chapter 2. How to customize the syntax is described in Chapter 11.
term ::= forall binderlist , term (1.2.8) | fun binderlist => term (1.2.7) | fix fix_bodies (1.2.14) | cofix cofix_bodies (1.2.14) | let ident_with_params := 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) | if term [dep_ret_type] then term else term (1.2.13, 2.2.1) | term : term (1.2.10) | term -> term (1.2.8) | term arg … arg (1.2.9) | @ qualid [term … term] (2.7.7) | term % ident (11.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) arg ::= term | ( ident := term ) (2.7.7) binderlist ::= name … name [: term] 1.2.6 | binder binderlet … binderlet binder ::= name 1.2.6 | ( name … name : term ) binderlet ::= binder 1.2.6 | ( name [: term] := term ) name ::= ident | _ qualid ::= ident | qualid access_ident sort ::= Prop | Set | Type
Figure 1.1: Syntax of terms
ident_with_params ::= ident [binderlet … binderlet] [: term] 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 binderlet … binderlet [annotation] [: term] := term cofix_body ::= ident_with_params := term annotation ::= { struct ident } match_item ::= term [as name] [in term] 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 | pattern as ident | pattern % ident | qualid | _ | num | ( or_pattern , … , or_pattern ) or_pattern ::= pattern | … | pattern
Figure 1.2: Syntax of terms (continued)
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.
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 have no definite semantics in the calculus. They are mere notations that can be bound to objects through the notation mechanism (see Chapter 11 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.
There are three sorts Set, Prop and Type.
More on sorts can be found in Section 4.1.1.
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.
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: ( ident1…identn : type ).
Some constructions allow the binding of a variable to value. This is called a “let-binder”. The entry binderlet of the grammar accepts either a 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 binderlet are allowed. In the case of fun and forall, the first binder of the list cannot be a let-binder, but 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).
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 one-variable functions. For instance the expression “fun ident1 … identn : type => term” denotes the same function as “fun ident1 : type => … fun identn : type => term”. If a let-binder occurs in the list of binders, it is expanded to a local definition (see Section 1.2.12).
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 Π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.
The expression term0 term1 denotes the application of term0 to term1.
The expression term0 term1 ... termn denotes the application of the term term0 to the arguments term1 ... then termn. It is equivalent to ( … ( term0 term1 ) … ) termn : 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.7).
The expression “term : type” is a type cast expression. It enforces the type of term to be type.
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 ident := term1 in term2 denotes the local binding of term1 to the variable ident in term2. There is a syntactic sugar for local definition of functions: let ident binder1 …bindern := term1 in term2 stands for let ident := fun binder1 …bindern => term2 in term2.
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 2.2.1 and Chapter 15 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 … ident.
The expression match term0 return_type with pattern1 => term1 | … | patternn => termn end, denotes a pattern-matching over the term term0 (expected to be of an inductive type I). The terms term1…termn are the branches of the pattern-matching expression. Each of patterni 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 branches2.
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:
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 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.
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 15.3). 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 _ … _ ident1 … identn” clause, where
For instance, in the following example:
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 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 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 (… , … , …) := … in …” (see Sections 2.2.2 and 2.2.3).
The expression “fix ident1 binder1 : type1 := term1 with … with identn bindern : typen := termn for identi” denotes the ithcomponent of a block of functions defined by mutual well-founded recursion. It is the local counterpart of the Fixpoint command. See Section 1.3.4 for more details. When n=1, the “for identi” clause is omitted.
The expression “cofix ident1 binder1 : type1 with … with identn bindern : typen for identi” denotes the ithcomponent of a block of terms defined by a mutual guarded co-recursion. It is the local counterpart of the CoFixpoint command. See Section 1.3.4 for more details. When n=1, the “for identi” 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.
sentence ::= declaration | definition | inductive | fixpoint | statement [proof] declaration ::= declaration_keyword assums . declaration_keyword ::= Axiom | Conjecture | Parameter | Parameters | Variable | Variables | Hypothesis | Hypotheses assums ::= ident … ident : term | binder … binder definition ::= Definition ident_with_params := term . | Let ident_with_params := term . inductive ::= Inductive ind_body with … with ind_body . | CoInductive ind_body with … with ind_body . ind_body ::= ident [binderlet … binderlet] : term := [[|] ident_with_params | … | ident_with_params] fixpoint ::= Fixpoint fix_body with … with fix_body . | CoFixpoint cofix_body with … with cofix_body . statement ::= statement_keyword ident [binderlet … binderlet] : term . statement_keyword ::= Theorem | Lemma | Definition proof ::= Proof . … Qed . | Proof . … Defined . | Proof . … Admitted .
Figure 1.3: Syntax of sentences
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 well-typed.
The declaration mechanism allows the user to specify his own basic objects. Declared objects play the role of axioms or parameters in mathematics. A declared object is an ident associated to a term. A declaration is accepted by Coq if and only if this term is a correct type in the current context of the declaration and ident was not previously defined in the same module. This term is considered to be the type, or specification, of the ident.
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:
Remark: It is possible to replace Parameter by Parameters.
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 Axiom.
Error messages:
Variants:
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).
Definitions differ from declarations in allowing to give a name to a term whereas declarations were just giving a type to a name. That is to say that the name of a defined object can be replaced at any time by its definition. This replacement is called δ-conversion (see Section 4.3). A defined object is accepted by the system if and only if the defining term is well-typed in the current context of the definition. Then the type of the name is the type of term. The defined name is called a constant and one says that the constant is added to the environment.
A formal presentation of constants and environments is given in Section 4.2.
This command binds the value term to the name ident in the environment, provided that term is well-typed.
Error messages:
Variants:
Error messages:
See also: Sections 6.2.4, 6.2.5, 8.5.5
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 local definition let ident := term in.
Error messages:
Variants:
See also: Sections 2.4 (section mechanism), 6.2.4,
6.2.5 (opaque/transparent constants), 8.5.5
We gradually explain simple inductive types, simple annotated inductive types, simple parametric inductive types, mutually inductive types. We explain also co-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 ident1, …, identn are the names of its constructors and type1, …, typen their respective types. The types of the constructors have to satisfy a positivity condition (see Section 4.5.3) for ident. This condition ensures the soundness of the inductive definition. If this is the case, the constants ident, ident1, …, identn 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:
The type nat is defined as the least Set containing O and closed by the S constructor. The constants 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:
This is the well known structural induction principle over natural numbers, i.e. the second-order form of Peano’s induction principle. It allows to prove 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:
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:
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:
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:
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 termi invoke the inductive type with the same values of parameters as its specification.
A typical example is the definition of polymorphic lists:
Note that in the type of nil and cons, we write (list A) and not just list.
The constants nil and
cons will have respectively types:
Types of destructors are also quantified with (A:Set).
Variants:
Error messages:
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 :
that can also be written by specifying only the type of the arguments:
But the following definition will give an error:
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.7.
The definition of a block of mutually inductive types has the form:
| Inductive ident1 : type1 := | ||||||||||||
| ||||||||||||
| with | ||||||||||||
| … | ||||||||||||
| with identm : typem := | ||||||||||||
|
It has the same semantics as the above Inductive definition for each ident1, …, identm. All names ident1, …, identm and ident11, …, identnmm are simultaneously added to the environment. Then well-typing of constructors can be checked. Each one of the ident1, …, identm 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 ident1 params : type1 := | ||||||||||||
| ||||||||||||
| with | ||||||||||||
| … | ||||||||||||
| with identm params : typem := | ||||||||||||
|
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.
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.
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:
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
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:
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 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 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:
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 1.3.4.
This section describes the primitive form of definition by recursion over inductive objects. See Section 2.3 for more advanced constructions. The command:
allows to define 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 type0, and is equivalent to the expression term0. The type of the ident is consequently forall params , type0 and the value is equivalent to fun params => term0.
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. This annotation may be left implicit for fixpoints where only one argument has an inductive type. For instance, one can define the addition function as :
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.4. 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:
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:
The ordinary match operation on natural numbers can be mimicked in the following way.
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.
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:
Example: The size of trees and forests can be defined the following way:
A generic command Scheme is useful to build automatically various mutual induction principles. It is described in Section 8.14.
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):
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:
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:
Variants:
A statement claims a goal of which the proof is then interactively done using tactics. More on the proof editing mode, statements and proofs can be found in Chapter 7.
This command binds type to the name ident in the environment, provided that a proof of type is next given.
After a statement, Coq needs a proof.
Variants:
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:
Variants: