8
6
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
9
<META name="GENERATOR" content="hevea 1.08">
7
<META name="GENERATOR" content="hevea 1.09">
10
8
<LINK rel="stylesheet" type="text/css" href="manual.css">
9
<TITLE>The module system</TITLE>
16
<A HREF="manual003.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
17
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
18
<A HREF="manual005.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
12
<A HREF="manual003.html"><IMG SRC="previous_motif.gif" ALT="Previous"></A>
13
<A HREF="index.html"><IMG SRC="contents_motif.gif" ALT="Up"></A>
14
<A HREF="manual005.html"><IMG SRC="next_motif.gif" ALT="Next"></A>
21
<H1 CLASS="chapter"><A NAME="htoc12">Chapter 2</A> The module system</H1> <A NAME="c:moduleexamples"></A>
23
This chapter introduces the module system of Objective Caml.<BR>
26
<H2 CLASS="section"><A NAME="htoc13">2.1</A> Structures</H2>
28
A primary motivation for modules is to package together related
16
<H1 CLASS="chapter"><A NAME="htoc12">Chapter�2</A>��The module system</H1><P> <A NAME="c:moduleexamples"></A>
17
</P><P>This chapter introduces the module system of Objective Caml.</P><H2 CLASS="section"><A NAME="htoc13">2.1</A>��Structures</H2><P>A primary motivation for modules is to package together related
29
18
definitions (such as the definitions of a data type and associated
30
19
operations over that type) and enforce a consistent naming scheme for
31
20
these definitions. This avoids running out of names or accidentally
32
21
confusing names. Such a package is called a <EM>structure</EM> and
33
is introduced by the <TT>struct</TT>...<TT>end</TT> construct, which contains an
22
is introduced by the <TT>struct</TT>…<TT>end</TT> construct, which contains an
34
23
arbitrary sequence of definitions. The structure is usually given a
35
24
name with the <TT>module</TT> binding. Here is for instance a structure
36
25
packaging together a type of priority queues and their operations:
37
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module PrioQueue =
26
</P><PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module PrioQueue =
39
28
type priority = int
40
29
type 'a queue = Empty | Node of priority * 'a * 'a queue * 'a queue
70
59
val remove_top : 'a queue -> 'a queue
71
60
val extract : 'a queue -> priority * 'a * 'a queue
74
63
Outside the structure, its components can be referred to using the
75
“dot notation”, that is, identifiers qualified by a structure name.
64
“dot notation”, that is, identifiers qualified by a structure name.
76
65
For instance, <TT>PrioQueue.insert</TT> in a value context is
77
66
the function <TT>insert</TT> defined inside the structure
78
67
<TT>PrioQueue</TT>. Similarly, <TT>PrioQueue.queue</TT> in a type context is the
79
68
type <TT>queue</TT> defined in <TT>PrioQueue</TT>.
80
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>PrioQueue.insert PrioQueue.empty 1 "hello";;
69
</P><PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>PrioQueue.insert PrioQueue.empty 1 "hello";;
81
70
</FONT><FONT COLOR=maroon>- : string PrioQueue.queue =
82
71
PrioQueue.Node (1, "hello", PrioQueue.Empty, PrioQueue.Empty)
85
<H2 CLASS="section"><A NAME="htoc14">2.2</A> Signatures</H2>
87
Signatures are interfaces for structures. A signature specifies
72
</FONT></PRE><H2 CLASS="section"><A NAME="htoc14">2.2</A>��Signatures</H2><P>Signatures are interfaces for structures. A signature specifies
88
73
which components of a structure are accessible from the outside, and
89
74
with which type. It can be used to hide some components of a structure
90
75
(e.g. local function definitions) or export some components with a
110
95
val extract : 'a queue -> int * 'a * 'a queue
111
96
exception Queue_is_empty
114
99
Restricting the <TT>PrioQueue</TT> structure by this signature results in
115
100
another view of the <TT>PrioQueue</TT> structure where the <TT>remove_top</TT>
116
101
function is not accessible and the actual representation of priority
117
102
queues is hidden:
118
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module AbstractPrioQueue = (PrioQueue : PRIOQUEUE);;
103
</P><PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module AbstractPrioQueue = (PrioQueue : PRIOQUEUE);;
119
104
</FONT><FONT COLOR=maroon>module AbstractPrioQueue : PRIOQUEUE
121
106
<FONT COLOR=black>#</FONT><FONT COLOR=blue><U>AbstractPrioQueue.remove_top</U>;;
122
107
</FONT>Unbound value AbstractPrioQueue.remove_top
124
109
<FONT COLOR=black>#</FONT><FONT COLOR=blue>AbstractPrioQueue.insert AbstractPrioQueue.empty 1 "hello";;
125
110
</FONT>- : string AbstractPrioQueue.queue = <abstr>
127
112
The restriction can also be performed during the definition of the
129
<PRE CLASS="verbatim">
130
module PrioQueue = (struct ... end : PRIOQUEUE);;
131
</PRE>An alternate syntax is provided for the above:
132
<PRE CLASS="verbatim">
133
module PrioQueue : PRIOQUEUE = struct ... end;;
136
<H2 CLASS="section"><A NAME="htoc15">2.3</A> Functors</H2>
138
Functors are “functions” from structures to structures. They are used to
114
</P><PRE CLASS="verbatim">module PrioQueue = (struct ... end : PRIOQUEUE);;
115
</PRE><P>An alternate syntax is provided for the above:
116
</P><PRE CLASS="verbatim">module PrioQueue : PRIOQUEUE = struct ... end;;
117
</PRE><H2 CLASS="section"><A NAME="htoc15">2.3</A>��Functors</H2><P>Functors are “functions” from structures to structures. They are used to
139
118
express parameterized structures: a structure <I>A</I> parameterized by a
140
119
structure <I>B</I> is simply a functor <I>F</I> with a formal parameter
141
120
<I>B</I> (along with the expected signature for <I>B</I>) which returns
142
121
the actual structure <I>A</I> itself. The functor <I>F</I> can then be
143
applied to one or several implementations <I>B</I><SUB>1</SUB> ...<I>B<SUB>n</SUB></I>
122
applied to one or several implementations <I>B</I><SUB>1</SUB> …<I>B<SUB>n</SUB></I>
144
123
of <I>B</I>, yielding the corresponding structures
145
<I>A</I><SUB>1</SUB> ...<I>A<SUB>n</SUB></I>.<BR>
147
For instance, here is a structure implementing sets as sorted lists,
124
<I>A</I><SUB>1</SUB> …<I>A<SUB>n</SUB></I>.</P><P>For instance, here is a structure implementing sets as sorted lists,
148
125
parameterized by a structure providing the type of the set elements
149
126
and an ordering function over this type (used to keep the sets
151
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>type comparison = Less | Equal | Greater;;
128
</P><PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>type comparison = Less | Equal | Greater;;
152
129
</FONT><FONT COLOR=maroon>type comparison = Less | Equal | Greater
154
131
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module type ORDERED_TYPE =
157
134
val compare: t -> t -> comparison
159
136
</FONT>module type ORDERED_TYPE = sig type t val compare : t -> t -> comparison end
161
138
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module Set =
162
139
functor (Elt: ORDERED_TYPE) ->
210
187
val add : OrderedString.t -> OrderedString.t list -> OrderedString.t list
211
188
val member : OrderedString.t -> OrderedString.t list -> bool
214
191
<FONT COLOR=black>#</FONT><FONT COLOR=blue>StringSet.member "bar" (StringSet.add "foo" StringSet.empty);;
215
192
</FONT>- : bool = false
218
<H2 CLASS="section"><A NAME="htoc16">2.4</A> Functors and type abstraction</H2>
220
As in the <TT>PrioQueue</TT> example, it would be good style to hide the
193
</FONT></PRE><H2 CLASS="section"><A NAME="htoc16">2.4</A>��Functors and type abstraction</H2><P>As in the <TT>PrioQueue</TT> example, it would be good style to hide the
221
194
actual implementation of the type <TT>set</TT>, so that users of the
222
195
structure will not rely on sets being lists, and we can switch later
223
196
to another, more efficient representation of sets without breaking
224
197
their code. This can be achieved by restricting <TT>Set</TT> by a suitable
225
198
functor signature:
226
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module type SETFUNCTOR =
199
</P><PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module type SETFUNCTOR =
227
200
functor (Elt: ORDERED_TYPE) ->
229
202
type element = Elt.t (* concrete *)
317
289
val add : element -> set -> set
318
290
val member : element -> set -> bool
321
As in the case of simple structures, an alternate syntax is provided
292
</FONT></PRE><P>As in the case of simple structures, an alternate syntax is provided
322
293
for defining functors and restricting their result:
323
<PRE CLASS="verbatim">
324
module AbstractSet(Elt: ORDERED_TYPE) : (SET with type element = Elt.t) =
294
</P><PRE CLASS="verbatim">module AbstractSet(Elt: ORDERED_TYPE) : (SET with type element = Elt.t) =
327
Abstracting a type component in a functor result is a powerful
296
</PRE><P>Abstracting a type component in a functor result is a powerful
328
297
technique that provides a high degree of type safety, as we now
329
298
illustrate. Consider an ordering over character strings that is
330
299
different from the standard ordering implemented in the
331
300
<TT>OrderedString</TT> structure. For instance, we compare strings without
332
301
distinguishing upper and lower case.
333
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module NoCaseString =
302
</P><PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module NoCaseString =
336
305
let compare s1 s2 =
364
333
standard ordering and for the case-insensitive ordering). Applying
365
334
operations from <TT>AbstractStringSet</TT> to values of type
366
335
<TT>NoCaseStringSet.set</TT> could give incorrect results, or build
367
lists that violate the invariants of <TT>NoCaseStringSet</TT>.<BR>
370
<H2 CLASS="section"><A NAME="htoc17">2.5</A> Modules and separate compilation</H2>
372
All examples of modules so far have been given in the context of the
336
lists that violate the invariants of <TT>NoCaseStringSet</TT>.</P><H2 CLASS="section"><A NAME="htoc17">2.5</A>��Modules and separate compilation</H2><P>All examples of modules so far have been given in the context of the
373
337
interactive system. However, modules are most useful for large,
374
338
batch-compiled programs. For these programs, it is a practical
375
339
necessity to split the source into several files, called compilation
376
340
units, that can be compiled separately, thus minimizing recompilation
379
In Objective Caml, compilation units are special cases of structures
341
after changes.</P><P>In Objective Caml, compilation units are special cases of structures
380
342
and signatures, and the relationship between the units can be
381
343
explained easily in terms of the module system. A compilation unit <I>A</I>
382
344
comprises two files:
383
<UL CLASS="itemize"><LI CLASS="li-itemize">
345
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
384
346
the implementation file <I>A</I><TT>.ml</TT>, which contains a sequence
385
of definitions, analogous to the inside of a <TT>struct</TT>...<TT>end</TT>
347
of definitions, analogous to the inside of a <TT>struct</TT>…<TT>end</TT>
387
<LI CLASS="li-itemize">the interface file <I>A</I><TT>.mli</TT>, which contains a sequence of
388
specifications, analogous to the inside of a <TT>sig</TT>...<TT>end</TT>
349
</LI><LI CLASS="li-itemize">the interface file <I>A</I><TT>.mli</TT>, which contains a sequence of
350
specifications, analogous to the inside of a <TT>sig</TT>…<TT>end</TT>
391
353
Both files define a structure named <I>A</I> as if
392
354
the following definition was entered at top-level:
394
356
module <I>A</I>: sig (* contents of file <I>A</I>.mli *) end
395
357
= struct (* contents of file <I>A</I>.ml *) end;;
397
359
The files defining the compilation units can be compiled separately
398
using the <TT>ocamlc -c</TT> command (the <TT>-c</TT> option means “compile only, do
399
not try to link”); this produces compiled interface files (with
360
using the <TT>ocamlc -c</TT> command (the <TT>-c</TT> option means “compile only, do
361
not try to link”); this produces compiled interface files (with
400
362
extension <TT>.cmi</TT>) and compiled object code files (with extension
401
363
<TT>.cmo</TT>). When all units have been compiled, their <TT>.cmo</TT> files are
402
364
linked together using the <TT>ocaml</TT> command. For instance, the following
403
365
commands compile and link a program composed of two compilation units
404
366
<TT>Aux</TT> and <TT>Main</TT>:
405
<PRE CLASS="verbatim">
406
$ ocamlc -c Aux.mli # produces aux.cmi
367
</P><PRE CLASS="verbatim">$ ocamlc -c Aux.mli # produces aux.cmi
407
368
$ ocamlc -c Aux.ml # produces aux.cmo
408
369
$ ocamlc -c Main.mli # produces main.cmi
409
370
$ ocamlc -c Main.ml # produces main.cmo
410
371
$ ocamlc -o theprogram Aux.cmo Main.cmo
411
</PRE>The program behaves exactly as if the following phrases were entered
372
</PRE><P>The program behaves exactly as if the following phrases were entered
414
375
module Aux: sig (* contents of Aux.mli *) end
415
376
= struct (* contents of Aux.ml *) end;;
416
377
module Main: sig (* contents of Main.mli *) end
417
378
= struct (* contents of Main.ml *) end;;
419
380
In particular, <TT>Main</TT> can refer to <TT>Aux</TT>: the definitions and
420
381
declarations contained in <TT>Main.ml</TT> and <TT>Main.mli</TT> can refer to
421
382
definition in <TT>Aux.ml</TT>, using the <TT>Aux.</TT><I>ident</I> notation, provided
422
these definitions are exported in <TT>Aux.mli</TT>.<BR>
424
The order in which the <TT>.cmo</TT> files are given to <TT>ocaml</TT> during the
383
these definitions are exported in <TT>Aux.mli</TT>.</P><P>The order in which the <TT>.cmo</TT> files are given to <TT>ocaml</TT> during the
425
384
linking phase determines the order in which the module definitions
426
385
occur. Hence, in the example above, <TT>Aux</TT> appears first and <TT>Main</TT> can
427
refer to it, but <TT>Aux</TT> cannot refer to <TT>Main</TT>.<BR>
429
Notice that only top-level structures can be mapped to
386
refer to it, but <TT>Aux</TT> cannot refer to <TT>Main</TT>.</P><P>Notice that only top-level structures can be mapped to
430
387
separately-compiled files, but not functors nor module types.
431
388
However, all module-class objects can appear as components of a
432
389
structure, so the solution is to put the functor or module type
433
390
inside a structure, which can then be mapped to a file.
438
<A HREF="manual003.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
439
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
440
<A HREF="manual005.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
393
<A HREF="manual003.html"><IMG SRC="previous_motif.gif" ALT="Previous"></A>
394
<A HREF="index.html"><IMG SRC="contents_motif.gif" ALT="Up"></A>
395
<A HREF="manual005.html"><IMG SRC="next_motif.gif" ALT="Next"></A>
added
removed
ocaml.html/manual004.html
