Fix reference to "Haskell 98"
[haskell-report.git] / report / modules.verb
index c18df7f..46cd095 100644 (file)
@@ -1,5 +1,5 @@
 %
-% $Header: /home/cvs/root/haskell-report/report/modules.verb,v 1.3 2001/05/30 10:59:06 simonpj Exp $
+% $Header: /home/cvs/root/haskell-report/report/modules.verb,v 1.20 2003/01/13 13:08:56 simonpj Exp $
 %
 %**<title>The Haskell 98 Report: Modules</title>
 %*section 5
@@ -9,9 +9,9 @@
 \index{module}
 
 A module defines a collection of values, datatypes, type synonyms,
-classes, etc.~(see Section~\ref{declarations}) in an environment created
-by a set of {\em imports}, resources brought into scope from other modules, 
-and {\em exports} some of these resources, making them available to
+classes, etc.~(see Chapter~\ref{declarations}), in an environment created
+by a set of {\em imports} (resources brought into scope from other modules).
+It {\em exports} some of these resources, making them available to
 other modules.  
 We use the term {\em entity}\index{entity} to refer to
 a value, type, or class defined in, imported into, or perhaps
@@ -22,7 +22,7 @@ which, by convention, must be called @Main@\indexmodule{Main} and must
 export the value @main@\indextt{main}.  The {\em value} of the program
 is the value of the identifier @main@ in module @Main@,
 which must be a computation of type $@IO@~\tau$ for some type $\tau$
-(see Section~\ref{io}).  When the program is executed, the computation
+(see Chapter~\ref{io}).  When the program is executed, the computation
 @main@ is performed, and its result (of type $\tau$) is discarded.
 
 Modules may reference other modules via explicit
@@ -65,24 +65,40 @@ It is equivalent to the following single-module program:
     bf = ...
 @
 \eprog
-Because they are mutually recursive,
+Because they are allowed to be mutually recursive,
 modules allow a program to be partitioned freely without regard to
 dependencies.
 
-The name-space for modules themselves is flat, with each module being associated
-with a unique module name (which are \Haskell{} identifiers
-beginning with a capital letter; i.e.~"modid").  
+\begin{haskellprime}
+A module name (lexeme "modid") is a sequence of one or more
+identifiers beginning with capital letters, separated by dots, with no
+intervening spaces.  For example, @Data.Bool@, @Main@ and
+@Foreign.Marshal.Alloc@ are all valid module names.
+
+@@@
+modid   ->  \hprime{\{conid @.@\}} conid       & (\tr{modules})
+@@@
+\indexsyn{modid}%
+
+Module names can be thought of as being arranged in a hierarchy in
+which appending a new component creates a child of the original module
+name.  For example, the module @Control.Monad.ST@ is a child of the
+@Control.Monad@ sub-hierarchy.  This is purely a convention, however,
+and not part of the language definition; in this report a "modid" is
+treated as a single identifier occupying a flat namespace.
+\end{haskellprime}
+
 There is one distinguished module, @Prelude@, which is imported into
-all programs by default (see Section~\ref{standard-prelude}), plus a
+all modules by default (see Section~\ref{standard-prelude}), plus a
 set of standard library modules that may be imported as required
-(see the \Haskell{} Library Report\cite{libraries}).
+(see Part~\ref{libraries}).
 
 \subsection{Module Structure} 
 \label{module-implementations}
 
 A module defines a mutually
 recursive scope containing declarations for value bindings, data
-types, type synonyms, classes, etc. (see Section~\ref{declarations}).
+types, type synonyms, classes, etc. (see Chapter~\ref{declarations}).
 
 @@@
 module -> @module@ modid [exports] @where@ body
@@ -91,27 +107,22 @@ body   -> @{@ impdecls @;@ topdecls @}@
        | @{@ impdecls  @}@
        | @{@ topdecls @}@
 
-modid       -> conid
-impdecls     -> impdecl_1 @;@ ... @;@ impdecl_n        & \qquad (n>=1)
-topdecls     -> topdecl_1 @;@ ... @;@ topdecl_n        & \qquad (n>=1)
+impdecls     -> impdecl_1 @;@ ... @;@ impdecl_n        & (n>=1)
+topdecls     -> topdecl_1 @;@ ... @;@ topdecl_n        & (n>=1)
 @@@
 
 \indexsyn{module}%
 \indexsyn{body}%
