Pourquoi 'a t et non t

(* A : pile.mli *)              (* B : pilep.mli *)
type t                          type 'a t
val vide : t                    val vide : 'a t
val empiler : int -> t -> t     val empiler : 'a -> 'a t -> 'a t

Mesuré, en compilant les deux modules puis un utilisateur :

avec A : Pile.empiler 3 Pile.vide         accepte
         Pile.empiler "trois" Pile.vide   error: This constant has type string
                                          but an expression was expected of type int
avec B : les DEUX sont acceptes, et Pilep.sommet rend 3 puis "trois"

Ce que le paramètre apporte. Un type paramétré n'est pas un type : c'est une fonction qui, appliquée à un type, en donne un. 'a t n'existe pas plus que 'a array ; ce sont int t et string t qui existent, et ce sont deux types distincts. La signature B décrit donc, en trois lignes, une infinité de piles — une par type d'élément — sans les écrire.

Ce que le paramètre ne coûte pas. La réalisation est la même :

type 'a t = 'a list
let vide = []
let empiler x p = x :: p

Aucun code n'a été dupliqué. C'est là que la comparaison avec C est instructive : n'ayant pas de type paramétré, C oblige soit à réécrire le module par type d'élément, soit à passer par des void* — c'est-à-dire à abandonner la vérification que l'on cherchait justement à obtenir.

Le lien avec le reste du chapitre. Le programme range le tableau parmi les types paramétrés et le pointeur parmi les types de C. La pile abstraite montre pourquoi le paramétrage est une notion d'interface et non de réalisation : c'est dans la signature qu'il se déclare, et c'est la signature que l'utilisateur lit.