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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
