Re: libraries in hugs/nhc

Good, so I propose to create a separate package (collections?) where we'll put the AVL-tree based collection types, plus the code they are based on. I will do this next week, provided I have the rights to create a new package on darcs.haskell.org Later on Data.Set/Map/IntSet/IntMap shall be moved to that package. Cheers, JP. On 3/1/06, Simon Marlow wrote:

On 28 February 2006 16:47, Adrian Hey wrote:

...

On Tuesday 28 Feb 2006 9:46 am, Jean-Philippe Bernardy wrote:

...

On 2/27/06, Simon Marlow wrote:

...

I didn't see the start of this discussion, but I'd question whether AVL should go into the base package. What's the goal here?

See my other reply to Ross. Text quoted below.

A (better) alternative is of course to put this in its own package. This is in line with the "decentralisation" idea indeed. I even say we should put the existing Data.Map/Set; etc. into that package; so "base" become lighter.

To be honest it's never been too clear to me what the long term plans are for library distribution and the base package.

As far as possible I think we should extract non-essential code from the base package. The main constraint on base is that it must contain enough to be able to implement the Prelude. There's a lot in there that doesn't fit that criteria. If Prelude gets smaller in Haskell', then base can be reduced even further (splitting out the I/O library, perhaps).

The minimum we can ship GHC with is those libraries required to bootstrap GHC itself (any less would cause undue difficulties, I think). This set is currently: base, haskell98, template-haskell, unix, Cabal, readline.

Ideally it should be configurable which packages are included in a GHC build, so that systems with a good package manager (Debian, Gentoo, FreeBSD etc.) can provide a minimal GHC and deliver further (Haskell) packages as separate OS-managed packages. For some distributions, such as the plain binary distribution, we will probably want to ship GHC with a larger set of libraries by default.

It has been at the back of my mind to think about this reorg at some point. The main technical hurdle is that we really need to build the libraries with Cabal, and that needs some extra support in Cabal.