Why the Prelude must die
sebastian.sylvan at gmail.com
Sun Mar 25 12:20:23 EDT 2007
On 3/25/07, David House <dmhouse at gmail.com> wrote:
> On 25/03/07, Ian Lynagh <igloo at earth.li> 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
> 2. To make including literals sane
> 3. Other basic functions
> Ord((<), (>), (<=), (>=))
> 4. Miscellaneous
> 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.
More information about the Libraries