Chapter 19  Canonical Structures

• 19.1  Notation overloading
• 19.2  Hierarchy of structures

Assia Mahboubi and Enrico Tassi

This chapter explains the basics of Canonical Structure and how they can be used to overload notations and build a hierarchy of algebraic structures. The examples are taken from [103]. We invite the interested reader to refer to this paper for all the details that are omitted here for brevity. The interested reader shall also find in [76] a detailed description of another, complementary, use of Canonical Structures: advanced proof search. This latter papers also presents many techniques one can employ to tune the inference of Canonical Structures.

19.1  Notation overloading

We build an infix notation == for a comparison predicate. Such notation will be overloaded, and its meaning will depend on the types of the terms that are compared.

We use Coq modules as name spaces. This allows us to follow the same pattern and naming convention for the rest of the chapter. The base name space contains the definitions of the algebraic structure. To keep the example small, the algebraic structure EQ.type we are defining is very simplistic, and characterizes terms on which a binary relation is defined, without requiring such relation to validate any property. The inner theory module contains the overloaded notation == and will eventually contain lemmas holding on all the instances of the algebraic structure (in this case there are no lemmas).

Note that in practice the user may want to declare EQ.obj as a coercion, but we will not do that here.

The following line tests that, when we assume a type e that is in the EQ class, then we can relates two of its objects with ==.

Still, no concrete type is in the EQ class. We amend that by equipping nat with a comparison relation.

This last test shows that Coq is now not only able to typecheck 3==3, but also that the infix relation was bound to the nat_eq relation. This relation is selected whenever == is used on terms of type nat. This can be read in the line declaring the canonical structure nat_EQty, where the first argument to Pack is the key and its second argument a group of canonical values associated to the key. In this case we associate to nat only one canonical value (since its class, nat_EQcl has just one member). The use of the projection op requires its argument to be in the class EQ, and uses such a member (function) to actually compare its arguments.

Similarly, we could equip any other type with a comparison relation, and use the == notation on terms of this type.

19.1.1  Derived Canonical Structures

We know how to use == on base types, like nat, bool, Z. Here we show how to deal with type constructors, i.e. how to make the following example work:

The error message is telling that Coq has no idea on how to compare pairs of objects. The following construction is telling Coq exactly how to do that.

Thanks to the pair_EQty declaration, Coq is able to build a comparison relation for pairs whenever it is able to build a comparison relation for each component of the pair. The declaration associates to the key * (the type constructor of pairs) the canonical comparison relation pair_eq whenever the type constructor * is applied to two types being themselves in the EQ class.

19.2  Hierarchy of structures

To get to an interesting example we need another base class to be available. We choose the class of types that are equipped with an order relation, to which we associate the infix <= notation.

As before we register a canonical LE class for nat.

And we enable Coq to relate pair of terms with <=.

At the current stage we can use == and <= on concrete types, like tuples of natural numbers, but we can’t develop an algebraic theory over the types that are equipped with both relations.

We need to define a new class that inherits from both EQ and LE.

The mixin component of the LEQ class contains all the extra content we are adding to EQ and LE. In particular it contains the requirement that the two relations we are combining are compatible.

Unfortunately there is still an obstacle to developing the algebraic theory of this new class.

The problem is that the two classes LE and LEQ are not yet related by a subclass relation. In other words Coq does not see that an object of the LEQ class is also an object of the LE class.

The following two constructions tell Coq how to canonically build the LE.type and EQ.type structure given an LEQ.type structure on the same type.

We can now formulate out first theorem on the objects of the LEQ structure.

Of course one would like to apply results proved in the algebraic setting to any concrete instate of the algebraic structure.

Again one has to tell Coq that the type nat is in the LEQ class, and how the type constructor * interacts with the LEQ class. In the following proofs are omitted for brevity.

The following script registers an LEQ class for nat and for the type constructor *. It also tests that they work as expected.

Unfortunately, these declarations are very verbose. In the following subsection we show how to make these declaration more compact.

Note that no direct proof of n <= m -> m <= n -> n == m is provided by the user for n and m of type nat * nat. What the user provides is a proof of this statement for n and m of type nat and a proof that the pair constructor preserves this property. The combination of these two facts is a simple form of proof search that Coq performs automatically while inferring canonical structures.

19.2.1  Compact declaration of Canonical Structures

We need some infrastructure for that.

To explain the notation [find v | t1 ~t2] let us pick one of its instances: [find e | EQ.obj e ~T | "is not an EQ.type" ]. It should be read as: “find a class e such that its objects have type T or fail with message "T is not an EQ.type"”.

The other utilities are used to ask Coq to solve a specific unification problem, that will in turn require the inference of some canonical structures. They are explained in mode details in [103].

We now have all we need to create a compact “packager” to declare instances of the LEQ class.

The object Pack takes a type T (the key) and a mixin m. It infers all the other pieces of the class LEQ and declares them as canonical values associated to the T key. All in all, the only new piece of information we add in the LEQ class is the mixin, all the rest is already canonical for T and hence can be inferred by Coq.

Pack is a notation, hence it is not type checked at the time of its declaration. It will be type checked when it is used, an in that case T is going to be a concrete type. The odd arguments _ and id we pass to the packager represent respectively the classes to be inferred (like e, o, etc) and a token (id) to force their inference. Again, for all the details the reader can refer to [103].

The declaration of canonical instances can now be way more compact:

Error messages are also quite intelligible (if one skips to the end of the message).