This chapter introduces the module system of Objective Caml.

A primary motivation for modules is to package together related
definitions (such as the definitions of a data type and associated
operations over that type) and enforce a consistent naming scheme for
these definitions. This avoids running out of names or accidentally
confusing names. Such a package is called a *structure* and
is introduced by the `struct`...`end` construct, which contains an
arbitrary sequence of definitions. The structure is usually given a
name with the `module` binding. Here is for instance a structure
packaging together a type of priority queues and their operations:

# module PrioQueue = struct type priority = int type 'a queue = Empty | Node of priority * 'a * 'a queue * 'a queue let empty = Empty let rec insert queue prio elt = match queue with Empty -> Node(prio, elt, Empty, Empty) | Node(p, e, left, right) -> if prio <= p then Node(prio, elt, insert right p e, left) else Node(p, e, insert right prio elt, left) exception Queue_is_empty let rec remove_top = function Empty -> raise Queue_is_empty | Node(prio, elt, left, Empty) -> left | Node(prio, elt, Empty, right) -> right | Node(prio, elt, (Node(lprio, lelt, _, _) as left), (Node(rprio, relt, _, _) as right)) -> if lprio <= rprio then Node(lprio, lelt, remove_top left, right) else Node(rprio, relt, left, remove_top right) let extract = function Empty -> raise Queue_is_empty | Node(prio, elt, _, _) as queue -> (prio, elt, remove_top queue) end;; module PrioQueue : sig type priority = int type 'a queue = | Empty | Node of priority * 'a * 'a queue * 'a queue val empty : 'a queue val insert : 'a queue -> priority -> 'a -> 'a queue exception Queue_is_empty val remove_top : 'a queue -> 'a queue val extract : 'a queue -> priority * 'a * 'a queue endOutside the structure, its components can be referred to using the ``dot notation'', that is, identifiers qualified by a structure name. For instance,

# PrioQueue.insert PrioQueue.empty 1 "hello";; - : string PrioQueue.queue = PrioQueue.Node (1, "hello", PrioQueue.Empty, PrioQueue.Empty)

Signatures are interfaces for structures. A signature specifies
which components of a structure are accessible from the outside, and
with which type. It can be used to hide some components of a structure
(e.g. local function definitions) or export some components with a
restricted type. For instance, the signature below specifies the three
priority queue operations `empty`, `insert` and `extract`, but not the
auxiliary function `remove_top`. Similarly, it makes the `queue` type
abstract (by not providing its actual representation as a concrete type).

# module type PRIOQUEUE = sig type priority = int (* still concrete *) type 'a queue (* now abstract *) val empty : 'a queue val insert : 'a queue -> int -> 'a -> 'a queue val extract : 'a queue -> int * 'a * 'a queue exception Queue_is_empty end;; module type PRIOQUEUE = sig type priority = int type 'a queue val empty : 'a queue val insert : 'a queue -> int -> 'a -> 'a queue val extract : 'a queue -> int * 'a * 'a queue exception Queue_is_empty endRestricting the

# module AbstractPrioQueue = (PrioQueue : PRIOQUEUE);; module AbstractPrioQueue : PRIOQUEUE # AbstractPrioQueue.remove_top;; Characters 0-28: Unbound value AbstractPrioQueue.remove_top # AbstractPrioQueue.insert AbstractPrioQueue.empty 1 "hello";; - : string AbstractPrioQueue.queue = <abstr>The restriction can also be performed during the definition of the structure, as in

module PrioQueue = (struct ... end : PRIOQUEUE);;An alternate syntax is provided for the above:

module PrioQueue : PRIOQUEUE = struct ... end;;

Functors are ``functions'' from structures to structures. They are used to
express parameterized structures: a structure *A* parameterized by a
structure *B* is simply a functor *F* with a formal parameter
*B* (along with the expected signature for *B*) which returns
the actual structure *A* itself. The functor *F* can then be
applied to one or several implementations *B*_{1} ... *B*_{n}
of *B*, yielding the corresponding structures
*A*_{1} ... *A*_{n}.

For instance, here is a structure implementing sets as sorted lists, parameterized by a structure providing the type of the set elements and an ordering function over this type (used to keep the sets sorted):

# type comparison = Less | Equal | Greater;; type comparison = | Less | Equal | Greater # module type ORDERED_TYPE = sig type t val cmp: t -> t -> comparison end;; module type ORDERED_TYPE = sig type t val cmp : t -> t -> comparison end # module Set = functor (Elt: ORDERED_TYPE) -> struct type element = Elt.t type set = element list let empty = [] let rec add x s = match s with [] -> [x] | hd::tl -> match Elt.cmp x hd with Equal -> s (* x is already in s *) | Less -> x :: s (* x is smaller than all elements of s *) | Greater -> hd :: add x tl let rec member x s = match s with [] -> false | hd::tl -> match Elt.cmp x hd with Equal -> true (* x belongs to s *) | Less -> false (* x is smaller than all elements of s *) | Greater -> member x tl end;; module Set : functor(Elt : ORDERED_TYPE) -> sig type element = Elt.t type set = element list val empty : 'a list val add : Elt.t -> Elt.t list -> Elt.t list val member : Elt.t -> Elt.t list -> bool endBy applying the

# module OrderedString = struct type t = string let cmp x y = if x = y then Equal else if x < y then Less else Greater end;; module OrderedString : sig type t = string val cmp : 'a -> 'a -> comparison end # module StringSet = Set(OrderedString);; module StringSet : sig type element = OrderedString.t type set = element list val empty : 'a list val add : OrderedString.t -> OrderedString.t list -> OrderedString.t list val member : OrderedString.t -> OrderedString.t list -> bool end # StringSet.member "bar" (StringSet.add "foo" StringSet.empty);; - : bool = false

