Re: n+k patterns, etc.

[hudak-paul]

  I think that we should try a different approach, forget about 

  the importing
  mechanism, and make a single statement defining the intended semantics.

  Section 1.2 (The Haskell Kernel) is the place. I propose adding the
  following.

  The translations given, and the identities given for the semantics of
  case expressions, are not macros. A simple replacement of the
  right-hand-side for the left-hand-side with substitution of parameters  
does
  not give the intended semantics. The reason for this is that the
  translations make use of certain names defined in the standard prelude  
(see
  section 5.4), and macro substitution could result in the capture of  
these
  names by locally defined entities, or the use of a name in a context in
  which it is not defined at all because the part of the prelude in which  
it
  is defined has not been imported. The general rule is: the use of a name
  defined in the standard prelude in a translation intended to show the
  semantics of a construct always implies the definition in the standard
  prelude.

  Then, people can locally rebind as much as they want, but the constructs
  defined by translation will be unaffected.
  

This sounds reasonable to me.  -Paul

Re: n+k patterns, etc.

[Simon L Peyton Jones]

|What if (the appropriate parts of) the standard prelude is
| explicitly *not* imported:
| 
|   import Prelude ()
| or
|   import Prelude hiding(map)
| 
| (see section 5.4.3).
| 
|Are then the hidden parts of the standard prelude still available via
| n+k patterns, list comprehensions etc.?  (Via some unseen and unhidable
| intermediary module.) Or are constructs that use hidden parts of the
| standard prelude (according to their translations given in the report)
| not available?

Yes.  No.  Respectively.

The Report is obviously not clear enough on this point. The wording given
for translations (eg list comprehensions) that "map" refers to the Prelude
"map" is meant to indicate that it refers to the Prelude "map" whether or
not the latter is explicitly in scope.  That's the consistent story for all
special syntax, to answer the latter part of your message.

Simon