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