-\indexsyn{modid}%
 \indexsyn{impdecls}%
 \indexsyn{topdecls}%
 
 A module 
 begins with a header: the keyword
 @module@, the module name, and a list of entities (enclosed in round
-parentheses) to be exported.  The header is followed by an optional
-list of @import@ declarations that specify modules to be imported,
-optionally restricting 
-the imported bindings.  This is
-followed by the module
-body.  The module body is simply a list of top-level declarations
-("topdecls"), as described in Section~\ref{declarations}.  
+parentheses) to be exported.  The header is followed by a possibly-empty
+list of @import@ declarations ("impdecls", Section~\ref{import}) that specify modules to be imported,
+optionally restricting the imported bindings.  
+This is followed by a possibly-empty list of top-level declarations ("topdecls", Chapter~\ref{declarations}).
 
 An abbreviated form of module, consisting only 
 of\index{abbreviated module}
@@ -126,18 +137,17 @@ for the top level of the module.
 \index{export list}
 
 @@@
-exports         -> @(@ export_1 @,@ ... @,@ export_n [ @,@ ] @)@ & \qquad (n>=0)
+exports         -> @(@ export_1 @,@ ... @,@ export_n [ @,@ ] @)@ & (n>=0)
 
 export   -> qvar
-        |  qtycon [@(..)@ | @(@ qcname_1 @,@ ... @,@ qcname_n @)@] & \qquad (n>=0)
-        |  qtycls [@(..)@ | @(@ qvar_1 @,@ ... @,@ qvar_n @)@] & \qquad (n>=0)
+        |  qtycon [@(..)@ | @(@ cname_1 @,@ ... @,@ cname_n @)@] &  (n>=0)
+        |  qtycls [@(..)@ | @(@ var_1 @,@ ... @,@ var_n @)@] &  (n>=0)
          |  @module@ modid
 
-qcname   -> qvar | qcon
+cname   -> var | con
 @@@
 \indexsyn{exports}%
 \indexsyn{export}%
-\indexsyn{qcname}%
 
 An {\em export list} identifies the entities to be exported by a
 module declaration.  A module implementation may only export an entity
@@ -150,9 +160,9 @@ Entities in an export list may be named as follows:
 \item
 A value, field name, or class method, whether declared in
 the module body or imported,
-may be named by giving the name of the value as a "qvarid".
+may be named by giving the name of the value as a "qvarid", which must be in scope.
 Operators should be enclosed in parentheses to turn them into
-"qvarid"'s.  
+"qvarid"s.  
 
 \item
 An algebraic datatype "T"
@@ -165,20 +175,34 @@ The form "T" names the type {\em but not the constructors or field names}.
 The ability to export a type without its constructors allows the
 construction of abstract datatypes (see Section~\ref{abstract-types}).
 \item
-The form $T@(@qcname_1@,@\ldots@,@qcname_n@)@$, where the $qcname_i$
-name only constructors and field names in $T$, 
+The form $T@(@c_1@,@\ldots@,@c_n@)@$, 
 names the type and some or all of its constructors and field names.  
-The $qcname_i$ must not contain duplications.  
+% Restriction removed March 02:
+% The subordinate names $c_i$ must not contain duplicates.  
 \item
 The abbreviated form "T@(..)@" names the type 
 and all its constructors and field names that are currently in scope
 (whether qualified or not).
 \end{itemize}
-Data constructors cannot be named in export lists in any other way.
+In all cases, the (possibly-qualified) type constructor "T" must be in scope. 
+The constructor and field names $c_i$ in the second form are unqualified;
+one of these subordinate names is legal if and only if (a) it names a constructor
+or field of "T", and (b) the constructor or field
+is in scope in the module body {\em regardless of whether it is in scope
+under a qualified or unqualified name}. For example, the following is 
+legal
+\bprog
+@
+  module A( Mb.Maybe( Nothing, Just ) ) where
+    import qualified Data.Maybe as Mb
+@
+\eprog
+Data constructors cannot be named in export lists except as subordinate names, because
+they cannot otherwise be distinguished from type constructors.
 
 \item
 A type synonym "T" declared by a
