Standard (core) libraries initiative: rationale

[Ian Lynagh]

On Mon, Nov 27, 2006 at 02:55:03PM -0800, David Roundy wrote:
> On Mon, Nov 27, 2006 at 10:28:09PM +0300, Bulat Ziganshin wrote:
> > [...]
> > and this leads us to other question - whether this set and API of each
> > library should be fixed in language standard or it can evolve during
> > the time?...
> 
> To me, this is the deciding issue.  The Haskell 98 libraries have some
> severe issues which are unfixable because they're defined as part of the
> standard.

Right, the problem is that there is a tension here between having the
ability to fix and evolve the libraries, and people wanting to write
books on how to use Haskell' (without having to define (+) and map etc
themselves).

We've been lucky thus far that having the hierarchial libraries
completely disjoint with the report has meant that we have been able add
to and alter things even in the base package without breaking anything
assuming Haskell98. We haven't had to worry about clashing with a user's
Data.Function module, or if adding an "on" function will cause
ambiguous-import errors in someone's program.

We still get the occasional person in #haskell asking why they can't
find the fromInt their book talks about, and I think that was probably
published in the 90s?

I've been pondering this all day, and I think my conclusion is that
books should be about "Haskell', base 3.0.* and mtl 2.1.*", and Haskell'
should say pretty much nothing about libraries (we'll probably want to
use things like head in examples, and talk about things like seq; hmm,
perhaps a very few functions like seq do belong in a package of their
own that Haskell' knows about, probably reexported elsewhere by the base
package).

This would be more reason for GHC to factor out the magic from base, as
it'll be possibly more important to be able to install base 3.0 and 4.1
simultaneously.


Thanks
Ian