replacing the Prelude (again)

[Bernard James POPE]

Hi again,

Malcolm writes:
> We came across the same problem in the Hat tracer (which is also a
> source-to-source transformation, and can also be used for debugging).
> 
> The problem is that the transformation introduces new classes, so
>     Prelude.Ord -> HatPrelude.Ord
>     Prelude.Eq  -> HatPrelude.Eq
>     Prelude.Num -> HatPrelude.Num
> 
> The defaulting mechanism *only* applies to types constrained by
> the original builtin Prelude.Num, not to the transformed class
> HatPrelude.Num.

I did wonder how Hat tackled this.

Out of curiosity what is the solution that Hat uses? And what is
the situation in nhc98?

> I think you are saying that if we
>     import HatPrelude as Prelude
> together with -fno-implicit-prelude in GHC, then defaulting should work
> over the HatPrelude classes rather than the Prelude ones?

That's what I had hoped for. 

> Unfortunately, in Hat at least, we continue to use the original
> Prelude in *addition* to the replacement HatPrelude.  

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. Still, I would like to be able to use do notation and
have it refer to Prelude.Monad, not MyPrelude.Monad. I can live without
it of course.

For what reasons do you require the original prelude? 

Cheers,
Bernie.