Hi all, Sorry to dig up an old topic, but I think this is an important one. (at least it is for me). I have run into a problem recently. I am writing a debugger for Haskell. It is based on a source-to-source transformation. The important bit is that the type of functions changes under the transformation. If you want to debug calls into the Standard Prelude (yes this is useful) then a transformed Prelude must be used. The idea being that a transformed program imports a transformed Prelude. That's okay, my debugger can transform all of the Standard Prelude since it is just a Haskell module (with provisions for primitive functions of course). The problem is that when I replace the Standard Prelude with a transformed Prelude the defaulting mechanism doesn't work anymore. What I would like is that the defualting rules refer to the classes in my version of the Prelude, not the Standard Prelude. I am using ghc version 5.03, and I don't think -fno-implicit-prelude can help here. I do think that this issue is independent of the Haskell environment, and more an issue of the design of the language. Now there have already been some discussions about replacing the Standard Prelude with a non-Standard Prelude. The trick being that a fair degree of the language definition makes use of things in the Standard Prelude. See for example: Dylan Thurston Replacing the Prelude http://www.haskell.org/pipermail/haskell-cafe/2002-May/003032.html Primitive types and Prelude shenanigans http://www.haskell.org/pipermail/haskell-cafe/2001-February/thread.html#1641 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 is, one could say: import Prelude () import MyPrelude as Prelude IMHO it's very intuitive, contrary to -fno-implicit-prelude flag. Presuming of course that defaulting would follow this path and refer to the new Prelude. I'm wondering if any further progress has been made towards this? Or perhaps someone can think of a temporary solution to my problem? Cheers, Bernie.
On Sat, Jul 13, 2002 at 07:58:19PM +1000, Bernard James POPE wrote:
... 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 is, one could say: import Prelude () import MyPrelude as Prelude IMHO it's very intuitive, contrary to -fno-implicit-prelude flag.
I don't agree with this, since the Haskell 98 standard explicitly contradicts it. I don't see what's wrong with a command line switch that would do this, anyway.
Presuming of course that defaulting would follow this path and refer to the new Prelude.
I never came up with a design that would allow this. Defaulting seems to be the one piece of the Haskell standard for which there is not yet a general solution. Although now that I think about it, if you could just specify which fromInteger you wanted (i.e., give that fromInteger a more specific type) the problem would go away. Perhaps that's really the better solution anyway: how often do people want to default to something that's not the first on the defaulting list? I think that might end up being less surprising to programmers, anyway. It might work as a temporary hack for you, anyway. (That is, add declarations like fromInteger :: Integer -> Int fromRational :: Rational -> Double in your new Prelude. This would work as long as users don't otherwise use fromInteger.) I don't know how you want to transform the types, but there are at least two areas where there are still special types: List and Bool. For List, I don't actually see any problem in principle with allowing other implementations of list comprehensions and whatnot, but Simon Peyton-Jones indicated that it would be difficult to actually implement; with Bool, one would need to define additional functions (like ifThenElse). Best, Dylan
participants (2)
-
Bernard James POPE -
Dylan Thurston