Parametric polymorphism is a basic mechanism in ML for writing code that is generic, i.e., that can be used on multiple different types. To get the basic idea of how what parametric polymorphism is, think about the following simple example.

module M : sig (* Takes a list and returns a stuttered version, e.g., [1;2;3] is mapped to [1;1;2;2;3;3] *) val double : ' a list -> ' a list end = struct let rec double = function | [] -> [] | hd :: tl -> hd :: hd :: double tl end

In the type signature for double , the expression 'a is a type variable, meaning that this function can be used with an arbitrary type plugged in for 'a . The reason that the type variable shows up is that the code of double doesn’t depend in any way on the properties of the elements of the list. At first glance, parametric polymorphism doesn’t seem all that powerful. After all, how useful is it to write functions that can only be generalized over all possible types? More often than not you want to write functions that can be used over some narrow universe of types with particular properties. Object oriented languages provide this functionality with subtyping, and Haskell lets you get at this with type-classes. What do you do in ML?

It turns out that ML does allow you to write functions like this in a quite straightforward and ordinary way. A simple example can be found be examining the signature of a standard sort function:

val sort : cmp : ( ' a -> ' a -> int ) -> ' a list -> ' a list

The signature above can be used on a value of any type, provided that you can also provide a comparison function for that type. In other words, a polymorphic function can take advantage of the idiosyncratic capabilities of the types it deals with, but the ability to take advantage of those capabilities must be passed in along with the values in question.

This is used in small ways throughout any non-trivial ML codebase. But we can use this in a more structured way by creating what are sometimes called type-indexed values. A type-indexed value is a value used to represent a set of capabilities associated with a type. Here’s an example of a simple type-indexed value for capturing number-ness. In what follows, the type-indexed value is Num.Type.t , and the rest of the Num module is just utility functions to make the interface pretty.

module Num : sig module Type : sig type ' a t val int : int t val float : float t end val (+) : ' a Type . t -> ' a -> ' a -> ' a val (-) : ' a Type . t -> ' a -> ' a -> ' a val ( * ) : ' a Type . t -> ' a -> ' a -> ' a val neg : ' a Type . t -> ' a -> ' a val zero : ' a Type . t -> ' a val sum : ' a Type . t -> ' a list -> ' a val sum_product ' a Type . t -> ' a list -> ' a list -> ' a end = struct module Type = struct module T = struct type ' a t = { plus : ' a -> ' a -> ' a ; mul : ' a -> ' a -> ' a ; neg : ' a -> ' a ; zero : ' a ; } end open T let int = { plus = Int . (+); neg = Int . (-); zero = Int . zero ; mul = Int . mul ; } let float = { plus = Float . (+); neg = Float . (-); zero = Float . zero ; mul = Float . mul ; } end open Type . T let (+) typ x y = typ . plus x y let neg typ x = typ . neg x let zero typ = typ . zero let ( * ) typ x y = typ . mul x y (* Some derived operations *) let (-) typ x y = typ . plus x ( typ . neg y ) let sum typ l = List . fold_left ~ init : typ . zero ~ f : typ . plus l let sum_product typ l1 l2 = sum typ ( List . map2 ~ f : typ . mul l1 l2 ) end

You’ll note that the definition above of Type.int and Type.float are basically boilerplate. Because the modules in question themselves have a fairly standardized interface, we could instead use a functor to create these type-indexed values without the boilerplate:

module type Arith = sig type t val (+) : t -> t -> t val neg : t -> t val zero : t end module Build_type ( M : Arith ) = struct let typ x = { Type . plus = M . (+); neg = M . (-); zero = M . zero ; } end let int = let module Z = Build_type ( Int ) in Z . typ let int64 = let module Z = Build_type ( Int64 ) in Z . typ let int32 = let module Z = Build_type ( Int32 ) in Z . typ let native = let module Z = Build_type ( Native_int ) in Z . typ let float = let module Z = Build_type ( Float ) in Z . typ let complex = let module Z = Build_type ( Complex ) in Z . typ

This is yet another advantage one gets from having standardized interfaces.

If type indexed-values look similar to Haskell’s type-classes, it’s because they are. In my limited understanding of Haskell, the implementation is similar as well, in that under the cover, Haskell passes around dictionaries of functions which play the same role that the Type.t s play here.

The number typeclass described above is just an example, and not something I’ve felt the need for in practice. But here are some places where we’ve used type-indexed values to good effect:

Serialization

The latest (unreleased) version of the bin_prot macros that we use for binary serialization and deserialization now come with a type-indexed value that ties together all the little bits that you need to use the library. Before we did that, one could only instantiate useful bin-prot functionality using the module language. Now, we can do it using ordinary polymorphic functions.

Little languages

Sometimes we design domain-specific languages embedded in the type system. It is often useful to have values representing the different types that can be generated in the language. For example, we use this as part of a set of SQL bindings to represent types that we know how to convert to and from SQL.

Containers

We’ve started experimenting with type-indexed values representing the container-hood of a given object. This is a little trickier than the previous examples, since the type-indexed value has two type parameters, one for the type of the container, and one for the type of the elements of the container. In the end, this let’s you write functions with signatures like

max : ( ' a , ' b ) Container . t -> cmp :( ' a -> ' a -> int ) -> ' b -> ' a

and use it to find the maximum element of a list (where the type-indexed value has type ('a, 'a list) Container.t ) or an array ( ('a, 'a array) Container.t ) or a string ( (char,string) Container.t ).

Type-indexed values obviously have their downsides: they can be somewhat inconvenient syntactically, since you need to explicitly pass them along; and they sacrifice some performance because it leads you to call closures where you could otherwise call static functions that could be inlined instead. But overall, they are a flexible and elegant way of writing generic code in ML.