Simon
[haskell-report.git] / report / modules.verb
1 %
2 % $Header: /home/cvs/root/haskell-report/report/modules.verb,v 1.10 2001/09/11 13:04:28 simonpj Exp $
3 %
4 %**<title>The Haskell 98 Report: Modules</title>
5 %*section 5
6 %**~header
7 \section{Modules} 
8 \label{modules} 
9 \index{module}
10
11 A module defines a collection of values, datatypes, type synonyms,
12 classes, etc.~(see Section~\ref{declarations}) in an environment created
13 by a set of {\em imports}, resources brought into scope from other modules, 
14 and {\em exports} some of these resources, making them available to
15 other modules.  
16 We use the term {\em entity}\index{entity} to refer to
17 a value, type, or class defined in, imported into, or perhaps
18 exported from a module.
19
20 A \Haskell{} {\em program} is a collection of modules, one of
21 which, by convention, must be called @Main@\indexmodule{Main} and must
22 export the value @main@\indextt{main}.  The {\em value} of the program
23 is the value of the identifier @main@ in module @Main@,
24 which must be a computation of type $@IO@~\tau$ for some type $\tau$
25 (see Section~\ref{io}).  When the program is executed, the computation
26 @main@ is performed, and its result (of type $\tau$) is discarded.
27
28 Modules may reference other modules via explicit
29 @import@ declarations, each giving the name of a module to be
30 imported and specifying its entities to be imported.
31 Modules may be mutually recursive.
32
33 Modules are used for name-space control, and are not first class values.
34 A multi-module Haskell program can be converted into a single-module
35 program by giving each entity a unique name, changing all occurrences
36 to refer to the appropriate unique name, and then concatenating all the module
37 bodies\footnote{There are two minor exceptions to this statement.
38 First, @default@ declarations scope over a single module (Section~\ref{default-decls}).
39 Second, Rule 2 of the monomorphism restriction (Section~\ref{sect:monomorphism-restriction})
40 is affected by module boundaries.
41 }.  
42 For example, here is a three-module program:
43 \bprog
44 @
45   module Main where
46     import A
47     import B
48     main = A.f >> B.f
49
50   module A where
51     f = ...
52
53   module B where
54     f = ...
55 @
56 \eprog
57 It is equivalent to the following single-module program:
58 \bprog
59 @
60   module Main where
61     main = af >> bf
62
63     af = ...
64
65     bf = ...
66 @
67 \eprog
68 Because they are allowed to be mutually recursive,
69 modules allow a program to be partitioned freely without regard to
70 dependencies.
71
72 The name-space for modules themselves is flat, with each module being associated
73 with a unique module name (which are \Haskell{} identifiers
74 beginning with a capital letter; i.e.~"modid").  
75 There is one distinguished module, @Prelude@, which is imported into
76 all modules by default (see Section~\ref{standard-prelude}), plus a
77 set of standard library modules that may be imported as required
78 (see the \Haskell{} Library Report\cite{libraries}).
79
80 \subsection{Module Structure} 
81 \label{module-implementations}
82
83 A module defines a mutually
84 recursive scope containing declarations for value bindings, data
85 types, type synonyms, classes, etc. (see Section~\ref{declarations}).
86
87 @@@
88 module -> @module@ modid [exports] @where@ body
89        |  body
90 body   -> @{@ impdecls @;@ topdecls @}@
91         | @{@ impdecls  @}@
92         | @{@ topdecls @}@
93
94 modid        -> conid
95 impdecls     -> impdecl_1 @;@ ... @;@ impdecl_n         & \qquad (n>=1)
96 topdecls     -> topdecl_1 @;@ ... @;@ topdecl_n         & \qquad (n>=1)
97 @@@
98
99 \indexsyn{module}%
100 \indexsyn{body}%
101 \indexsyn{modid}%
102 \indexsyn{impdecls}%
103 \indexsyn{topdecls}%
104
105 A module 
106 begins with a header: the keyword
107 @module@, the module name, and a list of entities (enclosed in round
108 parentheses) to be exported.  The header is followed by a possibly-empty
109 list of @import@ declarations ("impdecls", Section~\ref{import}) that specify modules to be imported,
110 optionally restricting the imported bindings.  
111 This is followed by a possibly-empty list of top-level declarations ("topdecls", Section~\ref{declarations}).  
112
113 An abbreviated form of module, consisting only 
114 of\index{abbreviated module}
115 the module body, is permitted.  If this is used, the header is assumed to be
116 `@module Main(main) where@'.
117 If the first lexeme in the
118 abbreviated module is not a @{@, then the layout rule applies
119 for the top level of the module.
120
121 \subsection{Export Lists}
122 \label{export}
123 \index{export list}
124
125 @@@
126 exports  -> @(@ export_1 @,@ ... @,@ export_n [ @,@ ] @)@ & \qquad (n>=0)
127
128 export   -> qvar
129          |  qtycon [@(..)@ | @(@ qcname_1 @,@ ... @,@ qcname_n @)@] & \qquad (n>=0)
130          |  qtycls [@(..)@ | @(@ qvar_1 @,@ ... @,@ qvar_n @)@] & \qquad (n>=0)
131          |  @module@ modid
132
133 qcname   -> qvar | qcon
134 @@@
135 \indexsyn{exports}%
136 \indexsyn{export}%
137 \indexsyn{qcname}%
138
139 An {\em export list} identifies the entities to be exported by a
140 module declaration.  A module implementation may only export an entity
141 that it declares, or that it imports from some other module.  If the
142 export list is omitted, all values, types and classes defined in the
143 module are exported, {\em but not those that are imported}.
144
145 Entities in an export list may be named as follows:
146 \begin{enumerate}
147 \item
148 A value, field name, or class method, whether declared in
149 the module body or imported,
150 may be named by giving the name of the value as a "qvarid".
151 Operators should be enclosed in parentheses to turn them into
152 "qvarid"'s.  
153
154 \item
155 An algebraic datatype "T"
156 \index{algebraic datatype}
157 declared by a @data@ or @newtype@ declaration may be named in one of
158 three ways: 
159 \begin{itemize}
160 \item
161 The form "T" names the type {\em but not the constructors or field names}.
162 The ability to export a type without its constructors allows the
163 construction of abstract datatypes (see Section~\ref{abstract-types}).
164 \item
165 The form $T@(@qcname_1@,@\ldots@,@qcname_n@)@$, where the $qcname_i$
166 name only constructors and field names in $T$, 
167 names the type and some or all of its constructors and field names.  
168 The $qcname_i$ must not contain duplications.  
169 \item
170 The abbreviated form "T@(..)@" names the type 
171 and all its constructors and field names that are currently in scope
172 (whether qualified or not).
173 \end{itemize}
174 Data constructors cannot be named in export lists in any other way.
175
176 \item
177 A type synonym "T" declared by a
178 @type@ declaration may be named by the form "T".
179 \index{type synonym}
180
181 \item
182 \index{class declaration}
183 A class $C$ with operations $f_1,\ldots,f_n$
184 declared in a @class@ declaration may be named in one of three ways:
185 \begin{itemize}
186 \item
187 The form "C" names the class {\em but not the class methods}.
188 \item
189 The form $C@(@f_1@,@\ldots@,@f_n@)@$, where
190 the $f_i$ must be class methods of $C$, names the class and some or all
191 of its methods.  The $f_i$ must not contain duplications.
192 \item
193 The abbreviated form $C@(..)@$ names the class and all its methods
194 that are in scope (whether qualified or not).
195 \end{itemize}
196
197 \item
198 The form `"@module@ M"' abbreviates the set of all entities whose
199 names are brought into scope by one or more {\em unqualified} @import@ declarations
200 of the form `"@import@~M~[impspec]"' or `"@import@~A~@as@~M~[impspec]"'.  This set may be empty.
201 For example:
202 \bprog
203 @
204       module Queue( module Stack, enqueue, dequeue ) where
205           import Stack
206           ...
207 @
208 \eprog
209 Here the module @Queue@ uses the module name @Stack@ in its export
210 list to abbreviate all the entities imported from @Stack@.  
211 \item
212 Additionally, a module can name its own local definitions in its export
213 list using its name in the `"@module@" m' syntax.  For example:
214 \bprog
215 @
216  module Mod1(module Mod1, module Mod2) where
217  import Mod2
218  import Mod3
219 @
220 \eprog
221 Here module @Mod1@ exports all local definitions as well as those
222 imported from @Mod2@ but not those imported from @Mod3@.  Note that
223 @module M where@ is the same as using @module M(module M) where@.
224 \end{enumerate}
225 It is an error to use "@module@~M" in an export list unless $M$ is the
226 module bearing the export list, or $M$ is imported
227 by at least one @import@ declaration (qualified or unqualified).
228
229 It makes no difference to an importing module how an entity was 
230 exported.  For example, a field name @f@ from data type @T@ may be exported individually
231 (@f@, item (1) above); or as an explicitly-named member of its data type (@T(f)@, item (2));
232 or as an implicitly-named member (@T(..)@, item(2)); or by exporting an entire
233 module (@module M@, item (5) or (6)).  
234
235 The {\em unqualified} names of the entities exported by a module must all be distinct
236 (within their respective namespace).  For example
237 \bprog
238 @
239   module A ( B.f, C.f, g ) where   -- an invalid module
240   import qualified B(f,g)
241   import qualified C(f)
242   g = True
243 @
244 \eprog
245 There are name clashes in the export list between @B.f@ and @C.f@ and
246 between @g@ and @B.g@ even though there are no name clashes within
247 module @A@.  
248
249
250 \subsection{Import Declarations}
251 \label{import}
252 \index{import declaration}
253
254 @@@
255 impdecl   -> @import@ [@qualified@] modid [@as@ modid] [impspec]
256           |     & (empty declaration)
257 impspec   -> @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & \qquad (n>=0)
258              |  @hiding@ @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & \qquad (n>=0)
259
260 import    -> var
261           |  tycon [ @(..)@ | @(@ cname_1 @,@ ... @,@ cname_n @)@] & \qquad (n>=1)
262           |  tycls [@(..)@ | @(@ var_1 @,@ ... @,@ var_n @)@] & \qquad (n>=0)
263 cname     -> var | con
264 @@@
265 %             var
266 %          |  tycon
267 %          |  tycon @(..)@
268 %          |  tycon @(@ con_1 @,@ ... @,@ con_n@)@ & \qquad (n>=1)
269 %          |  tycls @(..)@
270 %          |  tycls @(@ var_1 @,@ ... @,@ var_n@)@ & \qquad (n>=0)
271 \indexsyn{impdecl}%
272 \indexsyn{impspec}%
273 \indexsyn{import}%
274 \indexsyn{cname}%
275
276 The entities exported by a module may be brought into scope in
277 another module with
278 an @import@
279 declaration at the beginning
280 of the module.  
281 The @import@ declaration names the module to be
282 imported
283 and optionally specifies the entities to be imported.
284 A single module may be imported by more than one @import@ declaration.  
285 Imported names serve as top level declarations: they scope over
286 the entire body of the module but may  be shadowed by local
287 non-top-level bindings.  
288
289 The effect of multiple @import@ declarations is strictly
290 cumulative: an entity is in scope if it is imported by any of the @import@
291 declarations in a module.  The ordering of import declarations is irrelevant.
292
293 \subsubsection{What is imported}
294 \label{whatisimported}
295
296 Exactly which entities are to be imported can be specified in one
297 of the following three ways:\nopagebreak[4]
298 \begin{enumerate}
299 \item
300 The imported entities can be specified explicitly
301 by listing them in parentheses.
302 Items in the list have the same form as those in export lists, except
303 qualifiers are not permitted and
304 the `@module@ "modid"' entity is not permitted.  When the @(..)@ form
305 of import is used for a type or class, the @(..)@ refers to all of the
306 constructors, methods, or field names exported from the module.
307
308 The list must name only
309 entities exported by the imported module.
310 The list may be empty, in which case nothing except the instances is
311 imported.
312
313 \item
314 Entities can be excluded by 
315 using the form @hiding(@"import_1 @,@ ... @,@ import_n"
316 @)@,\index{hiding} which
317 specifies that all entities exported by the named module should
318 be imported except for those named in the list.  Data constructors may be
319 named directly in hiding lists without being prefixed by the
320 associated type.  Thus, in
321 \bprog
322 @
323   import M hiding (C)
324 @
325 \eprog
326 any constructor, class, or type named @C@ is excluded.  In contrast,
327 using @C@ in an import list names only a class or type.  
328
329 It is not an error to hide an entity that is not, in fact, exported by
330 the imported module, although compilers are encouraged to flag a warning in this case.
331
332 \item
333 Finally, if "impspec" is omitted then 
334 all the entities exported by the specified module are imported.
335 \end{enumerate}
336
337 \subsubsection{Qualified import}
338 \index{qualified name}
339
340 For each entity imported under the rules of Section~\ref{whatisimported},
341 the top-level environment is extended.  If the import declaration used
342 the @qualified@ keyword, only the {\em qualified name} of the entity is
343 brought into scope.  If the @qualified@ keyword is omitted, then {\em both} the
344 qualified {\em and} unqualified name of the entity is brought into scope.
345 Section~\ref{qualifiers} describes qualified names in more detail.
346
347 The qualifier on the imported name is either the name of the imported module,
348 or the local alias given in the @as@ clause (Section~\ref{as-clause}) 
349 on the @import@ statement.
350 Hence, {\em the qualifier is not necessarily the name of the module in which the
351 entity was originally declared}.
352
353 The ability to exclude the unqualified names allows full programmer control of
354 the unqualified namespace: a locally defined entity can share the same
355 name as a qualified import:
356 \bprog
357 @
358   module Ring where
359   import qualified Prelude  -- All Prelude names must be qualified
360   import List( nub )
361
362   l1 + l2 = l1 ++ l2        -- This + differs from the one in the Prelude
363   l1 * l2 = nub (l1 + l2)   -- This * differs from the one in the Prelude
364
365   succ = (Prelude.+ 1)
366 @
367 \eprog
368
369
370 \subsubsection{Local aliases}
371 \label{as-clause}
372
373 Imported modules may be assigned a local alias in the importing module
374 using the @as@ clause.
375 For example, in
376 \bprog
377 @
378   import qualified VeryLongModuleName as C
379 @
380 \eprog
381 entities must be referenced using `@C.@' as a qualifier instead of
382 `@VeryLongModuleName.@'.  This also allows a different module to be substituted
383 for @VeryLongModuleName@ without changing the qualifiers used for the imported module.
384 It is legal for more than one module in scope to 
385 use the same qualifier, provided that all names can still be resolved unambiguously.
386 For example:
387 \bprog
388 @
389   module M where
390     import qualified Foo as A
391     import qualified Baz as A
392     x = A.f
393 @
394 \eprog
395 This module is legal provided only that @Foo@ and @Baz@ do not both export @f@.
396
397 An @as@ clause may also be used on an un-@qualified@ @import@ statement:
398 \bprog
399 @
400   import Foo as A(f)
401 @
402 \eprog
403 This declaration brings into scope @f@ and @A.f@.
404
405
406 \subsubsection{Examples}
407
408 To clarify the above import rules, suppose the module @A@ exports @x@ and @y@.
409 Then this table shows what names are brought into scope by the specified import statement:
410 \begin{center}
411 \begin{tabular}{|ll|}
412 \hline
413 Import declaration & Names brought into scope \\
414 \hline
415   @import A@                    & @x@, @y@, @A.x@, @A.y@ \\
416   @import A()@                  & (nothing)     \\
417   @import A(x)@                 & @x@, @A.x@ \\
418   @import qualified A@          & @A.x@, @A.y@ \\
419   @import qualified A()@        & (nothing) \\
420   @import qualified A(x)@       & @A.x@ \\
421   @import A hiding ()@          & @x@, @y@, @A.x@, @A.y@ \\
422   @import A hiding (x)@         & @y@, @A.y@ \\
423   @import qualified A hiding ()@        & @A.x@, @A.y@ \\
424   @import qualified A hiding (x)@       & @A.y@ \\
425   @import A as B@               & @x@, @y@, @B.x@, @B.y@ \\
426   @import A as B(x)@            & @B.x@ \\
427   @import qualified A as B@     & @B.x@, @B.y@ \\
428 \hline
429 \end{tabular}
430 \end{center}
431 In all cases, all instance declarations in scope in module @A@ are imported
432 (Section~\ref{import-instances}).
433
434 \subsection{Importing and Exporting Instance Declarations}
435 \label{import-instances}
436 \index{instance declaration!importing and exporting}
437
438 Instance declarations cannot be explicitly named on import or export
439 lists.  All instances in scope within a module are {\em always}
440 exported and any import brings {\em all} instances in from the
441 imported module.  Thus, an
442 instance declaration is in scope if and only if a chain of @import@
443 declarations leads to the module containing the instance declaration.
444
445 For example, @import M()@ does not bring
446 any new names in scope from module @M@, but does bring in any instances
447 visible in @M@.  A module whose only purpose is to provide instance
448 declarations can have an empty export list.  For example
449 \bprog
450 @
451   module MyInstances() where
452     instance Show (a -> b) where
453         show fn = "<<function>>"
454     instance Show (IO a) where
455         show io = "<<IO action>>"
456 @
457 \eprog
458
459 \subsection{Name Clashes and Closure}
460
461 \subsubsection{Qualified names}\index{qualified name}
462 \label{qualifiers}
463
464 A {\em qualified name} is written as "modid"@.@"name" (Section~\ref{ids}).
465
466 A qualified name is brought into scope:
467 \begin{itemize}
468 \item {\em By a top level declaration.}
469 A top-level declaration brings into scope both the unqualified {\em and}
470 the qualified name of the entity being defined.  Thus:
471 \bprog
472 @
473   module M where
474     f x = ...
475     g x = M.f x x
476 @
477 \eprog
478 is legal.  The {\em defining} occurrence must mention the {\em unqualified} name; therefore, it is
479 illegal to write
480 \bprog
481 @
482   module M where
483     M.f x = ...                 -- ILLEGAL
484     g x = let M.y = x+1 in ...  -- ILLEGAL
485 @
486 \eprog
487 \item {\em By an @import@ declaration.}  An @import@ declaration, whether @qualified@ or not,
488 always brings into scope the qualified name of the imported entity (Section~\ref{import}).
489 \end{itemize}
490 Qualifiers may also be applied to
491 names imported by an unqualified import; this allows a qualified
492 import to be replaced with an unqualified one without forcing changes
493 in the references to the imported names.  
494
495
496 \subsubsection{Name clashes}
497
498 If a module contains a bound occurrence of a name, such as @f@ or @A.f@,
499 it must be possible unambiguously to resolve which entity is thereby referred to;
500 that is, there must be only one binding for @f@ or @A.f@ respectively.
501
502 It is {\em not} an error for there to exist names that cannot be so 
503 resolved, provided that the program does not mention those names.  For example:
504 \bprog
505 @
506   module A where
507     import B
508     import C
509     tup = (b, c, d, x)
510   
511   module B( d, b, x, y ) where
512     import D
513     x = ...
514     y = ...
515     b = ...
516   
517   module C( d, c, x, y ) where
518     import D
519     x = ...
520     y = ...
521     c = ...
522
523   module D( d ) where
524     d = ...
525 @
526 \eprog
527 Consider the definition of @tup@.  
528 \begin{itemize}
529 \item The references to @b@ and @c@
530 can be unambiguously resolved to @b@ declared in @B@, and @c@ declared in
531 @C@ respectively.  
532 \item The reference to @d@ is unambiguously resolved to
533 @d@ declared in @D@.  In this case the same entity is brought into scope by two routes
534 (the import of @B@ and the import of @C@), and can be referred to in @A@ by the names
535 @d@, @B.d@, and @C.d@.
536 \item The reference to @x@ is ambiguous: it could mean @x@ declared in @B@, or @x@ 
537 declared in @C@.  The ambiguity could be fixed by replacing the reference to @x@ by
538 @B.x@ or @C.x@.
539 \item There is no reference to @y@, so it is not erroneous that distinct entities called
540 @y@ are exported by both @B@ and @C@.  An error is only reported if @y@ is actually mentioned.
541 \end{itemize}
542
543 The name occurring in a type signature or fixity declarations is
544 always unqualified, and unambiguously refers to another declaration in
545 the same declaration list (except that the fixity declaration for a
546 class method can occur at top level --- Section~\ref{fixity}). For example,
547 the following module is legal:
548 \bprog
549 @
550   module F where
551
552     sin :: Float -> Float
553     sin x = (x::Float)
554
555     f x = Prelude.sin (F.sin x)
556 @
557 \eprog
558 The local declaration for @sin@ is
559 legal, even though the Prelude function @sin@ is implicitly in
560 scope. The references to @Prelude.sin@ and @F.sin@ must both be qualified
561 to make it unambigous which @sin@ is meant. However, the unqualified
562 name "@sin@" in the type signature in the first line of @F@ unambiguously
563 refers to the local declaration for @sin@.
564
565 \subsubsection{Closure}
566 \label{closure}
567 \index{closure}
568
569 Every module in a \Haskell{} program must be {\em closed}.  That is,
570 every name explicitly mentioned by the source code
571 must be either defined locally or imported from another module.
572 However, entities that the compiler requires for type checking or other
573 compile time analysis need not be imported if they are not mentioned
574 by name.  The \Haskell{} compilation system is responsible for finding
575 any information needed for compilation without the help of the
576 programmer.  That is, the import of a variable @x@ does not
577 require that the datatypes and classes in the signature of @x@ be
578 brought into the module along with @x@ unless these entities are
579 referenced by name in the user program.  The \Haskell{}
580 system silently imports any information that must accompany an
581 entity for type checking or any other purposes.  Such entities need
582 not even be explicitly exported: the following program is valid even though
583 @T@ does not escape @M1@:
584 \bprog
585 @
586   module M1(x) where
587     data T = T
588     x = T
589   
590   module M2 where
591     import M1(x)
592     y = x
593 @
594 \eprog
595 In this example, there is no way to supply an explicit type signature
596 for @y@ since @T@ is not in scope.
597 Whether or not @T@ is explicitly exported, module @M2@ knows
598 enough about @T@ to correctly type check the program.
599
600 The type of an exported entity is unaffected by non-exported type
601 synonyms.  For example, in
602 \bprog
603 @
604   module M(x) where
605     type T = Int
606     x :: T
607     x = 1
608 @
609 \eprog
610 the type of @x@ is both @T@ and @Int@; these are interchangeable even
611 when @T@ is not in scope.  That is, the definition of @T@ is available
612 to any module that encounters it whether or not the name @T@ is
613 in scope.  The only reason to export @T@ is to allow other modules to
614 refer it by name; the type checker finds the definition of @T@ if
615 needed whether or not it is exported.
616
617 \subsection{Standard Prelude}
618 \label{standard-prelude}
619 \index{standard prelude}
620 \index{libraries}
621 Many of the features of \Haskell{} are defined in \Haskell{}
622 itself as a library of standard datatypes, classes, and
623 functions, called the ``Standard Prelude.''  In
624 \Haskell{}, the Prelude is contained in the
625 module @Prelude@.\indexmodule{Prelude} There are also
626 many predefined library modules, which provide less frequently used
627 functions and types.  For example, arrays, 
628 tables, and most of the input/output are all part of the standard
629 libraries.    These are 
630 defined in the Haskell Library Report\cite{libraries},
631 a separate document.  Separating
632 libraries from the Prelude has the advantage of reducing the size and
633 complexity of the Prelude, allowing it to be more easily assimilated,
634 and increasing the space of useful names available to the programmer.
635
636 Prelude and library modules differ from other modules in that
637 their semantics (but not their implementation) are a fixed part of the
638 \Haskell{} language definition.
639 This means, for example, that a compiler may optimize calls to
640 functions in the Prelude without consulting the source code
641 of the Prelude.
642
643 \subsubsection{The @Prelude@ Module}
644 \indexmodule{Prelude}
645 \index{Prelude!implicit import of}
646
647 The @Prelude@ module is imported automatically into 
648 all modules as if by the statement `@import Prelude@', if and
649 only if it is not imported with an explicit @import@ declaration.
650 This provision for explicit import allows values defined in the
651 Prelude to be hidden from the unqualified name space.  The
652 @Prelude@ module is always available as a qualified import: an
653 implicit `@import qualified Prelude@' is part of every module and 
654 names prefixed by `@Prelude.@' can always be used to refer to entities in the
655 Prelude.
656
657 The semantics of the entities in @Prelude@ is specified by a reference
658 implementation of @Prelude@ written in \Haskell{}, given in
659 Appendix~\ref{stdprelude}.  Some datatypes (such as @Int@) and
660 functions (such as @Int@ addition) cannot be specified directly in
661 \Haskell{}.  Since the treatment of such entities depends on the
662 implementation, they are not formally defined in the appendix.
663 The implementation of
664 @Prelude@ is also incomplete in its treatment of tuples: there should
665 be an infinite family of tuples and their instance declarations, but the
666 implementation only gives a scheme.
667
668 Appendix~\ref{stdprelude} defines the module @Prelude@ using
669 several other modules: @PreludeList@, @PreludeIO@, and so on.
670 These modules are {\em not} part of Haskell 98, and they cannot be imported
671 separately.  They are simply 
672 there to help explain the structure of the @Prelude@ module; they
673 should be considered part of its implementation, not part of the language
674 definition.
675  
676 \subsubsection{Shadowing Prelude Names}
677 \label{std-prel-shadowing}
678
679 The rules about the Prelude have been cast so that it is
680 possible to use Prelude names for nonstandard purposes; however,
681 every module that does so must have an @import@ declaration
682 that makes this nonstandard usage explicit.  For example:
683 \bprog
684 @
685   module A( null, nonNull ) where
686     import Prelude hiding( null ) 
687     null, nonNull :: Int -> Bool
688     null    x = x == 0
689     nonNull x = not (null x)
690 @
691 \eprog
692 Module @A@ redefines @null@, and contains an unqualified reference to @null@
693 on the right hand side of @nonNull@. The latter would be ambiguous
694 without the @hiding(null)@ on the @import Prelude@ statement. Every
695 module that imports @A@ unqualified, and then makes an unqualified
696 reference to @null@ must also resolve the ambiguous use of @null@ just as
697 @A@ does. Thus there is little danger of accidentally shadowing Prelude
698 names.
699
700 It is possible to construct and use a different module to serve in
701 place of the Prelude.  Other than the fact that it is implicitly
702 imported, the Prelude is an ordinary \Haskell{} module; it is special
703 only in that some objects in the Prelude are referenced by special
704 syntactic constructs.  Redefining names used by the Prelude does not
705 affect the meaning of these special constructs.  For example, in
706 \bprog
707 @
708   module B where
709     import qualified Prelude
710     import MyPrelude
711       ...
712 @
713 \eprog
714 @B@ imports nothing from @Prelude@, but the
715 explicit @import qualified Prelude@ declaration prevents the automatic
716 import of 
717 @Prelude@.  @import MyPrelude@ brings the
718 non-standard prelude into scope.  As before, the
719 standard prelude names are hidden explicitly.  Special
720 syntax, such as lists or tuples, always refers to prelude entities:
721 there is no way to redefine the meaning of @[x]@ in terms of a
722 different implementation of lists.
723
724 It is not possible, however, to hide @instance@ declarations in the
725 @Prelude@.  For example, one cannot define a new instance for @Show Char@.
726
727 \subsection{Separate Compilation}
728 \index{separate compilation}
729 Depending on the \Haskell{} implementation used, separate compilation
730 of mutually recursive modules may require that imported modules contain
731 additional information so that they may be referenced before they are
732 compiled.  Explicit type signatures for all exported values may be
733 necessary to deal with mutual recursion.  The
734 precise details of separate compilation are not defined by this
735 report. 
736
737 \subsection{Abstract Datatypes}
738 \label{abstract-types}
739
740 \index{abstract datatype}
741 The ability to export a datatype without its constructors
742 allows the construction of abstract datatypes (ADTs).  For example,
743 an ADT for stacks could be defined as:
744 \bprog
745 @
746   module Stack( StkType, push, pop, empty ) where
747     data StkType a = EmptyStk | Stk a (StkType a)
748     push x s = Stk x s
749     pop (Stk _ s) = s
750     empty = EmptyStk
751 @
752 \eprog
753 Modules importing @Stack@ cannot construct values of type @StkType@
754 because they do not have access to the constructors of the type.
755 Instead, they must use @push@, @pop@, and @empty@ to construct such values.
756
757 It is also possible to build an ADT on top of an existing type by
758 using a @newtype@ declaration.  For example, stacks can be defined
759 with lists: 
760 \bprog
761 @
762   module Stack( StkType, push, pop, empty ) where
763     newtype StkType a = Stk [a]
764     push x (Stk s) = Stk (x:s)
765     pop (Stk (_:s)) = Stk s
766     empty = Stk []
767 @
768 \eprogNoSkip
769
770
771 %**~footer
772
773 % Local Variables: 
774 % mode: latex
775 % End: