[Haskell] base libraries

[Ian Lynagh]

On Fri, Nov 24, 2006 at 05:35:31PM +0000, Simon Peyton-Jones wrote:
> 
> http://hackage.haskell.org/trac/ghc/wiki/PackageReorg
> 
> I'd be interested to know whether the proposal has general support;
> what goals are omitted; and what other details are omitted.  I'm sure
> there are many, because this is a complex issue.

I'd like to see some rationale for why each of the core packages have
been chosen.

I'd have

    base, haskell98, Cabal, filepath

with the rationale that it is likely that people will want to write
Setup.hs with them (haskell98 is debatable here, but could probably be
argued in on the grounds that it's needed for lots of
books/tutorials/... to work).

I can't really think of any rationale for any others. For
userfriendliness we can have a cabal package called usefulstuff that
depends on mtl, regex, ..., but I don't see any need to bundle them all
with the compiler.

The less we force the implementations to come with, the quicker
compilation will be when developing, the smaller Debian packages (for
example) can be, the lower the disk space requirements to build GHC, the
lower the time wasted when a Debian package (for example) build fails
and the fewer packages we are tangling up with compiler release
schedules (OK, they can be upgraded independently, but it causes
headaches for package-management systems).

On quickcheck, the testsuite and GHC: we can have GHC compile any
libraries that are put in libraries/ and make ./darcs-all --get-dev grab
quickcheck too. On the other hand, you might want to run the testsuite
automatically when building debs/rpms/... but personally I'd prefer to
use a copy of QC compiled and installed under the testsuite tree for
that. This way we wouldn't suffer from the disadvantages above. We don't
need the testsuite programs to work after GHC has been installed so we
don't have to worry about providing the QC dynamic libraries in the
future.


Thanks
Ian