...

I thought the master plan was that less would come with the compiler / interpreter and the user would install packages using cabal.

Ideally, yes. I think a useful model would be GNU/Linux, where there is the Linux kernel, developed by core hackers, and then there are "distributions", which package up particular kernels with a load of different GNU libraries and utilities to form a complete operating environment. The maintainers of the distributions do not work on the kernel, but they do test their own combinations of kernel/libraries + utilities to ensure that everything plays together nicely.

I would like to see the same separation forming between the ghc compiler itself (which would minimally include only the small number of libraries needed to build the compiler), and larger "distributions" which would be maintained by other people, and include much larger collections of packages that the maintainer has tested and verified to work together. In the best of all worlds, a Haskell "distribution" would include multiple compilers, not just ghc.

i think that such separately maintained distributions would be one way to avoid the version skew chaos that might otherwise result from dropping all but the minimal set of libraries from ghc/hugs/.. distributions. now everybody take a step back to make room for the volunteers?-) a slightly more lightweight approach, that could grow into the above, would be if cabal packages supported nesting/grouping, so that sets of useful/proven libs could be bundled into a single package (the whole package builds if all the subpackages build individually, and form a coherent whole; that is, there'd need to be tests checking that the subpackages are actually compatible versions). then, instead of extra-libs in ghc/hugs/.., there'd be a standard-libs package on hackage showing exactly which haskell implementations it builds&tests with successfully and which not. and one could still get a whole consistent and maintained? bunch of standard libs in one go. </dream> claus