Fix reference to "Haskell 98"
[haskell-report.git] / report / modules.verb
index 23d4358..46cd095 100644 (file)
@@ -1,5 +1,5 @@
 %
 %
-% $Header: /home/cvs/root/haskell-report/report/modules.verb,v 1.6 2001/08/23 16:16:57 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
 %
 %**<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,
 \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
 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$
 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
 @main@ is performed, and its result (of type $\tau$) is discarded.
 
 Modules may reference other modules via explicit
@@ -69,20 +69,36 @@ Because they are allowed to be mutually recursive,
 modules allow a program to be partitioned freely without regard to
 dependencies.
 
 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 modules by default (see Section~\ref{standard-prelude}), plus a
 set of standard library modules that may be imported as required
 There is one distinguished module, @Prelude@, which is imported into
 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
 
 \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
 
 @@@
 module -> @module@ modid [exports] @where@ body
@@ -91,27 +107,22 @@ body   -> @{@ impdecls @;@ topdecls @}@
        | @{@ 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{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
 \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 import declarations ("impdecls", Section~\ref{import}) and
-top-level declarations ("topdecls", 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}
 
 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}
 
 @@@
 \index{export list}
 
 @@@
-exports         -> @(@ export_1 @,@ ... @,@ export_n [ @,@ ] @)@ & \qquad (n>=0)
+exports         -> @(@ export_1 @,@ ... @,@ export_n [ @,@ ] @)@ & (n>=0)
 
 export   -> qvar
 
 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
 
          |  @module@ modid
 
-qcname   -> qvar | qcon
+cname   -> var | con
 @@@
 \indexsyn{exports}%
 \indexsyn{export}%
 @@@
 \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
 
 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,
 \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
 Operators should be enclosed in parentheses to turn them into
-"qvarid"'s.  
+"qvarid"s.  
 
 \item
 An algebraic datatype "T"
 
 \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 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.  
 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}
 \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
 
 \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
 \index{type synonym}
 
 \item
@@ -189,64 +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
 \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}
 \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
 
 \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
 @
 \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@.  
 
 @
 \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
 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
 @
 \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
 @
 \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}
 \end{enumerate}
+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
 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) or (6)).  
+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
 @
 
 The {\em unqualified} names of the entities exported by a module must all be distinct
 (within their respective namespace).  For example
 \bprog
 @
-  module A ( module B, C.f, 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
 @
 \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}
 
 \subsection{Import Declarations}
 \label{import}
@@ -255,20 +293,20 @@ module @A@.
 @@@
 impdecl   -> @import@ [@qualified@] modid [@as@ modid] [impspec]
          |     & (empty declaration)
 @@@
 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
 
 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 @(..)@
 cname     -> var | con
 @@@
 %             var
 %          |  tycon
 %          |  tycon @(..)@
-%          |  tycon @(@ con_1 @,@ ... @,@ con_n@)@ & \qquad (n>=1)
+%          |  tycon @(@ con_1 @,@ ... @,@ con_n@)@ & (n>=1)
 %          |  tycls @(..)@
 %          |  tycls @(..)@
-%          |  tycls @(@ var_1 @,@ ... @,@ var_n@)@ & \qquad (n>=0)
+%          |  tycls @(@ var_1 @,@ ... @,@ var_n@)@ & (n>=0)
 \indexsyn{impdecl}%
 \indexsyn{impspec}%
 \indexsyn{import}%
 \indexsyn{impdecl}%
 \indexsyn{impspec}%
 \indexsyn{import}%
@@ -291,6 +329,11 @@ 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.
 
 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}
 
 \subsubsection{What is imported}
 \label{whatisimported}
 
@@ -327,6 +370,9 @@ 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.  
 
 any constructor, class, or type named @C@ is excluded.  In contrast,
 using @C@ in an import list names only a class or type.  
 
+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 
 all the entities exported by the specified module are imported.
 \item
 Finally, if "impspec" is omitted then 
 all the entities exported by the specified module are imported.
@@ -351,19 +397,21 @@ 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:
 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
 \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
 
   succ = (Prelude.+ 1)
 @
 \eprog
-
+}
 
 \subsubsection{Local aliases}
 \label{as-clause}
 
 \subsubsection{Local aliases}
 \label{as-clause}
@@ -421,7 +469,7 @@ Import declaration & Names brought into scope \\
   @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 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(x) as B@           & @B.x@ \\
+  @import A as B(x)@           & @x@, @B.x@ \\
   @import qualified A as B@    & @B.x@, @B.y@ \\
 \hline
 \end{tabular}
   @import qualified A as B@    & @B.x@, @B.y@ \\
 \hline
 \end{tabular}
@@ -448,9 +496,9 @@ declarations can have an empty export list.  For example
 @
   module MyInstances() where
     instance Show (a -> b) where
 @
   module MyInstances() where
     instance Show (a -> b) where
-       show fn = "<<function>>"
+      show fn = "<<function>>"
     instance Show (IO a) where
     instance Show (IO a) where
-       show io = "<<IO action>>"
+      show io = "<<IO action>>"
 @
 \eprog
 
 @
 \eprog
 
@@ -460,7 +508,6 @@ declarations can have an empty export list.  For example
 \label{qualifiers}
 
 A {\em qualified name} is written as "modid"@.@"name" (Section~\ref{ids}).
 \label{qualifiers}
 
 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.}
 A qualified name is brought into scope:
 \begin{itemize}
 \item {\em By a top level declaration.}
@@ -484,11 +531,10 @@ illegal to write
 \eprog
 \item {\em By an @import@ declaration.}  An @import@ declaration, whether @qualified@ or not,
 always brings into scope the qualified name of the imported entity (Section~\ref{import}).
 \eprog
 \item {\em By an @import@ declaration.}  An @import@ declaration, whether @qualified@ or not,
 always brings into scope the qualified name of the imported entity (Section~\ref{import}).
-\end{itemize}
-Qualifiers may also be applied to
-names imported by an unqualified import; this allows a qualified
+This allows a qualified
 import to be replaced with an unqualified one without forcing changes
 in the references to the imported names.  
 import to be replaced with an unqualified one without forcing changes
 in the references to the imported names.  
+\end{itemize}
 
 
 \subsubsection{Name clashes}
 
 
 \subsubsection{Name clashes}
@@ -556,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
 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@.
 
 name "@sin@" in the type signature in the first line of @F@ unambiguously
 refers to the local declaration for @sin@.
 
@@ -622,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
 \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 
 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.
 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.
@@ -638,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.
 
 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}
 
 \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 @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
 
 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
 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.
 
 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.
 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
 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
@@ -704,20 +746,23 @@ affect the meaning of these special constructs.  For example, in
 \bprog
 @
   module B where
 \bprog
 @
   module B where
-    import qualified Prelude
+    import Prelude()
     import MyPrelude
     import MyPrelude
-      ...
+    f x = (x,x)
+    g x = (,) x x
+    h x = [x] ++ []
 @
 \eprog
 @
 \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.
 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@.
 
 It is not possible, however, to hide @instance@ declarations in the
 @Prelude@.  For example, one cannot define a new instance for @Show Char@.