[Haskell-cafe] Why the Prelude must die

Robert Dockins robdockins at fastmail.fm
Sat Mar 24 11:40:37 EDT 2007


On Saturday 24 March 2007 05:36, Sebastian Sylvan wrote:
> On 3/24/07, Chris Eidhof <chris at eidhof.nl> 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.
>
>
> That should take of most issues.

+1 for this opinion.  The presence/absence of the "module" declaration seems 
like a very nice way to separate the student/newbie/just-writing-a-quick-hack 
class of use cases from the library-maintainer/large-scale-program-author 
class of use cases.

Rob Dockins


More information about the Libraries mailing list