1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="manual.css">
<TITLE>
The module system
</TITLE>
</HEAD>
<BODY >
<A HREF="manual003.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="manual005.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>
<H1 CLASS="chapter"><A NAME="htoc12">Chapter 2</A> The module system</H1> <A NAME="c:moduleexamples"></A>
This chapter introduces the module system of Objective Caml.<BR>
<BR>
<H2 CLASS="section"><A NAME="htoc13">2.1</A> Structures</H2>
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 <EM>structure</EM> and
is introduced by the <TT>struct</TT>...<TT>end</TT> construct, which contains an
arbitrary sequence of definitions. The structure is usually given a
name with the <TT>module</TT> binding. Here is for instance a structure
packaging together a type of priority queues and their operations:
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>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;;
</FONT><FONT COLOR=maroon>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
</FONT></PRE>
Outside the structure, its components can be referred to using the
“dot notation”, that is, identifiers qualified by a structure name.
For instance, <TT>PrioQueue.insert</TT> in a value context is
the function <TT>insert</TT> defined inside the structure
<TT>PrioQueue</TT>. Similarly, <TT>PrioQueue.queue</TT> in a type context is the
type <TT>queue</TT> defined in <TT>PrioQueue</TT>.
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>PrioQueue.insert PrioQueue.empty 1 "hello";;
</FONT><FONT COLOR=maroon>- : string PrioQueue.queue =
PrioQueue.Node (1, "hello", PrioQueue.Empty, PrioQueue.Empty)
</FONT></PRE>
<H2 CLASS="section"><A NAME="htoc14">2.2</A> Signatures</H2>
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 <TT>empty</TT>, <TT>insert</TT> and <TT>extract</TT>, but not the
auxiliary function <TT>remove_top</TT>. Similarly, it makes the <TT>queue</TT> type
abstract (by not providing its actual representation as a concrete type).
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>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;;
</FONT><FONT COLOR=maroon>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
</FONT></PRE>
Restricting the <TT>PrioQueue</TT> structure by this signature results in
another view of the <TT>PrioQueue</TT> structure where the <TT>remove_top</TT>
function is not accessible and the actual representation of priority
queues is hidden:
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module AbstractPrioQueue = (PrioQueue : PRIOQUEUE);;
</FONT><FONT COLOR=maroon>module AbstractPrioQueue : PRIOQUEUE
<FONT COLOR=black>#</FONT><FONT COLOR=blue><U>AbstractPrioQueue.remove_top</U>;;
</FONT>Unbound value AbstractPrioQueue.remove_top
<FONT COLOR=black>#</FONT><FONT COLOR=blue>AbstractPrioQueue.insert AbstractPrioQueue.empty 1 "hello";;
</FONT>- : string AbstractPrioQueue.queue = <abstr>
</FONT></PRE>
The restriction can also be performed during the definition of the
structure, as in
<PRE CLASS="verbatim">
module PrioQueue = (struct ... end : PRIOQUEUE);;
</PRE>An alternate syntax is provided for the above:
<PRE CLASS="verbatim">
module PrioQueue : PRIOQUEUE = struct ... end;;
</PRE>
<H2 CLASS="section"><A NAME="htoc15">2.3</A> Functors</H2>
Functors are “functions” from structures to structures. They are used to
express parameterized structures: a structure <I>A</I> parameterized by a
structure <I>B</I> is simply a functor <I>F</I> with a formal parameter
<I>B</I> (along with the expected signature for <I>B</I>) which returns
the actual structure <I>A</I> itself. The functor <I>F</I> can then be
applied to one or several implementations <I>B</I><SUB>1</SUB> ...<I>B<SUB>n</SUB></I>
of <I>B</I>, yielding the corresponding structures
<I>A</I><SUB>1</SUB> ...<I>A<SUB>n</SUB></I>.<BR>
<BR>
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):
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>type comparison = Less | Equal | Greater;;
</FONT><FONT COLOR=maroon>type comparison = Less | Equal | Greater
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module type ORDERED_TYPE =
sig
type t
val compare: t -> t -> comparison
end;;
</FONT>module type ORDERED_TYPE = sig type t val compare : t -> t -> comparison end
<FONT COLOR=black>#</FONT><FONT COLOR=blue>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;;
</FONT>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
</FONT></PRE>
By applying the <TT>Set</TT> functor to a structure implementing an ordered
type, we obtain set operations for this type:
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module OrderedString =
struct
type t = string
let compare x y = if x = y then Equal else if x < y then Less else Greater
end;;
</FONT><FONT COLOR=maroon>module OrderedString :
sig type t = string val compare : 'a -> 'a -> comparison end
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module StringSet = Set(OrderedString);;
</FONT>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
<FONT COLOR=black>#</FONT><FONT COLOR=blue>StringSet.member "bar" (StringSet.add "foo" StringSet.empty);;
</FONT>- : bool = false
</FONT></PRE>
<H2 CLASS="section"><A NAME="htoc16">2.4</A> Functors and type abstraction</H2>
As in the <TT>PrioQueue</TT> example, it would be good style to hide the
actual implementation of the type <TT>set</TT>, 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 <TT>Set</TT> by a suitable
functor signature:
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>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;;
</FONT><FONT COLOR=maroon>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
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module AbstractSet = (Set : SETFUNCTOR);;
</FONT>module AbstractSet : SETFUNCTOR
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module AbstractStringSet = AbstractSet(OrderedString);;
</FONT>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
<FONT COLOR=black>#</FONT><FONT COLOR=blue>AbstractStringSet.add "gee" AbstractStringSet.empty;;
</FONT>- : AbstractStringSet.set = <abstr>
</FONT></PRE>
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:
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module type SET =
sig
type element
type set
val empty : set
val add : element -> set -> set
val member : element -> set -> bool
end;;
</FONT><FONT COLOR=maroon>module type SET =
sig
type element
type set
val empty : set
val add : element -> set -> set
val member : element -> set -> bool
end
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module WrongSet = (Set : functor(Elt: ORDERED_TYPE) -> SET);;
</FONT>module WrongSet : functor (Elt : ORDERED_TYPE) -> SET
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module WrongStringSet = WrongSet(OrderedString);;
</FONT>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
<FONT COLOR=black>#</FONT><FONT COLOR=blue>WrongStringSet.add <U>"gee"</U> WrongStringSet.empty;;
</FONT>This expression has type string but is here used with type
WrongStringSet.element = WrongSet(OrderedString).element
</FONT></PRE>
The problem here is that <TT>SET</TT> specifies the type <TT>element</TT>
abstractly, so that the type equality between <TT>element</TT> in the result
of the functor and <TT>t</TT> in its argument is forgotten. Consequently,
<TT>WrongStringSet.element</TT> is not the same type as <TT>string</TT>, and the
operations of <TT>WrongStringSet</TT> cannot be applied to strings.
As demonstrated above, it is important that the type <TT>element</TT> in the
signature <TT>SET</TT> be declared equal to <TT>Elt.t</TT>; unfortunately, this is
impossible above since <TT>SET</TT> is defined in a context where <TT>Elt</TT> does
not exist. To overcome this difficulty, Objective Caml provides a
<TT>with type</TT> construct over signatures that allows to enrich a signature
with extra type equalities:
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module AbstractSet =
(Set : functor(Elt: ORDERED_TYPE) -> (SET with type element = Elt.t));;
</FONT><FONT COLOR=maroon>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
</FONT></PRE>
As in the case of simple structures, an alternate syntax is provided
for defining functors and restricting their result:
<PRE CLASS="verbatim">
module AbstractSet(Elt: ORDERED_TYPE) : (SET with type element = Elt.t) =
struct ... end;;
</PRE>
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
<TT>OrderedString</TT> structure. For instance, we compare strings without
distinguishing upper and lower case.
<PRE><FONT COLOR=black>#</FONT><FONT COLOR=blue>module NoCaseString =
struct
type t = string
let compare s1 s2 =
OrderedString.compare (String.lowercase s1) (String.lowercase s2)
end;;
</FONT><FONT COLOR=maroon>module NoCaseString :
sig type t = string val compare : string -> string -> comparison end
<FONT COLOR=black>#</FONT><FONT COLOR=blue>module NoCaseStringSet = AbstractSet(NoCaseString);;
</FONT>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
<FONT COLOR=black>#</FONT><FONT COLOR=blue>NoCaseStringSet.add "FOO" <U>AbstractStringSet.empty</U>;;
</FONT>This expression has type
AbstractStringSet.set = AbstractSet(OrderedString).set
but is here used with type
NoCaseStringSet.set = AbstractSet(NoCaseString).set
</FONT></PRE>
Notice that the two types <TT>AbstractStringSet.set</TT> and
<TT>NoCaseStringSet.set</TT> are not compatible, and values of these
two types do not match. This is the correct behavior: even though both
set types contain elements of the same type (strings), both are built
upon different orderings of that type, and different invariants need
to be maintained by the operations (being strictly increasing for the
standard ordering and for the case-insensitive ordering). Applying
operations from <TT>AbstractStringSet</TT> to values of type
<TT>NoCaseStringSet.set</TT> could give incorrect results, or build
lists that violate the invariants of <TT>NoCaseStringSet</TT>.<BR>
<BR>
<H2 CLASS="section"><A NAME="htoc17">2.5</A> Modules and separate compilation</H2>
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.<BR>
<BR>
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 <I>A</I>
comprises two files:
<UL CLASS="itemize"><LI CLASS="li-itemize">
the implementation file <I>A</I><TT>.ml</TT>, which contains a sequence
of definitions, analogous to the inside of a <TT>struct</TT>...<TT>end</TT>
construct;
<LI CLASS="li-itemize">the interface file <I>A</I><TT>.mli</TT>, which contains a sequence of
specifications, analogous to the inside of a <TT>sig</TT>...<TT>end</TT>
construct.
</UL>
Both files define a structure named <I>A</I> as if
the following definition was entered at top-level:
<PRE>
module <I>A</I>: sig (* contents of file <I>A</I>.mli *) end
= struct (* contents of file <I>A</I>.ml *) end;;
</PRE>
The files defining the compilation units can be compiled separately
using the <TT>ocamlc -c</TT> command (the <TT>-c</TT> option means “compile only, do
not try to link”); this produces compiled interface files (with
extension <TT>.cmi</TT>) and compiled object code files (with extension
<TT>.cmo</TT>). When all units have been compiled, their <TT>.cmo</TT> files are
linked together using the <TT>ocaml</TT> command. For instance, the following
commands compile and link a program composed of two compilation units
<TT>Aux</TT> and <TT>Main</TT>:
<PRE CLASS="verbatim">
$ 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
</PRE>The program behaves exactly as if the following phrases were entered
at top-level:
<PRE>
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;;
</PRE>
In particular, <TT>Main</TT> can refer to <TT>Aux</TT>: the definitions and
declarations contained in <TT>Main.ml</TT> and <TT>Main.mli</TT> can refer to
definition in <TT>Aux.ml</TT>, using the <TT>Aux.</TT><I>ident</I> notation, provided
these definitions are exported in <TT>Aux.mli</TT>.<BR>
<BR>
The order in which the <TT>.cmo</TT> files are given to <TT>ocaml</TT> during the
linking phase determines the order in which the module definitions
occur. Hence, in the example above, <TT>Aux</TT> appears first and <TT>Main</TT> can
refer to it, but <TT>Aux</TT> cannot refer to <TT>Main</TT>.<BR>
<BR>
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.
<BR>
<BR>
<HR>
<A HREF="manual003.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="manual005.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
|
