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