[Haskell-cafe] Why the Prelude must die

[Neil Mitchell]

Hi

Reducing to just haskell-cafe - since this isn't yet a concrete
proposal - more just a discussion.

> 1. Namespace pollution

Do you want to overload (.) ? I think its good that some names mean
standard things. Maybe not as many as the prelude, but some standard
things are good.


> This is a highly non-academic concern.  Many widely used libraries,
> such as Parsec, operate only on lists and not the newer and more
> efficient sequence types, such as bytestrings.

Lists in Haskell are the nicest data structure, they work most
naturally with the language. There is a reason that lists is the
default.


> 3. Supports obsolete programming styles

Niggle: nub isn't in Prelude, it's Data.List

> More damagingly, the Prelude encourages programmers to use
> backtracking parsers.  Moore's law can save you from nub, but it will
> never clarify "Prelude.read: no parse".

This is very bad!

> 5. Inflexibility
>
> Because of Haskell's early binding, the Prelude always uses the
> implementation of modules that exists where the Prelude was compiled.
> You cannot replace modules with better ones.

I think this is a good thing - I can imagine people changing map to
also do a reverse, then changing it retroactively in an existing
program/library. They should at least be forced to recompile.


> 6. Dependency

Could not agree more! If additionally your compiler is written in a
silly way, you can make this problem 100 times worse for yourself.

> 13. There can be no escape

I still like the Prelude.

> 14. My future
>
> 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 would then provide "Common" or something, which just imported and
exported Control.Function/Data.List and the other common modules. This
would probably be better for scripts (I often end up importing
Data.List, System.Directory, System.Process), and would make larger
programs more explicit.

If Common was provided as a replacement, which was more general than
the Prelude, then you could do that easily. With a tiny bit of work I
think you could replicate Prelude and add flags as required.

Of course, I think technically this would be a lot of work - just
fighting with dependencies, bugs, make systems, silly compilers etc.

Thanks

Neil