-@type@ declaration may be named by the form "T".
+@type@ declaration may be named by the form "T", where "T" is in scope.
 \index{type synonym}
 
 \item
@@ -189,62 +213,78 @@ declared in a @class@ declaration may be named in one of three ways:
 \item
 The form "C" names the class {\em but not the class methods}.
 \item
-The form $C@(@f_1@,@\ldots@,@f_n@)@$, where
-the $f_i$ must be class methods of $C$, names the class and some or all
-of its methods.  The $f_i$ must not contain duplications.
+The form $C@(@f_1@,@\ldots@,@f_n@)@$, names the class and some or all
+of its methods.  
+% Restriction removed March 02:
+% The subordinate names $f_i$ must not contain duplicates.
 \item
 The abbreviated form $C@(..)@$ names the class and all its methods
 that are in scope (whether qualified or not).
 \end{itemize}
+In all cases, "C" must be in scope.  In the second form,
+one of the (unqualified) subordinate names $f_i$ is legal if and only if (a) it names a
+class method of "C", and (b) the class method 
+is in scope in the module body regardless of whether it is in scope
+under a qualified or unqualified name.
 
 \item
-The set of all entities brought into scope 
-from a
-module "m" by one or more unqualified @import@ declarations may be
-named by the form `"@module@ m"', which is equivalent to listing all of
-the entities imported from the module.  For example:
+The form ``@module M@'' names the set of all entities that are in
+scope with both an unqualified name ``@e@'' and a qualified name
+``@M.e@''.
+This set may be empty.
+For example:
 \bprog
 @
-      module Queue( module Stack, enqueue, dequeue ) where
-          import Stack
-          ...
+  module Queue( module Stack, enqueue, dequeue ) where
+      import Stack
+      ...
 @
 \eprog
 Here the module @Queue@ uses the module name @Stack@ in its export
 list to abbreviate all the entities imported from @Stack@.  
 
-\item
 A module can name its own local definitions in its export
-list using its name in the `"@module@" m' syntax.  For example:
+list using its own name in the ``@module M@'' syntax, because a local
+declaration brings into scope both a qualified and unqualified name (Section~\ref{qualifiers}). 
+For example:
 \bprog
 @
module Mod1(module Mod1, module Mod2) where
- import Mod2
- import Mod3
 module Mod1( module Mod1, module Mod2 ) where
 import Mod2
 import Mod3
 @
 \eprog
 Here module @Mod1@ exports all local definitions as well as those
-imported from @Mod2@ but not those imported from @Mod3@.  Note that
-@module M where@ is the same as using @module M(module M) where@.
+imported from @Mod2@ but not those imported from @Mod3@.
+
+It is an error to use @module M@ in an export list unless @M@ is 
+the module bearing the export list, or @M@ is imported by at 
+least one import declaration (qualified or unqualified).
 \end{enumerate}
-The qualifier (see Section \ref{import}) on a name only identifies the
-module an entity is 
-imported from; this may be different from the module in which the
-entity is defined.  For example, if module A exports B.c, this is
-referenced as `@A.c@', not @`A.B.c@'.  In consequence, names in export
-lists must remain distinct after qualifiers are removed.  For example:
+Exports lists are cumulative: the set of entities exported by an export
+list is the union of the entities exported by the individual items of the list.
+
+It makes no difference to an importing module how an entity was 
+exported.  For example, a field name @f@ from data type @T@ may be exported individually
+(@f@, item (1) above); or as an explicitly-named member of its data type (@T(f)@, item (2));
+or as an implicitly-named member (@T(..)@, item(2)); or by exporting an entire
+module (@module M@, item (5)).  
+
+The {\em unqualified} names of the entities exported by a module must all be distinct
+(within their respective namespace).  For example
 \bprog
 @
-  module A ( B.f, C.f, g, B.g ) where   -- an invalid module
-  import qualified B(f,g)
-  import qualified C(f)
-  g = True
+  module A ( C.f, C.g, g, module B ) where   -- an invalid module
+  import B(f)
+  import qualified C(f,g)
+  g = True
 @
 \eprog
-There are name clashes in the export list between @B.f@ and @C.f@ and
-between @g@ and @B.g@ even though there are no name clashes within
-module @A@.  
-
+There are no name clashes within module @A@ itself, 
+but there are name clashes in the export list between @C.g@ and @g@
+(assuming @C.g@ and @g@ are different entities -- remember, modules
+can import each other recursively), and between @module B@ and @C.f@
+(assuming @B.f@ and @C.f@ are different entities).
 
 \subsection{Import Declarations}
 \label{import}
