Malcolm Wallace
One of the problems with the current mechanism for overriding Prelude definitions, is that every module that /uses/ such an entity must also explicitly hide the original Prelude:
I guess I don't quite understand what you are trying to achieve. Case one: existing project where you want to replace the Prelude Subcase a: the project already has a dummy module MyPrelude which just reexports the Prelude, and which is imported everywhere. - Great, all you need to do is modify MyPrelude! - Benefit from your proposal: you could skip import Prelude () from all .hs files (or -fno-implicit-prelude from your Makefile) - Drawback: anybody actually *do* this in real code without concrete plans for Prelude replacement? Subcase b: you don't have a MyPrelude. - Too bad, you need to modify all your .hs files *anyway* (Unless the good and benevolent secret keepers of the compiler code would implement a -fprelude-is MyPrelude switch) Subcase c: you want an alternative Prelude only in some of your files. Well, you are going to need to modify those files. At least you get to leave the rest alone. Case two: a new project with a different Prelude Well, if you're starting a new project, you can of course choose your own imports as you wish. Currently, the cost in one extra line in each file or the -fno-implicit option. I don't think saving one line from each file in projects using alternative Preludes justify adding one line to each file in projects using the standard Prelude. If there is any reason to think custom Preludes will outnumber the standard one, I'll change my mind. This sounds like yet another feature that is greatly interesting and wonderful to language hackers, and mostly annoying to the average programmer - partly by requiring extra overhead and boilerplate stuff, and partly by breaking old code. To summarize: * I don't think this is a good solution to name clashes; to use e.g. Set (and, hey, I agree with Okasaki and you that it should probably be used more instead of lists) I would need to use fine-grained imports management which adds administrative overhead. (A simple rename of a couple of offending identifiers would solve the problem. Why not 'isEmpty' instead of 'null', for instance?) * The standard Prelude is IMO going to be vastly more common than custom replacements. Custom Prelude users are also likely to be more accomplished Haskell programmers. Any administrative burden should be on the custom Prelude users. * That said, I'm all in favor of a switch to tell the compiler to use a custom module instead of the implicit Prelude. Or perhaps more generally: provide an implicit, project-wide import? Something like: ghc --make -fno-implicit-prelude -fimplicit-import MyPrelude Main.hs * Much of my resistance would go away if I had better tools to manage module interfaces more automatically. As it is now, import/export administration is already enough of a chore to be noticeable. -k -- If I haven't seen further, it is by standing in the footprints of giants