October release
[haskell-report.git] / report / modules.verb
1 %
2 % $Header: /home/cvs/root/haskell-report/report/modules.verb,v 1.13 2001/10/02 09:09:26 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 {\em unqualified} name, $e$, is in scope, and for which the {\em qualified} name
200 $M.e$ is also in scope and refers to the same entity as $e$.  This set
201 may be empty.
202 For example:
203 \bprog
204 @
205   module Queue( module Stack, enqueue, dequeue ) where
206       import Stack
207       ...
208 @
209 \eprog
210 Here the module @Queue@ uses the module name @Stack@ in its export
211 list to abbreviate all the entities imported from @Stack@.  
212
213 A module can name its own local definitions in its export
214 list using its own name in the ``@module M@'' syntax, because a local
215 declaration brings into scope both a qualified and unqualified name (Section~\ref{qualifiers}). 
216 For example:
217 \bprog
218 @
219   module Mod1( module Mod1, module Mod2 ) where
220   import Mod2
221   import Mod3
222 @
223 \eprog
224 Here module @Mod1@ exports all local definitions as well as those
225 imported from @Mod2@ but not those imported from @Mod3@.
226
227 It is an error to use @module M@ in an export list unless @M@ is 
228 the module bearing the export list, or @M@ is imported by at 
229 least one import declaration (qualified or unqualified).
230 \end{enumerate}
231 Exports lists are cumulative: the set of entities exported by an export
232 list is the union of the entities exported by the individual items of the list.
233
234 It makes no difference to an importing module how an entity was 
235 exported.  For example, a field name @f@ from data type @T@ may be exported individually
236 (@f@, item (1) above); or as an explicitly-named member of its data type (@T(f)@, item (2));
237 or as an implicitly-named member (@T(..)@, item(2)); or by exporting an entire
238 module (@module M@, item (5)).  
239
240 The {\em unqualified} names of the entities exported by a module must all be distinct
241 (within their respective namespace).  For example
242 \bprog
243 @
244   module A ( B.f, C.f, g ) where   -- an invalid module
245   import qualified B(f,g)
246   import qualified C(f)
247   g = True
248 @
249 \eprog
250 There are name clashes in the export list between @B.f@ and @C.f@ and
251 between @g@ and @B.g@ even though there are no name clashes within
252 module @A@.  
253
254
255 \subsection{Import Declarations}
256 \label{import}
257 \index{import declaration}
258
259 @@@
260 impdecl   -> @import@ [@qualified@] modid [@as@ modid] [impspec]
261           |     & (empty declaration)
262 impspec   -> @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & \qquad (n>=0)
263              |  @hiding@ @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & \qquad (n>=0)
264
265 import    -> var
266           |  tycon [ @(..)@ | @(@ cname_1 @,@ ... @,@ cname_n @)@] & \qquad (n>=1)
267           |  tycls [@(..)@ | @(@ var_1 @,@ ... @,@ var_n @)@] & \qquad (n>=0)
268 cname     -> var | con
269 @@@
270 %             var
271 %          |  tycon
272 %          |  tycon @(..)@
273 %          |  tycon @(@ con_1 @,@ ... @,@ con_n@)@ & \qquad (n>=1)
274 %          |  tycls @(..)@
275 %          |  tycls @(@ var_1 @,@ ... @,@ var_n@)@ & \qquad (n>=0)
276 \indexsyn{impdecl}%
277 \indexsyn{impspec}%
278 \indexsyn{import}%
279 \indexsyn{cname}%
280
281 The entities exported by a module may be brought into scope in
282 another module with
283 an @import@
284 declaration at the beginning
285 of the module.  
286 The @import@ declaration names the module to be
287 imported
288 and optionally specifies the entities to be imported.
289 A single module may be imported by more than one @import@ declaration.  
290 Imported names serve as top level declarations: they scope over
291 the entire body of the module but may  be shadowed by local
292 non-top-level bindings.  
293
294 The effect of multiple @import@ declarations is strictly
295 cumulative: an entity is in scope if it is imported by any of the @import@
296 declarations in a module.  The ordering of import declarations is irrelevant.
297
298 \subsubsection{What is imported}
299 \label{whatisimported}
300
301 Exactly which entities are to be imported can be specified in one
302 of the following three ways:\nopagebreak[4]
303 \begin{enumerate}
304 \item
305 The imported entities can be specified explicitly
306 by listing them in parentheses.
307 Items in the list have the same form as those in export lists, except
308 qualifiers are not permitted and
309 the `@module@ "modid"' entity is not permitted.  When the @(..)@ form
310 of import is used for a type or class, the @(..)@ refers to all of the
311 constructors, methods, or field names exported from the module.
312
313 The list must name only
314 entities exported by the imported module.
315 The list may be empty, in which case nothing except the instances is
316 imported.
317
318 \item
319 Entities can be excluded by 
320 using the form @hiding(@"import_1 @,@ ... @,@ import_n"
321 @)@,\index{hiding} which
322 specifies that all entities exported by the named module should
323 be imported except for those named in the list.  Data constructors may be
324 named directly in hiding lists without being prefixed by the
325 associated type.  Thus, in
326 \bprog
327 @
328   import M hiding (C)
329 @
330 \eprog
331 any constructor, class, or type named @C@ is excluded.  In contrast,
332 using @C@ in an import list names only a class or type.  
333
334 It is an error to hide an entity that is not, in fact, exported by
335 the imported module.
336
337 \item
338 Finally, if "impspec" is omitted then 
339 all the entities exported by the specified module are imported.
340 \end{enumerate}
341
342 \subsubsection{Qualified import}
343 \index{qualified name}
344
345 For each entity imported under the rules of Section~\ref{whatisimported},
346 the top-level environment is extended.  If the import declaration used
347 the @qualified@ keyword, only the {\em qualified name} of the entity is
348 brought into scope.  If the @qualified@ keyword is omitted, then {\em both} the
349 qualified {\em and} unqualified name of the entity is brought into scope.
350 Section~\ref{qualifiers} describes qualified names in more detail.
351
352 The qualifier on the imported name is either the name of the imported module,
353 or the local alias given in the @as@ clause (Section~\ref{as-clause}) 
354 on the @import@ statement.
355 Hence, {\em the qualifier is not necessarily the name of the module in which the
356 entity was originally declared}.
357
358 The ability to exclude the unqualified names allows full programmer control of
359 the unqualified namespace: a locally defined entity can share the same
360 name as a qualified import:
361 \bprog
362 @
363   module Ring where
364   import qualified Prelude  -- All Prelude names must be qualified
365   import List( nub )
366
367   l1 + l2 = l1 ++ l2        -- This + differs from the one in the Prelude
368   l1 * l2 = nub (l1 + l2)   -- This * differs from the one in the Prelude
369
370   succ = (Prelude.+ 1)
371 @
372 \eprog
373
374
375 \subsubsection{Local aliases}
376 \label{as-clause}
377
378 Imported modules may be assigned a local alias in the importing module
379 using the @as@ clause.
380 For example, in
381 \bprog
382 @
383   import qualified VeryLongModuleName as C
384 @
385 \eprog
386 entities must be referenced using `@C.@' as a qualifier instead of
387 `@VeryLongModuleName.@'.  This also allows a different module to be substituted
388 for @VeryLongModuleName@ without changing the qualifiers used for the imported module.
389 It is legal for more than one module in scope to 
390 use the same qualifier, provided that all names can still be resolved unambiguously.
391 For example:
392 \bprog
393 @
394   module M where
395     import qualified Foo as A
396     import qualified Baz as A
397     x = A.f
398 @
399 \eprog
400 This module is legal provided only that @Foo@ and @Baz@ do not both export @f@.
401
402 An @as@ clause may also be used on an un-@qualified@ @import@ statement:
403 \bprog
404 @
405   import Foo as A(f)
406 @
407 \eprog
408 This declaration brings into scope @f@ and @A.f@.
409
410
411 \subsubsection{Examples}
412
413 To clarify the above import rules, suppose the module @A@ exports @x@ and @y@.
414 Then this table shows what names are brought into scope by the specified import statement:
415 \begin{center}
416 \begin{tabular}{|ll|}
417 \hline
418 Import declaration & Names brought into scope \\
419 \hline
420   @import A@                    & @x@, @y@, @A.x@, @A.y@ \\
421   @import A()@                  & (nothing)     \\
422   @import A(x)@                 & @x@, @A.x@ \\
423   @import qualified A@          & @A.x@, @A.y@ \\
424   @import qualified A()@        & (nothing) \\
425   @import qualified A(x)@       & @A.x@ \\
426   @import A hiding ()@          & @x@, @y@, @A.x@, @A.y@ \\
427   @import A hiding (x)@         & @y@, @A.y@ \\
428   @import qualified A hiding ()@        & @A.x@, @A.y@ \\
429   @import qualified A hiding (x)@       & @A.y@ \\
430   @import A as B@               & @x@, @y@, @B.x@, @B.y@ \\
431   @import A as B(x)@            & @B.x@ \\
432   @import qualified A as B@     & @B.x@, @B.y@ \\
433 \hline
434 \end{tabular}
435 \end{center}
436 In all cases, all instance declarations in scope in module @A@ are imported
437 (Section~\ref{import-instances}).
438
439 \subsection{Importing and Exporting Instance Declarations}
440 \label{import-instances}
441 \index{instance declaration!importing and exporting}
442
443 Instance declarations cannot be explicitly named on import or export
444 lists.  All instances in scope within a module are {\em always}
445 exported and any import brings {\em all} instances in from the
446 imported module.  Thus, an
447 instance declaration is in scope if and only if a chain of @import@
448 declarations leads to the module containing the instance declaration.
449
450 For example, @import M()@ does not bring
451 any new names in scope from module @M@, but does bring in any instances
452 visible in @M@.  A module whose only purpose is to provide instance
453 declarations can have an empty export list.  For example
454 \bprog
455 @
456   module MyInstances() where
457     instance Show (a -> b) where
458         show fn = "<<function>>"
459     instance Show (IO a) where
460         show io = "<<IO action>>"
461 @
462 \eprog
463
464 \subsection{Name Clashes and Closure}
465
466 \subsubsection{Qualified names}\index{qualified name}
467 \label{qualifiers}
468
469 A {\em qualified name} is written as "modid"@.@"name" (Section~\ref{ids}).
470
471 A qualified name is brought into scope:
472 \begin{itemize}
473 \item {\em By a top level declaration.}
474 A top-level declaration brings into scope both the unqualified {\em and}
475 the qualified name of the entity being defined.  Thus:
476 \bprog
477 @
478   module M where
479     f x = ...
480     g x = M.f x x
481 @
482 \eprog
483 is legal.  The {\em defining} occurrence must mention the {\em unqualified} name; therefore, it is
484 illegal to write
485 \bprog
486 @
487   module M where
488     M.f x = ...                 -- ILLEGAL
489     g x = let M.y = x+1 in ...  -- ILLEGAL
490 @
491 \eprog
492 \item {\em By an @import@ declaration.}  An @import@ declaration, whether @qualified@ or not,
493 always brings into scope the qualified name of the imported entity (Section~\ref{import}).
494 \end{itemize}
495 Qualifiers may also be applied to
496 names imported by an unqualified import; this allows a qualified
497 import to be replaced with an unqualified one without forcing changes
498 in the references to the imported names.  
499
500
501 \subsubsection{Name clashes}
502
503 If a module contains a bound occurrence of a name, such as @f@ or @A.f@,
504 it must be possible unambiguously to resolve which entity is thereby referred to;
505 that is, there must be only one binding for @f@ or @A.f@ respectively.
506
507 It is {\em not} an error for there to exist names that cannot be so 
508 resolved, provided that the program does not mention those names.  For example:
509 \bprog
510 @
511   module A where
512     import B
513     import C
514     tup = (b, c, d, x)
515   
516   module B( d, b, x, y ) where
517     import D
518     x = ...
519     y = ...
520     b = ...
521   
522   module C( d, c, x, y ) where
523     import D
524     x = ...
525     y = ...
526     c = ...
527
528   module D( d ) where
529     d = ...
530 @
531 \eprog
532 Consider the definition of @tup@.  
533 \begin{itemize}
534 \item The references to @b@ and @c@
535 can be unambiguously resolved to @b@ declared in @B@, and @c@ declared in
536 @C@ respectively.  
537 \item The reference to @d@ is unambiguously resolved to
538 @d@ declared in @D@.  In this case the same entity is brought into scope by two routes
539 (the import of @B@ and the import of @C@), and can be referred to in @A@ by the names
540 @d@, @B.d@, and @C.d@.
541 \item The reference to @x@ is ambiguous: it could mean @x@ declared in @B@, or @x@ 
542 declared in @C@.  The ambiguity could be fixed by replacing the reference to @x@ by
543 @B.x@ or @C.x@.
544 \item There is no reference to @y@, so it is not erroneous that distinct entities called
545 @y@ are exported by both @B@ and @C@.  An error is only reported if @y@ is actually mentioned.
546 \end{itemize}
547
548 The name occurring in a type signature or fixity declarations is
549 always unqualified, and unambiguously refers to another declaration in
550 the same declaration list (except that the fixity declaration for a
551 class method can occur at top level --- Section~\ref{fixity}). For example,
552 the following module is legal:
553 \bprog
554 @
555   module F where
556
557     sin :: Float -> Float
558     sin x = (x::Float)
559
560     f x = Prelude.sin (F.sin x)
561 @
562 \eprog
563 The local declaration for @sin@ is
564 legal, even though the Prelude function @sin@ is implicitly in
565 scope. The references to @Prelude.sin@ and @F.sin@ must both be qualified
566 to make it unambigous which @sin@ is meant. However, the unqualified
567 name "@sin@" in the type signature in the first line of @F@ unambiguously
568 refers to the local declaration for @sin@.
569
570 \subsubsection{Closure}
571 \label{closure}
572 \index{closure}
573
574 Every module in a \Haskell{} program must be {\em closed}.  That is,
575 every name explicitly mentioned by the source code
576 must be either defined locally or imported from another module.
577 However, entities that the compiler requires for type checking or other
578 compile time analysis need not be imported if they are not mentioned
579 by name.  The \Haskell{} compilation system is responsible for finding
580 any information needed for compilation without the help of the
581 programmer.  That is, the import of a variable @x@ does not
582 require that the datatypes and classes in the signature of @x@ be
583 brought into the module along with @x@ unless these entities are
584 referenced by name in the user program.  The \Haskell{}
585 system silently imports any information that must accompany an
586 entity for type checking or any other purposes.  Such entities need
587 not even be explicitly exported: the following program is valid even though
588 @T@ does not escape @M1@:
589 \bprog
590 @
591   module M1(x) where
592     data T = T
593     x = T
594   
595   module M2 where
596     import M1(x)
597     y = x
598 @
599 \eprog
600 In this example, there is no way to supply an explicit type signature
601 for @y@ since @T@ is not in scope.
602 Whether or not @T@ is explicitly exported, module @M2@ knows
603 enough about @T@ to correctly type check the program.
604
605 The type of an exported entity is unaffected by non-exported type
606 synonyms.  For example, in
607 \bprog
608 @
609   module M(x) where
610     type T = Int
611     x :: T
612     x = 1
613 @
614 \eprog
615 the type of @x@ is both @T@ and @Int@; these are interchangeable even
616 when @T@ is not in scope.  That is, the definition of @T@ is available
617 to any module that encounters it whether or not the name @T@ is
618 in scope.  The only reason to export @T@ is to allow other modules to
619 refer it by name; the type checker finds the definition of @T@ if
620 needed whether or not it is exported.
621
622 \subsection{Standard Prelude}
623 \label{standard-prelude}
624 \index{standard prelude}
625 \index{libraries}
626 Many of the features of \Haskell{} are defined in \Haskell{}
627 itself as a library of standard datatypes, classes, and
628 functions, called the ``Standard Prelude.''  In
629 \Haskell{}, the Prelude is contained in the
630 module @Prelude@.\indexmodule{Prelude} There are also
631 many predefined library modules, which provide less frequently used
632 functions and types.  For example, arrays, 
633 tables, and most of the input/output are all part of the standard
634 libraries.    These are 
635 defined in the Haskell Library Report\cite{libraries},
636 a separate document.  Separating
637 libraries from the Prelude has the advantage of reducing the size and
638 complexity of the Prelude, allowing it to be more easily assimilated,
639 and increasing the space of useful names available to the programmer.
640
641 Prelude and library modules differ from other modules in that
642 their semantics (but not their implementation) are a fixed part of the
643 \Haskell{} language definition.
644 This means, for example, that a compiler may optimize calls to
645 functions in the Prelude without consulting the source code
646 of the Prelude.
647
648 \subsubsection{The @Prelude@ Module}
649 \indexmodule{Prelude}
650 \index{Prelude!implicit import of}
651
652 The @Prelude@ module is imported automatically into 
653 all modules as if by the statement `@import Prelude@', if and
654 only if it is not imported with an explicit @import@ declaration.
655 This provision for explicit import allows values defined in the
656 Prelude to be hidden from the unqualified name space.  The
657 @Prelude@ module is always available as a qualified import: an
658 implicit `@import qualified Prelude@' is part of every module and 
659 names prefixed by `@Prelude.@' can always be used to refer to entities in the
660 Prelude.
661
662 The semantics of the entities in @Prelude@ is specified by a reference
663 implementation of @Prelude@ written in \Haskell{}, given in
664 Appendix~\ref{stdprelude}.  Some datatypes (such as @Int@) and
665 functions (such as @Int@ addition) cannot be specified directly in
666 \Haskell{}.  Since the treatment of such entities depends on the
667 implementation, they are not formally defined in the appendix.
668 The implementation of
669 @Prelude@ is also incomplete in its treatment of tuples: there should
670 be an infinite family of tuples and their instance declarations, but the
671 implementation only gives a scheme.
672
673 Appendix~\ref{stdprelude} defines the module @Prelude@ using
674 several other modules: @PreludeList@, @PreludeIO@, and so on.
675 These modules are {\em not} part of Haskell 98, and they cannot be imported
676 separately.  They are simply 
677 there to help explain the structure of the @Prelude@ module; they
678 should be considered part of its implementation, not part of the language
679 definition.
680  
681 \subsubsection{Shadowing Prelude Names}
682 \label{std-prel-shadowing}
683
684 The rules about the Prelude have been cast so that it is
685 possible to use Prelude names for nonstandard purposes; however,
686 every module that does so must have an @import@ declaration
687 that makes this nonstandard usage explicit.  For example:
688 \bprog
689 @
690   module A( null, nonNull ) where
691     import Prelude hiding( null ) 
692     null, nonNull :: Int -> Bool
693     null    x = x == 0
694     nonNull x = not (null x)
695 @
696 \eprog
697 Module @A@ redefines @null@, and contains an unqualified reference to @null@
698 on the right hand side of @nonNull@. The latter would be ambiguous
699 without the @hiding(null)@ on the @import Prelude@ statement. Every
700 module that imports @A@ unqualified, and then makes an unqualified
701 reference to @null@ must also resolve the ambiguous use of @null@ just as
702 @A@ does. Thus there is little danger of accidentally shadowing Prelude
703 names.
704
705 It is possible to construct and use a different module to serve in
706 place of the Prelude.  Other than the fact that it is implicitly
707 imported, the Prelude is an ordinary \Haskell{} module; it is special
708 only in that some objects in the Prelude are referenced by special
709 syntactic constructs.  Redefining names used by the Prelude does not
710 affect the meaning of these special constructs.  For example, in
711 \bprog
712 @
713   module B where
714     import qualified Prelude
715     import MyPrelude
716       ...
717 @
718 \eprog
719 @B@ imports nothing from @Prelude@, but the
720 explicit @import qualified Prelude@ declaration prevents the automatic
721 import of 
722 @Prelude@.  @import MyPrelude@ brings the
723 non-standard prelude into scope.  As before, the
724 standard prelude names are hidden explicitly.  Special
725 syntax, such as lists or tuples, always refers to prelude entities:
726 there is no way to redefine the meaning of @[x]@ in terms of a
727 different implementation of lists.
728
729 It is not possible, however, to hide @instance@ declarations in the
730 @Prelude@.  For example, one cannot define a new instance for @Show Char@.
731
732 \subsection{Separate Compilation}
733 \index{separate compilation}
734 Depending on the \Haskell{} implementation used, separate compilation
735 of mutually recursive modules may require that imported modules contain
736 additional information so that they may be referenced before they are
737 compiled.  Explicit type signatures for all exported values may be
738 necessary to deal with mutual recursion.  The
739 precise details of separate compilation are not defined by this
740 report. 
741
742 \subsection{Abstract Datatypes}
743 \label{abstract-types}
744
745 \index{abstract datatype}
746 The ability to export a datatype without its constructors
747 allows the construction of abstract datatypes (ADTs).  For example,
748 an ADT for stacks could be defined as:
749 \bprog
750 @
751   module Stack( StkType, push, pop, empty ) where
752     data StkType a = EmptyStk | Stk a (StkType a)
753     push x s = Stk x s
754     pop (Stk _ s) = s
755     empty = EmptyStk
756 @
757 \eprog
758 Modules importing @Stack@ cannot construct values of type @StkType@
759 because they do not have access to the constructors of the type.
760 Instead, they must use @push@, @pop@, and @empty@ to construct such values.
761
762 It is also possible to build an ADT on top of an existing type by
763 using a @newtype@ declaration.  For example, stacks can be defined
764 with lists: 
765 \bprog
766 @
767   module Stack( StkType, push, pop, empty ) where
768     newtype StkType a = Stk [a]
769     push x (Stk s) = Stk (x:s)
770     pop (Stk (_:s)) = Stk s
771     empty = Stk []
772 @
773 \eprogNoSkip
774
775
776 %**~footer
777
778 % Local Variables: 
779 % mode: latex
780 % End: