Preliminaries

The Coq file supporting today's course is available at https://gitlab.math.univ-paris-diderot.fr/saurin/coq-lmfi-2023/-/blob/main/Lectures/Course4.v. https://gitlab.math.univ-paris-diderot.fr/saurin/coq-lmfi-2023/-/blob/main/TP/TP4.v. The aim of this fourth lecture is to deepend the investigation of dependent types in programming, pursuing the journey started in the previous lecture.

Wrap up on basic dependent types

Let us sum up what we saw during the introductory lecture on dependent types.

A dependent type of nat_or_bool

An example of value in this type.

Its type is not bool → nat_or_bool: it is a dependent type, that is the return type depends on the value of the input:

value_nat_or_bool : ∀ b : bool, nat_or_bool b This match b ... is roughly equivalent to if b then 0 else false but writing a if here would not give Coq enough details. Even putting the explicit output type isn't enough, we add to use an extra syntax return ... to help Coq.

Tuples

Let us "program" the desired type, starting from the number n. The obtained type depends from the value of this number: that's hence a dependent type. (Remember the power type considered in Lecture 2 and compare the following type with it.)

Type -> nat -> Type

Note that in the previous match the two branches have different types :

• it is nat in the first case and
• it is (n_tuple nat n' × nat) in the second case.

This is a dependent match, whose typing is quite different from all earlier match we have done, where all branches were having the same common type. Here Coq is clever enough to notice that these different types are actually the correct instances of the claimed type n_tuple nat n, respectively n_tuple nat 0 and n_tuple nat (S n'). But Coq would not be clever enough to guess the output type n_tuple nat n by itself, here it is mandatory to write it.

a 100-uple

Some explanations about implicit arguments

You already noticed that the type notations in Coq can be very heavy espacially to handle type instanciation and all the more when starting working with dependent types. An essential feature of Coq to work smoothly with those types is the ability to declare some arguments as being implicit and let Coq infer the corresponding argument.

An option, is, at the time of the definition, to specify which argument is implicit:

Another option is to automatically declare arguments as implicit when they can be inferred as such:

One can deactivate implicite arguments by using @:

It can also happen that one need to explicitly provide explicit arguments, for instance because of a partial application of arguments:

Inductive dependent types

Vectors

In the previous lecture on dependent types, we saw a first dependent type encoding n-tuples:

We shall now study another encoding of n-tuples. We almost reuse the inductive definition of lists, but we add an extra parameter representing the length of the list so that the type itself is equiped with the information of the length of the list.

Notice that this is a inductive type definition, but the type being defined depends on values of type nat: it is a inductive dependent type:

vect : Type → nat → Type This type vect is implemented in Coq standard library, see file Vector.v. One can declare the domain arguments of the constructors (Vnil and Vcons) as being implicit arguments:

Let us see the encoding of triple (0,2,3) :

The first argument of each constructor (numbers 2, 0, 1) indicates the lengths of each sub-vector. Since this is pretty predictable, and hence "boring", we could even hide the n argument of Vcons. As follows:

But this n argument is still there internally and can be printed by requiring to print all information (in CoqIDE, this is managed in the "View" panel):

@Vcons nat 2 0 (@Vcons nat 1 2 (@Vcons nat 0 3 (@Vnil nat))) : vect nat 3

0 :: 2 :: 3 :: @nil nat)%list

Conversion bewteen vectors and regular lists.

Since vectors are lists with some additional information, one can of course define a conversion function from vectors to lists:

But it is also possible to define the conversion in the other direction:

In the previous definition, we benefited greatly from the implicit argument management offered by Coq. Try to define the same conversion function without declaring the nat argument as implicit...

The following definition (re-)computing the length of a vector is actually useless since we already known this length, it is the parameter n mentionned in the type vect. Later, we could prove that ∀ A n (v:vect A n), length v = n.

We could more simply define it as:

With such vectors, we avoid the usual issues encountered when defining head and cons on lists, requiring to use a default value or an option type. Indeed, we can specify that we want to operate only on non-empty vectors, since they have a Vect A (S n) type for some n. On lists we can define the head function using a default value:

Or returning in the option A type:

On vectors, we can more simply restict the domain of the function Vhead:

Notice that the match branch for Vnil just vanished, and Coq did not complained about a missing case ! Actually, there does exist such a case internally, filled by Coq with a somewhat arbitrary code, that will never be accessed during computations.

Some check to see what is going on with the missing branch:

The error message is: The term "Vnil" has type "vect ?A 0" while it is expected to have type "vect ?A (S ?n)". That is, there is a type mismatch.

Concatenating vectors

Everything goes smoothly here, since this function mimics the equations of the addition on nat.

0 + m = m S p + m = S (p+m)

of type vect A m = vect A (0+m) = vect A (n+m) here

of type vect A (S (p+m)) = vect A ((S p)+m) = vect A (n+m) here

Alas, for other algorithms, we aren not so lucky. For instance, consider the (naive) definition of the reverse of a vector. A direct attempt is rejected as badly-typed. Coq would need to know that vect A (n+1) is equal to vect A (1+n). This is provably true, but not computationally true (a.k.a "convertible" in the Coq jargon). More precisely, we cannot have n+1 = 1+n by just the above (Peano) equations, this would later need a proof by induction.

Which returns the following error message: The term "Vapp (Vrev A n0 v0) (Vcons x Vnil)" has type "vect A (n0 + 1)" while it is expected to have type "vect A (S n0)".

We shall see two solutions to that problem: A first solution is to use the Coq equality to "cast" between vectors of equal lengths. We'll detail more later how Coq represents its logical equality, for now let's just say that it's internally a syntactic correspondence between the two side of the equation. Hence "matching" over this proof h of type n=m would formally "equate" n with m. And all it well.

But for defining our Vrev, we need a proof of n+1=1+n.

That is a lemma called Nat.add_1_r, exactly what we need: remember indeed that 1 + n reduces to S n

Or, forcing the implicit argument to be treated explicitly:

Issue: all computations with this Vrev is blocked, since they cannot access Coq standard proof of Nat.add_1_r (such a proof is said to be "opaque").

Solution inside the solution : do the proof ourself, in a "transparent" way. Forget about this proof for the moment.

And not the usual Qed keyword, that would be opaque:

• Qed ends an opaque proof while
• Defined ends a transparent proof.

Another solution : another definition of Vcast, way more complex, that proceeds by induction over the vector instead of doing an induction over the equality proof. You can skip the (ugly) details of this function Vcast2, just notice that it does exist.

Computing with this Vcast2 means deconstructing the whole vector v before reconstructing everything (but with a length expressed with the other side of the equality).

fix ... match v ...Vil => ... Vnil ... | Vcons n h w => ... Vcons h ... To get the underlying algorithm behind all these details, a nice way it to use the "extraction" tool, that convert a Coq definition into some corresponding OCaml code, and drop on the fly all logical parts (such as the equalities). More on that to come later.

And finally :

And we can compute here, even with Coq standard proof of n+1=1+n.

As a conclusion:

• programming with dependent type may help a lot by ruling out some impossible cases and producing functions with rich types describing precisely the current situation.
• but it is not always convenient to proceed in this style, and may lead you to some definitional nightmare such as this Vrev.

Some more details about dependent types

Perfect binary trees, this time via inductive types.

Just as vectors can be compared to lists, we add an extra argument in nat to perfect binary trees, here encoding the depth of the tree.

Again, arguments of constructors may be treated implicitly:

Dependent pairs (aka. dependent sums).

We have seen that the arrow type A→B has a dependent counterpart, the product ∀ x:A, B x (also called Π-type). Similarly, the pair type A×B, has a dependent version which is called sigT (for Σ-type), with a notation {x:A & B x}.

Inductive sigT (A : Type) (P : A → Type) : Type := existT : ∀ x : A, P x → {x : A & P x}. which is the inductive type, with syntax { ... & ... }

and its constructor

Just as the conclusion of a product may have a type B x which depends on the value x of the input, here the right component of this pair {x:A & B x} will have a type B x which depends on the value x present on the left of this pair. As the name existT of the constructor may suggests, this type can also be seen as an existential type : "there exists an x in A such that the right component is in B x". Example : a type of all perfect binary trees on a domain A, regardless of theirs depth

We can exhibit an inhabitant of this sum type, that is the pair of an m: nat and an inhabitant of fultree A m.

the _ is here the "predicate" B, that Coq can infer here as being fulltree nat. Actually, Coq could even guess here the second argument (1), by typing the last one (obtaining fulltree A 1 here).

To manipulate dependent sums, we have some predefined projections:

of type : (fun n : nat => fulltree nat n) (projT1 some_fulltree) which is convertible to : fulltree nat 1

For instance :

We will see later a few other existential types :

• the type of existential statements ∃ x:A, B x where A and B are in universe Prop.
• the "mixed" existential type {x:A | B x} (with underlying type name sig), where B is a logical statement in Prop, but A is in Type (we call A an "informative" or "relevent" type).

Fin: finite sets

Another famous dependent type : type Fin n, encoding a canonical finite set with exactly n elements. Or said otherwise, the type of all numbers strictly less than n. So this type is also called the "bounded integers".

As usual, let us get rid of some "boring" arguments

Nobody can be in type Fin 0, since all constructors of Fin have final types of the form Fin (S ...). Then Fin 1 is a type with just one element

Then Fin 2 is a type with two elements, but no more

If we convert inhabitants of Fin n back to nat by forgetting all the inner implicit arguments, then we indeed get all nat numbers strictly less than n.

Note : another approach for defining such "bounded" integers is to use an existential type to restrict nat.

• Pros : easy projection to nat, no need for a reconstruction like fin2nat above.
• Cons : This implies to work with logical predicate < (in Prop, not the boolean comparison <? we have been using up to now) and requires to build arithmetical proofs. This is hence less suitable for the Vnth function below (no nice inductive structure).

Application: Vnth

The type Fin of "bounded" integers provides a neat way to specify and implement a safe access to the n-th element of a vector (type vect), recall: Inductive vect' (A:Type) : nat → Type := | Vnil : vect' A 0 | Vcons n : A → vect' A n → vect' A (S n). Arguments Vnil {A}. Arguments Vcons {A} {n}. For a vector v in type vect A n, we can access any position p as long as p is in Fin n (hence garanteed to represent a number strictly less than n.

Notice that this type of programming is still relatively new in Coq, and still very fragile. For instance, in the previous example, one may be tempted to move the recursive call Vnth inside the final match v, and hence write: | Succ p => fun v => match v with Vcons _ v => Vnth p v end But this is rejected by Coq for the moment. Similarly, no way (yet ?) to move out the two fun v ⇒ and factorize them in one fun v ⇒ outside of match p. Example of use: with a vector of size 3, one may access to elements at position 0, 1, 2 but not 3.