replacing the Prelude (again)

[Bernard James POPE]

Malcolm writes:
> Bernie writes: 
> > I did wonder how Hat tackled this.
> > Out of curiosity what is the solution that Hat uses?
> 
> Hat doesn't have a solution.  When the lack of correct defaulting
> causes Hat to generate type-incorrect code, the underlying compiler
> will complain vociferously.  Our advice to users is to write `default
> ()' at the top of the module, then resolve the type errors they
> get from the normal compilation so that defaulting is completely
> eliminated.  The code will then go through Hat smoothly.
> 
> It isn't very satisfactory, but in practice, defaulting doesn't
> really occur very often, so it isn't too much of a hardship.

That was going to be my fallback strategy, I'm glad I'm not the only one!

> > This adds an extra element of difficulty to the problem. I am trying
> > my hardest to avoid needing the to import the original Prelude in 
> > a transformed module - this requires quite a bit of desugaring in the
> > transformation. 
> > 
> > For what reasons do you require the original prelude? 
> 
> Exactly the same reasons.  We want to do as little desugaring as
> necessary in the transformation, so inevitably we need at least a
> small part of the Prelude in scope.

I would like to use do-notation in the transformed program, but have it
refer to Prelude.Monad and not MyPrelude.Monad which is also in scope.

The reason I mention this is that the behviour of -fno-implicit-prelude seems to
have changed with respect to desugaring do notation, at least according to
this post from Simon Peyton-Jones:
  
   http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003688.html

   In the upcoming 5.04 release you'll be able to do exactly
   that.  GHC will use whatever >>= is in scope if you say
   -fno-implicit-prelude.

Sure I can always get by without do notation, but the transformed program is
then a lot uglier and harder to comprehend. 

Does hat work with ghc 5.04?

Cheers,
Bernie.