[Haskell] base libraries

[Simon Peyton-Jones]

I've elaborated the Wiki to try to articulate the choice that Ian describes here; it's in direct tension with Bulat's goals.

Simon

| -----Original Message-----
| From: Ian Lynagh [mailto:igloo at earth.li]
| Sent: 24 November 2006 19:35
| To: Simon Peyton-Jones
| Cc: Bulat Ziganshin; Malcolm Wallace; libraries at haskell.org
| Subject: Re: Re[2]: [Haskell] base libraries
|
| 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