RE: replacing the Prelude (again)

I'm fond of the idea proposed by Marcin 'Qrczak' Kowalczyk: | May I propose an alternative way of specifying an alternative Prelude? | Instead of having a command line switch, let's say that 3 always means | Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That's a perfectly reasonable idea, but GHC can't make it the default because it's not H98. It *would* be possible to make GHC's -fno-implicit-prelude flag mean that 3 means Prelude.fromInteger 3 rather than fromInteger 3 I quite like the fact that you would then have to say import MyPrelude as Prelude thereby stressing that you are importing the Prelude stuff. But it would be that *plus* -fno-implicit-prelude, I'm afraid. If there were a consensus in favour of this I'll gladly do it (5 min job). | anymore. What I would like is that the defualting rules refer | to the classes in my version of the Prelude, | not the Standard Prelude. You can always get that (with the -fno-implicit-prelude thing) by adding default [Int, Double] or whatever to your source module, just after the import that gets your new standard Prelude. Doesn't that do it? It would also not be hard to arrange that the "default default" declaration became scoped with -fno-implicit-prelude (like fromInteger), if that was useful. It's a good point; I thought that *all* the numeric stuff was un-coupled from the Prelude with -fno-implicit-prelude, but it isn't quite. Simon

| anymore. What I would like is that the defualting rules refer | to the classes in my version of the Prelude, | not the Standard Prelude.
You can always get that (with the -fno-implicit-prelude thing) by adding default [Int, Double]
or whatever to your source module, just after the import that gets your new standard Prelude. Doesn't that do it?
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 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? Unfortunately, in Hat at least, we continue to use the original Prelude in *addition* to the replacement HatPrelude. So how would defaulting work in the following? {-# -fno-implicit-prelude #-} import Prelude as Original import HatPrelude as Prelude default (Integer,Double) Regards, Malcolm
participants (2)
-
Malcolm Wallace
-
Simon Peyton-Jones