> On 20-May-2000, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> > Of course, that doesn't solve the problem! Sergey essentially wants to
> > replace the entire prelude, special syntax and all. There are lots
> > of small but important things under the heading of special syntax:
If I recall correctly, several others have tried to produce alternative
preludes as well. Even more vaguely, I recall that Hugs at least used
to treat some prelude thingies in a very special way (so Prelude is not
just another module, implicitly imported), and that the combination
of both has led to some headaches.
The report seems to be slightly ambiguos in this regard: it explicitly
promotes the idea that the prelude is just another module and can
be replaced, but it also contradicts or qualifies this idea with lots of
special rules about references to the prelude.
It would be nice if it would be possible to pin down precisely which
parts of the Prelude fit in with the "it is just a preloaded module" story
and which parts have to be treated specially (the latter collection
should be made as small as possible, but may not be empty, simply
because we don't know better at the moment).
Currently, the report reserves the import name Prelude for the
module named Prelude (5.6.1), referring to both interchangably as
"the" prelude. This is also the case in section 5.6.2, which mentions
that special syntax always refers to prelude entities, and in paragraph
2 of section 5.6, which allows implementations to ignore the source
code of "the" prelude!
If we distinguish between module names and import names, special
syntax could refer to entities in the *module imported as Prelude*.
Alternatively, special syntax could refer to the *module named
Prelude*, independent of imports.
Personally, I don't like the "independent of imports" bit in the
second alternative, and the first alternative would allow for later
extensions that enable redefinitions of special syntax, even if we
don't offer that yet.
Also, I don't see the need for the implicit "import qualified Prelude"
(5.6.1). If I need items from the *module Prelude*, I can always
write something like "import qualified Prelude as P", and
implementations can optimize calls to the *module Prelude*,
independent of its *import name* (whether it is imported as
Prelude or as P).
By omitting the implicit "import qualified Prelude" and defining
special syntax as referring to the import name Prelude, we could
use existing syntax for prelude redefinitions:
module M where
import Prelude ()
import MyPrelude as Prelude
or even (if any import referring to either module *or* import name
Prelude would cancel the implicit "import Prelude"):
module M where
import MyPrelude as Prelude
I think the report currently allows this, but redefinitions of
Prelude.thing, if used in M, would conflict with the implicit "import
qualified Prelude" (which, unlike the implicit "import Prelude", is
always available, 5.6.1).
The second variant would also avoid the annoying uncontrolled import
of instances from the module named Prelude (but only if MyPrelude
doesn't do any imports from the module named Prelude..).
> > I don't think this would be too hard to implement in GHC. Now I think
> > about it, it's rather attractive. I wonder what other people think?
I always thought these things were special because implementations
depended on built-in knowledge about them, so this remark is rather
encouraging!-) Even if we cannot get rid of all "special magic", I
strongly support the idea to get rid of as much of it as we can.
If Ralf and your's current work on "generic default methods" would
be able to replace and generalize the "deriving" magic, that would be
another big step in the same direction.
Claus
PS
> > module M where
> > import Prelude ()
> > import {-# SYNTAX #-} MyPrelude
If there has to be a SYNTAX pragma, I would like to see it around
the definition of special syntax, not around the use.
