Chapter 2 The module system

This chapter introduces the module system of OCaml.

2.1 Structures

A primary motivation for modules is to package together relateddefinitions (such as the definitions of a data type and associatedoperations over that type) and enforce a consistent naming scheme forthese definitions. This avoids running out of names or accidentallyconfusing names. Such a package is called a structure andis introduced by the struct…end construct, which contains anarbitrary sequence of definitions. The structure is usually given aname with the module binding. Here is for instance a structurepackaging 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
  end

Outside the structure, its components can be referred to using the“dot notation”, that is, identifiers qualified by a structure name.For instance, PrioQueue.insert is the function insert definedinside the structure PrioQueue and PrioQueue.queue is the typequeue defined in PrioQueue.

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

Another possibility is to open the module, which brings allidentifiers defined inside the module in the scope of the currentstructure.

   open PrioQueue;;

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

Opening a module enables lighter access to its components, at thecost of making it harder to identify in which module a identifierhas been defined. In particular, opened modules can shadowidentifiers present in the current scope, potentially leadingto confusing errors:

   let empty = []
    open PrioQueue;;
val empty : 'a list = []

   let x = 1 :: empty ;;
Error: This expression has type 'a PrioQueue.queue
       but an expression was expected of type int list

A partial solution to this conundrum is to open modules locally,making the components of the module available only in theconcerned expression. This can also make the code easier to read– the open statement is closer to where it is used– and to refactor– the code fragment is more self-contained.Two constructions are available for this purpose:

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

and

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

In the second form, when the body of a local open is itself delimitedby parentheses, braces or bracket, the parentheses of the local opencan be omitted. For instance,

   PrioQueue.[empty] = PrioQueue.([empty]);;
- : bool = true

   PrioQueue.[|empty|] = PrioQueue.([|empty|]);;
- : bool = true

    PrioQueue.{ contents = empty } = PrioQueue.({ contents = empty });;
- : bool = true

becomes

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

It is also possible to copy the components of a module insideanother module by using an include statement. This can beparticularly useful to extend existing modules. As an illustration,we could add functions that returns an optional value rather thanan exception when the priority queue is empty.

   module PrioQueueOpt =
    struct
      include PrioQueue
      let remove_top_opt x =
        try Some(remove_top x) with Queue_is_empty -> None
      let extract_opt x =
        try Some(extract x) with Queue_is_empty -> None
    end;;
module PrioQueueOpt :
  sig
    type priority = int
    type 'a queue =
      'a PrioQueue.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
    val remove_top_opt : 'a queue -> 'a queue option
    val extract_opt : 'a queue -> (priority * 'a * 'a queue) option
  end

2.2 Signatures

