Re: replacing the Prelude (again)
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 msg01816/pgp0.pgp Description: PGP signature
Re: Replacing the Prelude
On Sun, May 12, 2002 at 09:31:38PM -0700, Ashley Yakeley wrote: I have recently been experimenting writing code that replaces large chunks of the Prelude, compiling with -fno-implicit-prelude. I notice that I can happily redefine numeric literals simply by creating functions called 'fromInteger' and 'fromRational': GHC will use whatever is in scope for those names. I was hoping to do something similar for 'do' notation by redefining (), (=) etc., but unfortunately GHC is quite insistent that 'do' notation quite specifically refers to GHC.Base.Monad (i.e. Prelude.Monad, as the Report seems to require). I don't suppose there's any way of fooling it, is there? I was rather hoping 'do' notation would work like a macro in rewriting its block, and not worry about types at all. I accept that this might be a slightly bizarre request. There are a number of things I don't like about the way the Prelude.Monad class and 'do' notation are set up, and it would be nice to be able to experiment with alternatives. A while ago, there were extensive discussions about replacing the Prelude on this list. (Search for Prelude shenanigans.) I started to write up a design document for how to enable replacing the Prelude. This boiled down to taking most of the syntactic sugar defined in the report seriously, ignoring the types (as you say). I'm surprised that ghc uses the fromInteger and fromRational that are in scope; I thought there was general agreement that it should use the Prelude.from{Integer,Rational} in scope. As I recall, there were several relevant bits of syntactic sugar: - Numeric types, including 'fromInteger', 'fromRational', and 'negate'. This all works fine, except that the defaulting mechanism is completely broken, causing a number of headaches. - Monads. The translation given in the report is clean, and it seems like it can be used without problems. - Bools. There was a slight problem here: the expansion of 'if ... then ... else ...' uses a case construct referring to the constructors of the Bool type, which prevents any useful redefinition of Bool. I would propose using a new function, 'Prelude.ifThenElse', if there is one in scope. - Enumerations. Clean syntactic sugar. - List comprehensions. The report gives one translation, but I think I might prefer a translation into monads. - Lists and tuples more generally. At some point the translations start getting too hairy; I think I decided that lists and tuples were too deeply intertwined into the language to change cleanly. I'll dig up my old notes and write more, and then maybe write a complete design document and get someone to implement it. --Dylan Thurston msg01674/pgp0.pgp Description: PGP signature
RE: Replacing the Prelude
Ashley writes | I was hoping to do something similar for 'do' notation by redefining | (), (=) etc., but unfortunately GHC is quite insistent | that 'do' notation quite specifically refers to GHC.Base.Monad Dylan replies | I'm surprised that ghc uses the fromInteger and fromRational | that are in scope; I thought there was general agreement that | it should use the Prelude.from{Integer,Rational} in scope. Ashley is referring to a GHC extension. Normally, GHC uses Prelude.fromInteger etc, regardless of what is in scope. But if you say -fno-implicit-prelude, GHC will instead use whatver fromInteger is in scope. (This is documented in the manual.) Ashley's question, as I understand is whether something similar could be done for monads. Answer: I think so, without much bother. I'm beavering away on a Haskell workshop paper at the moment, but ping me in a fortnight to do it. Simon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe