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.