@@ -253,20 +293,20 @@ module @A@.
 @@@
 impdecl   -> @import@ [@qualified@] modid [@as@ modid] [impspec]
          |     & (empty declaration)
-impspec   -> @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & \qquad (n>=0)
-             |  @hiding@ @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & \qquad (n>=0)
+impspec   -> @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & (n>=0)
+             |  @hiding@ @(@ import_1 @,@ ... @,@ import_n [ @,@ ] @)@ & (n>=0)
 
 import    -> var
-         |  tycon [ @(..)@ | @(@ cname_1 @,@ ... @,@ cname_n @)@] & \qquad (n>=1)
-         |  tycls [@(..)@ | @(@ var_1 @,@ ... @,@ var_n @)@] & \qquad (n>=0)
+         |  tycon [ @(..)@ | @(@ cname_1 @,@ ... @,@ cname_n @)@] &  (n>=0)
+         |  tycls [@(..)@ | @(@ var_1 @,@ ... @,@ var_n @)@] & (n>=0)
 cname     -> var | con
 @@@
 %             var
 %          |  tycon
 %          |  tycon @(..)@
-%          |  tycon @(@ con_1 @,@ ... @,@ con_n@)@ & \qquad (n>=1)
+%          |  tycon @(@ con_1 @,@ ... @,@ con_n@)@ & (n>=1)
 %          |  tycls @(..)@
-%          |  tycls @(@ var_1 @,@ ... @,@ var_n@)@ & \qquad (n>=0)
+%          |  tycls @(@ var_1 @,@ ... @,@ var_n@)@ & (n>=0)
 \indexsyn{impdecl}%
 \indexsyn{impspec}%
 \indexsyn{import}%
@@ -283,12 +323,22 @@ and optionally specifies the entities to be imported.
 A single module may be imported by more than one @import@ declaration.  
 Imported names serve as top level declarations: they scope over
 the entire body of the module but may  be shadowed by local
-non-top-level bindings.  The effect of multiple @import@ declarations is
-cumulative: an entity is in scope if it is named by any of the @import@
-declarations in a module.  The ordering of imports is irrelevant.
+non-top-level bindings.  
+
+The effect of multiple @import@ declarations is strictly
+cumulative: an entity is in scope if it is imported by any of the @import@
+declarations in a module.  The ordering of import declarations is irrelevant.
+
+Lexically, the terminal symbols ``@as@'', ``@qualified@'' and
+``@hiding@'' are each a "varid" rather than a "reservedid".  They have
+special significance only in the context of an @import@ declaration;
+they may also be used as variables.
+
+\subsubsection{What is imported}
+\label{whatisimported}
 
 Exactly which entities are to be imported can be specified in one
-of three ways:\nopagebreak[4]
+of the following three ways:\nopagebreak[4]
 \begin{enumerate}
 \item
 The imported entities can be specified explicitly
@@ -320,15 +370,8 @@ associated type.  Thus, in
 any constructor, class, or type named @C@ is excluded.  In contrast,
 using @C@ in an import list names only a class or type.  
 
-The hiding
-clause only applies to unqualified names.  In the previous example, 
-the name @M.C@ is brought into scope.  A hiding clause has no effect
-in an @import@ @qualified@ declaration.
-
-The effect of multiple @import@ declarations is strictly
-cumulative: hiding an entity on one import declaration does not
-prevent the same entity from being imported by another import from
-the same module.
+It is an error to hide an entity that is not, in fact, exported by
+the imported module.
 
 \item
 Finally, if "impspec" is omitted then 
@@ -338,31 +381,37 @@ all the entities exported by the specified module are imported.
 \subsubsection{Qualified import}
 \index{qualified name}
 
-An import declaration that uses the @qualified@ keyword brings into scope
-only the {\em qualified names} of the imported entities (Section~\ref{qualifiers});
-if the @qualified@ keyword
-is omitted, both qualified and unqualified names are brought into scope.
+For each entity imported under the rules of Section~\ref{whatisimported},
+the top-level environment is extended.  If the import declaration used
+the @qualified@ keyword, only the {\em qualified name} of the entity is
+brought into scope.  If the @qualified@ keyword is omitted, then {\em both} the
+qualified {\em and} unqualified name of the entity is brought into scope.
+Section~\ref{qualifiers} describes qualified names in more detail.
+
 The qualifier on the imported name is either the name of the imported module,
