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