libraries in hugs/nhc

[Jean-Philippe Bernardy]

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 <simonmar at microsoft.com> 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 <simonmar at microsoft.com> 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.
>