-or the local alias given in the @as@ clause on the @import@ statement (Section~\ref{as-clause}).
+or the local alias given in the @as@ clause (Section~\ref{as-clause}) 
+on the @import@ statement.
 Hence, {\em the qualifier is not necessarily the name of the module in which the
 entity was originally declared}.
 
 The ability to exclude the unqualified names allows full programmer control of
 the unqualified namespace: a locally defined entity can share the same
 name as a qualified import:
+\par
+{\small
 \bprog
 @
   module Ring where
-  import qualified Prelude  -- All Prelude names must be qualified
-  import List( nub )
+  import qualified Prelude    -- All Prelude names must be qualified
+  import Data.List( nub )
 
-  l1 + l2 = l1 ++ l2        -- This + differs from the one in the Prelude
-  l1 * l2 = nub (l1 + l2)   -- This * differs from the one in the Prelude
+  l1 + l2 = l1 Prelude.++ l2  -- This + differs from the one in the Prelude
+  l1 * l2 = nub (l1 + l2)     -- This * differs from the one in the Prelude
 
   succ = (Prelude.+ 1)
 @
 \eprog
-
+}
 
 \subsubsection{Local aliases}
 \label{as-clause}
@@ -372,12 +421,12 @@ using the @as@ clause.
 For example, in
 \bprog
 @
