replacing the Prelude (again)
Bernard James POPE
Mon, 15 Jul 2002 23:21:45 +1000 (EST)
> 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
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?