Signatures are interfaces for structures. A signature specifieswhich components of a structure are accessible from the outside, andwith which type. It can be used to hide some components of a structure(e.g. local function definitions) or export some components with arestricted type. For instance, the signature below specifies the threepriority queue operations empty, insert and extract, but not theauxiliary function remove_top. Similarly, it makes the queue typeabstract (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
  end

Restricting the PrioQueue structure by this signature results inanother view of the PrioQueue structure where the remove_topfunction is not accessible and the actual representation of priorityqueues is hidden:

 module AbstractPrioQueue = (PrioQueue : PRIOQUEUE);;
module AbstractPrioQueue : PRIOQUEUE

 AbstractPrioQueue.remove_top ;;
Error: 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 thestructure, as in

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

An alternate syntax is provided for the above:

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

Like for modules, it is possible to include a signature to copyits components inside the current signature. For instance, wecan extend the PRIOQUEUE signature with the extract_optfunction:

 module type PRIOQUEUE_WITH_OPT =
    sig
      include PRIOQUEUE
      val extract_opt : 'a queue -> (int * 'a * 'a queue) option
    end;;
module type PRIOQUEUE_WITH_OPT =
  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
    val extract_opt : 'a queue -> (int * 'a * 'a queue) option
  end

2.3 Functors

Functors are “functions” from modules to modules. Functors let you createparameterized modules and then provide other modules as parameter(s) to geta specific implementation. For instance, a Set module implementing setsas sorted lists could be parameterized to work with any module that providesan element type and a comparison function compare (such as OrderedString):

 type comparison = Less | Equal | Greater;;
type comparison = Less | Equal | Greater

 module type ORDERED_TYPE =
    sig
      type t
      val compare: t -> t -> comparison
    end;;
module type ORDERED_TYPE = sig type t val compare : 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.compare 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.compare 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
    end

By applying the Set functor to a structure implementing an orderedtype, we obtain set operations for this type:

 module OrderedString =
    struct
      type t = string
      let compare x y = if x = y then Equal else if x < y then Less else Greater
    end;;
module OrderedString :
  sig type t = string val compare : '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

2.4 Functors and type abstraction

As in the PrioQueue example, it would be good style to hide theactual implementation of the type set, so that users of thestructure will not rely on sets being lists, and we can switch laterto another, more efficient representation of sets without breakingtheir code. This can be achieved by restricting Set by a suitablefunctor 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 structurereturned 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 ;;
Error: This expression has type string but an expression was expected of type
         WrongStringSet.element = WrongSet(OrderedString).element

The problem here is that SET specifies the type elementabstractly, so that the type equality between element in the resultof the functor and t in its argument is forgotten. Consequently,WrongStringSet.element is not the same type as string, and theoperations of WrongStringSet cannot be applied to strings.As demonstrated above, it is important that the type element in thesignature SET be declared equal to Elt.t; unfortunately, this isimpossible above since SET is defined in a context where Elt doesnot exist. To overcome this difficulty, OCaml provides awith type construct over signatures that allows enriching a signaturewith extra type equalities:

 module AbstractSet2 =
    (Set : functor(Elt: ORDERED_TYPE) -> (SET with type element = Elt.t));;
module AbstractSet2 :
  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 providedfor defining functors and restricting their result:

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

Abstracting a type component in a functor result is a powerfultechnique that provides a high degree of type safety, as we nowillustrate. Consider an ordering over character strings that isdifferent from the standard ordering implemented in theOrderedString structure. For instance, we compare strings withoutdistinguishing upper and lower case.

 module NoCaseString =
    struct
      type t = string
      let compare s1 s2 =
        OrderedString.compare (String.lowercase_ascii s1) (String.lowercase_ascii s2)
    end;;
module NoCaseString :
  sig type t = string val compare : 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 ;;
Error: This expression has type
         AbstractStringSet.set = AbstractSet(OrderedString).set
       but an expression was expected of type
         NoCaseStringSet.set = AbstractSet(NoCaseString).set

Note that the two types AbstractStringSet.set andNoCaseStringSet.set are not compatible, and values of thesetwo types do not match. This is the correct behavior: even though bothset types contain elements of the same type (strings), they are builtupon different orderings of that type, and different invariants needto be maintained by the operations (being strictly increasing for thestandard ordering and for the case-insensitive ordering). Applyingoperations from AbstractStringSet to values of typeNoCaseStringSet.set could give incorrect results, or buildlists that violate the invariants of NoCaseStringSet.

2.5 Modules and separate compilation

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

In OCaml, compilation units are special cases of structuresand signatures, and the relationship between the units can beexplained easily in terms of the module system. A compilation unit Acomprises two files:

• the implementation file A.ml, which contains a sequenceof definitions, analogous to the inside of a struct…endconstruct;
• the interface file A.mli, which contains a sequence ofspecifications, analogous to the inside of a sig…endconstruct. These two files together define a structure named A as ifthe following definition was entered at top-level:

module A: sig (* contents of file A.mli *) end
        = struct (* contents of file A.ml *) end;;

The files that define the compilation units can be compiled separatelyusing the ocamlc -c command (the -c option means “compile only, donot try to link”); this produces compiled interface files (withextension .cmi) and compiled object code files (with extension.cmo). When all units have been compiled, their .cmo files arelinked together using the ocamlc command. For instance, the followingcommands compile and link a program composed of two compilation unitsAux and Main:

$ 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.cmo

The program behaves exactly as if the following phrases were enteredat 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, Main can refer to Aux: the definitions anddeclarations contained in Main.ml and Main.mli can refer todefinition in Aux.ml, using the Aux.ident notation, providedthese definitions are exported in Aux.mli.

The order in which the .cmo files are given to ocamlc during thelinking phase determines the order in which the module definitionsoccur. Hence, in the example above, Aux appears first and Main canrefer to it, but Aux cannot refer to Main.

Note that only top-level structures can be mapped toseparately-compiled files, but neither functors nor module types.However, all module-class objects can appear as components of astructure, so the solution is to put the functor or module typeinside a structure, which can then be mapped to a file.