Re: [Haskell-cafe] Why the Prelude must die

On Mar 24, 2007, at 2:36 AM, Sebastian Sylvan wrote:

On 3/24/07, Chris Eidhof wrote:

...

...

Given all these issues, I consider the only reasonable option is to discard the Prelude entirely. There will be no magic modules. Everything will be an ordinary library. HOFs like (.) are available from Control.Function. List ops come from Data.List. Any general abstractions can be added in abstract Sequence, Monad, etc. modules. Haskell will regain the kind of organic evolution whose lack currently causes Haskell to lose its lead over Python et al by the day. I basically agree with a lot of the things you say. The only thing is: it's so convenient to have the Prelude. I can just start writing my haskell programs and don't have to worry about all kinds of imports. And you'll end up being repetitive: you'll import (.) and stuff like that in _every_ file. Yeah, this will definitely be more modular, but if we go for it, it's going to be so much more (tedious) work to create a new program.

The solution is simple:

* If there is a "module M where" clause in the beginning of the file, then it's a "proper" module and shouldn't import the Prelude. * If there is no module declaration then it's a "quick'n dirty script" and should have the Prelude implicitly imported. * Interactive interpreters should probably import the Prelude. So if I'm writing a script, which has been working, then import Control.Monad, it all suddenly stops working?

I also think that you want to minimize the differences between an interpreted (interactive) version and a compiled version. It would be very weird for first-time users if their scripts work in ghci but break when they compile them. I'm sorry for being so negative. I like the idea, but I don't like it from a newbie-standpoint. The thing is: this is mostly handy for power-users, maybe we should do it for power-users only? We can still change the prelude to have no more code in there, but make it only a bunch of imports? -chris