As in the `PrioQueue` example, it would be good style to hide the
actual implementation of the type `set`, so that users of the
structure will not rely on sets being lists, and we can switch later
to another, more efficient representation of sets without breaking
their code. This can be achieved by restricting `Set` by a suitable
functor signature:

# module type SETFUNCTOR = functor (Elt: ORDERED_TYPE) -> sig type element = Elt.t (* concrete *) type set (* abstract *) val empty : set val add : element -> set -> set val member : element -> set -> bool end;; module type SETFUNCTOR = functor(Elt : ORDERED_TYPE) -> sig type element = Elt.t type set val empty : set val add : element -> set -> set val member : element -> set -> bool end # module AbstractSet = (Set : SETFUNCTOR);; module AbstractSet : SETFUNCTOR # module AbstractStringSet = AbstractSet(OrderedString);; module AbstractStringSet : sig type element = OrderedString.t type set = AbstractSet(OrderedString).set val empty : set val add : element -> set -> set val member : element -> set -> bool end # AbstractStringSet.add "gee" AbstractStringSet.empty;; - : AbstractStringSet.set = <abstr>

In an attempt to write the type constraint above more elegantly, one may wish to name the signature of the structure returned by the functor, then use that signature in the constraint:

# module type SET = sig type element type set val empty : set val add : element -> set -> set val member : element -> set -> bool end;; module type SET = sig type element type set val empty : set val add : element -> set -> set val member : element -> set -> bool end # module WrongSet = (Set : functor(Elt: ORDERED_TYPE) -> SET);; module WrongSet : functor(Elt : ORDERED_TYPE) -> SET # module WrongStringSet = WrongSet(OrderedString);; module WrongStringSet : sig type element = WrongSet(OrderedString).element type set = WrongSet(OrderedString).set val empty : set val add : element -> set -> set val member : element -> set -> bool end # WrongStringSet.add "gee" WrongStringSet.empty;; Characters 19-24: This expression has type string but is here used with type WrongStringSet.element = WrongSet(OrderedString).elementThe problem here is that

# module AbstractSet = (Set : functor(Elt: ORDERED_TYPE) -> (SET with type element = Elt.t));; module AbstractSet : functor(Elt : ORDERED_TYPE) -> sig type element = Elt.t type set val empty : set val add : element -> set -> set val member : element -> set -> bool end

As in the case of simple structures, an alternate syntax is provided for defining functors and restricting their result:

module AbstractSet(Elt: ORDERED_TYPE) : (SET with type element = Elt.t) = struct ... end;;

Abstracting a type component in a functor result is a powerful
technique that provides a high degree of type safety, as we now
illustrate. Consider an ordering over character strings that is
different from the standard ordering implemented in the
`OrderedString` structure. For instance, we compare strings without
distinguishing upper and lower case.

# module NoCaseString = struct type t = string let cmp s1 s2 = OrderedString.cmp (String.lowercase s1) (String.lowercase s2) end;; module NoCaseString : sig type t = string val cmp : string -> string -> comparison end # module NoCaseStringSet = AbstractSet(NoCaseString);; module NoCaseStringSet : sig type element = NoCaseString.t type set = AbstractSet(NoCaseString).set val empty : set val add : element -> set -> set val member : element -> set -> bool end # NoCaseStringSet.add "FOO" AbstractStringSet.empty;; Characters 26-49: This expression has type AbstractStringSet.set = AbstractSet(OrderedString).set but is here used with type NoCaseStringSet.set = AbstractSet(NoCaseString).setNotice that the two types

All examples of modules so far have been given in the context of the interactive system. However, modules are most useful for large, batch-compiled programs. For these programs, it is a practical necessity to split the source into several files, called compilation units, that can be compiled separately, thus minimizing recompilation after changes.

In Objective Caml, compilation units are special cases of structures
and signatures, and the relationship between the units can be
explained easily in terms of the module system. A compilation unit *a*
comprises two files:

- the implementation file
*a*`.ml`, which contains a sequence of definitions, analogous to the inside of a`struct`...`end`construct; - the interface file
*a*`.mli`, which contains a sequence of specifications, analogous to the inside of a`sig`...`end`construct.

moduleThe files defining the compilation units can be compiled separately using theA: sig (* contents of filea.mli *) end = struct (* contents of filea.ml *) end;;

$ ocamlc -c aux.mli # produces aux.cmi $ ocamlc -c aux.ml # produces aux.cmo $ ocamlc -c main.mli # produces main.cmi $ ocamlc -c main.ml # produces main.cmo $ ocamlc -o theprogram aux.cmo main.cmoThe program behaves exactly as if the following phrases were entered at top-level:

module Aux: sig (* contents of aux.mli *) end = struct (* contents of aux.ml *) end;; module Main: sig (* contents of main.mli *) end = struct (* contents of main.ml *) end;;In particular,

The order in which the `.cmo` files are given to `ocaml` during the
linking phase determines the order in which the module definitions
occur. Hence, in the example above, `Aux` appears first and `Main` can
refer to it, but `Aux` cannot refer to `Main`.

Notice that only top-level structures can be mapped to separately-compiled files, but not functors nor module types. However, all module-class objects can appear as components of a structure, so the solution is to put the functor or module type inside a structure, which can then be mapped to a file.