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

On 3/25/07, David House wrote:

On 25/03/07, Ian Lynagh wrote:

...

I've submitted:

http://hackage.haskell.org/trac/haskell-prime/ticket/124

which I hope covers the essence of the result of this thread.

I'd hate to have to import things like Data.Function for such trivial functions as (.) and ($), which are so often used that they become almost like control structures and keywords in themselves. What did people think of my idea of a stripped down prelude containing primarily the functions like (.) and ($)? Here'd be my list:

1. Almost like control structures otherwise (.) flip ($)

2. To make including literals sane Char String Int Integer Num(..)

3. Other basic functions Eq(..) Ord((<), (>), (<=), (>=)) Show(show)

4. Miscellaneous id const undefined

Of course, the precise details would be debateable.

I think I like this proposal. Perhaps without 2 though (unless Num and String gets some attention). I'm not sure the "not automatically imported if proper module" rule is needed if the Prelude gets stripped down a bit, but I wouldn't mind it (it makes sense to make imports explicit in "proper" modules). So to summarize what I perceive to be the issues: * Do we want a new Prelude, or just hide the existing one? (I want a new, stripped down version) * Should this new Prelude be automatically included always, or should it be hidden in "proper modules" (I'm ambivalent). * Should there be a larger backwards compatible Prelude (I think Yes) * Shold this larger Prelude be implicitly imported for non-proper modules? (I think no, it should always be explicitly imported, perhaps through command line options) With regards to the first point, I think it's a misstake to just have "Large Prelude which is not implicitly imported" because everytime you need (.) or ($) people would probably just "import Prelude" and then you're stuck with the old problem again. So I do think stripping down the Prelude is essential. I think this is a separate issue that can be agreed upon regardless of the issue of wether it should be implicitly imported or not. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862