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. _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users