[Haskell-cafe] Why the Prelude must die
vivian.mcphail at paradise.net.nz
Sat Mar 24 22:14:05 EDT 2007
I agree with Sven, but...
What I want to push is a 'mathematically sound' numeric prelude. A proper
numerical prelude should have bona fide mathematical obects like groups,
rings, and fields underlying common numerical classes. It would be edifying
to the student who discovered that the particular data type he is using is
an inhabitant of a known class and can thus take advantage of known
properties, presupplied as class methods. Reasoning and communication about
programs, data types, and functions would be enhanced.
[Conjecture 1 (2007). Haskell Mathematical Prelude and Mathematicians] If
Haskell had a mathematically sound prelude then more mathematicians would
> Message: 1
> Date: Sat, 24 Mar 2007 17:56:11 +0100
> From: Sven Panne <sven.panne at aedion.de>
> Subject: Re: [Haskell-cafe] Why the Prelude must die
> To: haskell-cafe at haskell.org
> Cc: libraries at haskell.org
> Message-ID: <200703241756.11121.sven.panne at aedion.de>
> Content-Type: text/plain; charset="iso-8859-1"
> On Saturday 24 March 2007 03:48, Stefan O'Rear wrote:
> > 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
> > with no benefit. [...]
> Even though I think that the current Prelude is far from
> perfect, one should not forget that is a very solid
> foundation of a "common language": If one sees e.g. '(.)' or
> 'map', it is immediately clear to everybody what this means,
> without having to scan through (perhaps long) import lists.
> Of course one could hide some parts of the Prelude etc., but
> I think in the long run this only leads to confusion.
> Redefining common things, heavy use of tons of self-defined
> operators etc. all make maintenance much harder.
> Try reading Lisp code with heavy use of macros or C++ code
> with tons of overloadings. This is more like Sudoku solving
> than anything else, because there is no "common language"
> between the author and the reader anymore.
> And taking away the prelude is a little bit like taking away
> 'int', 'double', 'for', 'while' etc. from the C programmer...
> > 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.
> Depending on your viewpoint, you can see this as a plus.
> Everybody agrees that finalizers are evil, but propose the
> removal of that method from java.lang.Object to the Java people. :-)
> My proposal would be to incrementally improve the Prelude,
> modularize it a bit more, fix the Num hierarchy, but
> basically leave it as it is.
More information about the Haskell-Cafe