New subject: [Haskell-cafe] Why the Prelude must die

24 Mar 2007

      This is a ranty request for comments, and the more replies the better.

1. Namespace pollution

The Prelude uses many simple and obvious names.  Most programs don't
use the whole Prelude, so names that aren't needed take up namespace
with no benefit.

2. Monomorphism

The Prelude defines many data types (e.g Lists), and operations on
these types.  Because the Prelude is imported automatically,
programmers are encouraged to write their programs in terms of
non-overloaded operators.  These programs then fail to generalize.

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.

3. Supports obsolete programming styles

The Prelude uses, and by means of type classes encourages, obsolete
and naive programming styles.  By providing short functions such as
nub automatically while forcing imports to use sets, the Prelude
insidiously motivates programmers to treat lists as if they were sets,
maps, etc.  This makes Haskell programs even slower than the inherent
highlevelness of laziness requires; real programs use nub and pay
dearly.

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".

4. Stagnation

Because every program uses the Prelude, every program depends on the
Prelude.  Nobody will willingly propose to alter it.  (This is of
course Bad; I hope Haskell' will take the fleeting opportunity to
break to loop)

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.

6. Dependency

Because every module imports the Prelude every module that the Prelude
depends on, mutually depends with the Prelude.  This creates huge
dependency groups and general nightmares for library maintainers.

7. Monolithicity

Every module the Prelude uses MUST be in base.  Even if packages could
be mutually recursive, it would be very difficult to upgrade any of
the Prelude's codependents.

8. Monolithic itself

Because the Prelude handles virtually everything, it is very large and
cannot be upgraded or replaced piecemeal.  Old and new prelude parts
cannot coexist.

9. One-size-fits-all-ism

Because the Prelude must satisfy everyone, it cannot be powerful,
because doing so would harm error messages.  Many desirable features
of Haskell, such as overloaded map, have been abandoned because the
Prelude needed to provide crutches for newbies.

10. Portability

Because the Prelude must be available everywhere, it is forced to use
only least-common-denominator features in its interface.  Monad and
Functor use constructor classes, even though MPTC/FD is usefully far
more flexible.  The Class_system_extension_proposal, while IMO
extremely well designed and capable of alleviating most of our class
hierarchy woes, cannot be adopted.

11. Committeeism

Because the Prelude has such a wide audience, a strong committee
effect exists on any change to it.  This is the worst kind of
committeeism, and impedes real progress while polluting the Prelude
with little-used features such as fail in Monad (as opposed to
MonadZero) and until.

12. There is no escape

Any technical defect in Map could be fixed by someone writing a better
Map; this has happened, and the result has been accepted.  Defects in
the PackedString library have been fixed, with the creation and
adoption of ByteString.  Defects in System.Time have been fixed, by
the creation and adoption of Data.Time.  Ditto for Binary and Arrays
and Network and Regex.  But this will never happen for the Prelude.  A
replacement Prelude cannot be adopted because it is so easy to take
the implicit import of the default one.  Nobody will go out of their
way to 'import Prelude() ; import FixedPrelude'.  Psychology trumps
engineering.

13. There can be no escape

The Prelude was designed by extremely smart people and was considered
close to perfect at the time.  It is almost universally hated now.
Even if all the issues I describe could be fixed (which I consider
unlikely), the Prelude will almost certainly be hated just as
universally five years hence.

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.

Stefan

Why the Prelude must die

Stefan O'Rear

dons＠cse.unsw.edu.au

Chris Eidhof

Sebastian Sylvan

Chris Eidhof

David Menendez

Robert Dockins

Stefan O'Rear

Ashley Yakeley

Lennart Augustsson

Sven Panne

David House

Isaac Dupree

Claus Reinke

Ian Lynagh

David House

Ian Lynagh

David House

Sebastian Sylvan

Simon Marlow

David House

Jeffrey Yasskin

David House

tags

participants (15)