Amokrane Saïbi
This section describes the inheritance mechanism of Coq. In Coq with inheritance, we are not interested in adding any expressive power to our theory, but only convenience. Given a term, possibly not typable, we are interested in the problem of determining if it can be well typed modulo insertion of appropriate coercions. We allow to write:
A class with n parameters is any defined name with a type forall (x1:A1)..(xn:An), s where s is a sort. Thus a class with parameters is considered as a single class and not as a family of classes. An object of a class C is any term of type C t1 .. tn. In addition to these user-classes, we have two abstract classes:
Formally, the syntax of a classes is defined on Figure 16.1.
class ::= qualid | Sortclass | Funclass
Figure 16.1: Syntax of classes
A name f can be declared as a coercion between a source user-class C with n parameters and a target class D if one of these conditions holds:
We then write f:C >-> D. The restriction on the type of coercions is called the uniform inheritance condition. Remark that the abstract classes Funclass and Sortclass cannot be source classes.
To coerce an object t:C t1..tn of C towards D, we have to apply the coercion f to it; the obtained term f t1..tn t is then an object of D.
Identity coercions are special cases of coercions used to go around the uniform inheritance condition. Let C and D be two classes with respectively n and m parameters and f:forall (x1:T1)..(xk:Tk)(y:C u1..un), D v1..vm a function which does not verify the uniform inheritance condition. To declare f as coercion, one has first to declare a subclass C′ of C:
C′ := fun (x1:T1)..(xk:Tk) => C u1..un |
We then define an identity coercion between C′ and C:
|
We can now declare f as coercion from C′ to D, since we can
“cast” its type as
forall (x1:T1)..(xk:Tk)(y:C′ x1..xk),D v1..vm.
The identity
coercions have a special status: to coerce an object t:C′ t1..tk
of C′ towards C, we does not have to insert explicitly Id_C′_C
since Id_C′_C t1..tk t is convertible with t. However we
“rewrite” the type of t to become an object of C; in this case,
it becomes C u1*..uk* where each ui* is the result of the
substitution in ui of the variables xj by tj.
Coercions form an inheritance graph with classes as nodes. We call coercion path an ordered list of coercions between two nodes of the graph. A class C is said to be a subclass of D if there is a coercion path in the graph from C to D; we also say that C inherits from D. Our mechanism supports multiple inheritance since a class may inherit from several classes, contrary to simple inheritance where a class inherits from at most one class. However there must be at most one path between two classes. If this is not the case, only the oldest one is valid and the others are ignored. So the order of declaration of coercions is important.
We extend notations for coercions to coercion paths. For instance [f1;..;fk]:C >-> D is the coercion path composed by the coercions f1..fk. The application of a coercion path to a term consists of the successive application of its coercions.
Declares the construction denoted by qualid as a coercion between class1 and class2.
Error messages:
When the coercion qualid is added to the inheritance graph, non
valid coercion paths are ignored; they are signaled by a warning.
Warning :
Ambiguous paths: | [f11;..;fn11] : C1>->D1 |
... | |
[f1m;..;fnmm] : Cm>->Dm |
Variants:
declaration | ::= | declaration_keyword assums . |
assums | ::= | simple_assums |
| | ( simple_assums) … ( simple_assums) | |
simple_assums | ::= | ident … ident :[>] term |
If the extra > is present before the type of some assumptions, these assumptions are declared as coercions.
inductive | ::= | Inductive ind_body with … with ind_body . |
| | CoInductive ind_body with … with ind_body . | |
ind_body | ::= | ident [binderlet … binderlet] : term := |
[[|] constructor | … | constructor] | ||
constructor | ::= | ident [binderlet … binderlet] [:[>] term] |
Especially, if the extra > is present in a constructor declaration, this constructor is declared as a coercion.
We check that class1 is a constant with a value of the form fun (x1:T1)..(xn:Tn) => (class2 t1..tm) where m is the number of parameters of class2. Then we define an identity function with the type forall (x1:T1)..(xn:Tn)(y:class1 x1..xn), class2 t1..tm, and we declare it as an identity coercion between class1 and class2.
Error messages:
Variants:
Definition ident := type.
followed by
Identity Coercion Id_ident_ident’:ident >-> ident’.
Print the list of declared classes in the current context.
Print the list of declared coercions in the current context.
Print the list of valid coercion paths in the current context.
Print the list of valid coercion paths from class1 to class2.
This command forces all the coercions to be printed. Conversely, to skip the printing of coercions, use Unset Printing Coercions. By default, coercions are not printed.
This command forces coercion denoted by qualid to be printed. To skip the printing of coercion qualid, use Unset Printing Coercion qualid. By default, a coercion is never printed.
We allow the definition of Structures with Inheritance (or classes as records) by extending the existing Record macro (see Section 2.1). Its new syntax is:
Record [>] ident binderlet : sort := [ident0] { | |||
|
The identifier ident is the name of the defined record and sort is its type. The identifier ident0 is the name of its constructor. The identifiers ident1, .., identn are the names of its fields and term1, .., termn their respective types. The alternative [:|:>] is “:” or “:>”. If identi:>termi, then identi is automatically declared as coercion from ident to the class of termi. Remark that identi always verifies the uniform inheritance condition. If the optional “>” before ident is present, then ident0 (or the default name Build_ident if ident0 is omitted) is automatically declared as a coercion from the class of termn to ident (this may fail if the uniform inheritance condition is not satisfied).
Remark: The keyword Structure is a synonym of Record.
The inheritance mechanism is compatible with the section mechanism. The global classes and coercions defined inside a section are redefined after its closing, using their new value and new type. The classes and coercions which are local to the section are simply forgotten. Coercions with a local source class or a local target class, and coercions which do not verify the uniform inheritance condition any longer are also forgotten.
There are three situations:
We first give an example of coercion between atomic inductive types
Warning: “Check true=O.
” fails. This is “normal” behaviour of
coercions. To validate true=O
, the coercion is searched from
nat
to bool
. There is none.
We give an example of coercion between classes with parameters.
We give now an example using identity coercions.
In the case of functional arguments, we use the monotonic rule of sub-typing. Approximatively, to coerce t:forall x:A, B towards forall x:A′,B′, one have to coerce A′ towards A and B towards B′. An example is given below:
Remark the changes in the result following the modification of the previous example.
Let us see the resulting graph of this session.