-  import qualified Complex as C
+  import qualified VeryLongModuleName as C
 @
 \eprog
 entities must be referenced using `@C.@' as a qualifier instead of
-`@Complex.@'.  This also allows a different module to be substituted
-for @Complex@ without changing the qualifiers used for the imported module.
+`@VeryLongModuleName.@'.  This also allows a different module to be substituted
+for @VeryLongModuleName@ without changing the qualifiers used for the imported module.
 It is legal for more than one module in scope to 
 use the same qualifier, provided that all names can still be resolved unambiguously.
 For example:
@@ -400,7 +449,36 @@ An @as@ clause may also be used on an un-@qualified@ @import@ statement:
 This declaration brings into scope @f@ and @A.f@.
 
 
+\subsubsection{Examples}
+
+To clarify the above import rules, suppose the module @A@ exports @x@ and @y@.
+Then this table shows what names are brought into scope by the specified import statement:
+\begin{center}
+\begin{tabular}{|ll|}
+\hline
+Import declaration & Names brought into scope \\
+\hline
+  @import A@                   & @x@, @y@, @A.x@, @A.y@ \\
+  @import A()@                 & (nothing)     \\
+  @import A(x)@                & @x@, @A.x@ \\
+  @import qualified A@         & @A.x@, @A.y@ \\
+  @import qualified A()@       & (nothing) \\
+  @import qualified A(x)@      & @A.x@ \\
+  @import A hiding ()@         & @x@, @y@, @A.x@, @A.y@ \\
+  @import A hiding (x)@                & @y@, @A.y@ \\
+  @import qualified A hiding ()@       & @A.x@, @A.y@ \\
+  @import qualified A hiding (x)@      & @A.y@ \\
+  @import A as B@              & @x@, @y@, @B.x@, @B.y@ \\
+  @import A as B(x)@           & @x@, @B.x@ \\
+  @import qualified A as B@    & @B.x@, @B.y@ \\
+\hline
+\end{tabular}
+\end{center}
+In all cases, all instance declarations in scope in module @A@ are imported
+(Section~\ref{import-instances}).
+
 \subsection{Importing and Exporting Instance Declarations}
+\label{import-instances}
 \index{instance declaration!importing and exporting}
 
 Instance declarations cannot be explicitly named on import or export
@@ -418,9 +496,9 @@ declarations can have an empty export list.  For example
 @
   module MyInstances() where
     instance Show (a -> b) where
-       show fn = "<<function>>"
+      show fn = "<<function>>"
     instance Show (IO a) where
-       show io = "<<IO action>>"
+      show io = "<<IO action>>"
 @
 \eprog
 
@@ -429,21 +507,7 @@ declarations can have an empty export list.  For example
 \subsubsection{Qualified names}\index{qualified name}
 \label{qualifiers}
 
-A {\em qualified name} is written as "modid"@.@"name".
-Since qualifier names are part of the lexical syntax, no spaces are
-allowed between the qualifier and the name.
-Sample parses are shown below.
-\[\bto{|l|l|}
-\hline
-This                               & Lexes as this                       \\
-\hline
-@f.g@                               & @f . g@ (three tokens)             \\
-@F.g@                              & @F.g@ (qualified `g')            \\
-@f..@                              & @f ..@ (two tokens)    \\
-@F..@                              & @F..@ (qualified `.')         \\
-@F.@                                & @F .@ (two tokens)                     \\
-\hline\eto\]
-
+A {\em qualified name} is written as "modid"@.@"name" (Section~\ref{ids}).
 A qualified name is brought into scope:
 \begin{itemize}
 \item {\em By a top level declaration.}
@@ -456,26 +520,21 @@ the qualified name of the entity being defined.  Thus:
     g x = M.f x x
 @
 \eprog
-is legal.  The {\em defining} occurrence must mention the unqualified name, however; it is
+is legal.  The {\em defining} occurrence must mention the {\em unqualified} name; therefore, it is
 illegal to write
 \bprog
 @
   module M where
-    M.f x = ...
+    M.f x = ...                        -- ILLEGAL
+    g x = let M.y = x+1 in ... -- ILLEGAL
 @
 \eprog
 \item {\em By an @import@ declaration.}  An @import@ declaration, whether @qualified@ or not,
-always brings into scope the qualified names of the imported entity (Section~\ref{import}).
-\end{itemize}
-
-The qualifier does not change the syntactic treatment of a name;
-for example, @Prelude.+@ is an infix operator with the same fixity as the 
-definition of @+@ in the Prelude (Section~\ref{fixity}).
-
-Qualifiers may also be applied to
-names imported by an unqualified import; this allows a qualified
+always brings into scope the qualified name of the imported entity (Section~\ref{import}).
+This allows a qualified
 import to be replaced with an unqualified one without forcing changes
 in the references to the imported names.  
+\end{itemize}
 
 
 \subsubsection{Name clashes}
@@ -543,7 +602,7 @@ the following module is legal:
 The local declaration for @sin@ is
 legal, even though the Prelude function @sin@ is implicitly in
 scope. The references to @Prelude.sin@ and @F.sin@ must both be qualified
-to make it unambigous which @sin@ is meant. However, the unqualified
+to make it unambiguous which @sin@ is meant. However, the unqualified
 name "@sin@" in the type signature in the first line of @F@ unambiguously
 refers to the local declaration for @sin@.
 
@@ -554,7 +613,7 @@ refers to the local declaration for @sin@.
 Every module in a \Haskell{} program must be {\em closed}.  That is,
 every name explicitly mentioned by the source code
 must be either defined locally or imported from another module.
-Entities that the compiler requires for type checking or other
+However, entities that the compiler requires for type checking or other
 compile time analysis need not be imported if they are not mentioned
 by name.  The \Haskell{} compilation system is responsible for finding
 any information needed for compilation without the help of the
@@ -609,11 +668,11 @@ functions, called the ``Standard Prelude.''  In
 \Haskell{}, the Prelude is contained in the
 module @Prelude@.\indexmodule{Prelude} There are also
 many predefined library modules, which provide less frequently used
-functions and types.  For example, arrays, 
-tables, and most of the input/output are all part of the standard
+functions and types.  For example, complex numbers, arrays, 
+and most of the input/output are all part of the standard
 libraries.    These are 
-defined in the Haskell Library Report\cite{libraries},
-a separate document.  Separating
+defined in Part~\ref{libraries}.
+Separating
 libraries from the Prelude has the advantage of reducing the size and
 complexity of the Prelude, allowing it to be more easily assimilated,
 and increasing the space of useful names available to the programmer.
@@ -625,34 +684,30 @@ This means, for example, that a compiler may optimize calls to
 functions in the Prelude without consulting the source code
 of the Prelude.
 
-\subsubsection{The @Prelude@ Module}
+\subsubsection{The \texorpdfstring{@Prelude@}{Prelude} Module}
 \indexmodule{Prelude}
 \index{Prelude!implicit import of}
 
-The @Prelude@ module is imported automatically into 
-all modules as if by the statement `@import Prelude@', if and
-only if it is not imported with an explicit @import@ declaration.
-This provision for explicit import allows values defined in the
-Prelude to be hidden from the unqualified name space.  The
-@Prelude@ module is always available as a qualified import: an
-implicit `@import qualified Prelude@' is part of every module and 
-names prefixed by `@Prelude.@' can always be used to refer to entities in the
-Prelude.
-
-The semantics of the entities in @Prelude@ is specified by an
+The @Prelude@ module is imported automatically into all modules as if
+by the statement `@import Prelude@', if and only if it is not imported
+with an explicit @import@ declaration. This provision for explicit
+import allows entities defined in the Prelude to be selectively imported,
+just like those from any other module.
+
+The semantics of the entities in @Prelude@ is specified by a reference
 implementation of @Prelude@ written in \Haskell{}, given in
-Appendix~\ref{stdprelude}.  Some datatypes (such as @Int@) and
+Chapter~\ref{stdprelude}.  Some datatypes (such as @Int@) and
 functions (such as @Int@ addition) cannot be specified directly in
 \Haskell{}.  Since the treatment of such entities depends on the
-implementation, they are not formally defined in the appendix.
+implementation, they are not formally defined in Chapter~\ref{stdprelude}.
 The implementation of
 @Prelude@ is also incomplete in its treatment of tuples: there should
 be an infinite family of tuples and their instance declarations, but the
 implementation only gives a scheme.
 
-Appendix~\ref{stdprelude} defines the module @Prelude@ using
+Chapter~\ref{stdprelude} defines the module @Prelude@ using
 several other modules: @PreludeList@, @PreludeIO@, and so on.
-These modules are {\em not} part of Haskell 98, and they cannot be imported
+These modules are {\em not} part of Haskell, and they cannot be imported
 separately.  They are simply 
 there to help explain the structure of the @Prelude@ module; they
 should be considered part of its implementation, not part of the language
@@ -691,20 +746,23 @@ affect the meaning of these special constructs.  For example, in
 \bprog
 @
   module B where
-    import qualified Prelude
+    import Prelude()
     import MyPrelude
-      ...
+    f x = (x,x)
+    g x = (,) x x
+    h x = [x] ++ []
 @
 \eprog
-@B@ imports nothing from @Prelude@, but the
-explicit @import qualified Prelude@ declaration prevents the automatic
-import of 
-@Prelude@.  @import MyPrelude@ brings the
-non-standard prelude into scope.  As before, the
-standard prelude names are hidden explicitly.  Special
-syntax, such as lists or tuples, always refers to prelude entities:
-there is no way to redefine the meaning of @[x]@ in terms of a
+the explicit @import Prelude()@ declaration prevents the automatic
+import of @Prelude@, while the declaration @import MyPrelude@ brings the
+non-standard prelude into scope.  
+The special syntax for tuples (such as @(x,x)@ and @(,)@) and lists
+(such as @[x]@ and @[]@) continues to refer to the tuples and lists
+defined by the standard @Prelude@;
+there is no way to redefine the meaning of @[x]@, for example, in terms of a
 different implementation of lists.
+On the other hand, the use of @++@ is not special syntax, so it refers
+to @++@ imported from @MyPrelude@.
 
 It is not possible, however, to hide @instance@ declarations in the
 @Prelude@.  For example, one cannot define a new instance for @Show Char@.
@@ -737,6 +795,7 @@ an ADT for stacks could be defined as:
 \eprog
 Modules importing @Stack@ cannot construct values of type @StkType@
 because they do not have access to the constructors of the type.
+Instead, they must use @push@, @pop@, and @empty@ to construct such values.
 
 It is also possible to build an ADT on top of an existing type by
 using a @newtype@ declaration.  For example, stacks can be defined
@@ -746,7 +805,7 @@ with lists:
   module Stack( StkType, push, pop, empty ) where
     newtype StkType a = Stk [a]
     push x (Stk s) = Stk (x:s)
-    pop (Stk (x:s)) = Stk s
+    pop (Stk (_:s)) = Stk s
     empty = Stk []
 @
 \eprogNoSkip