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@earth.li] | Sent: 24 November 2006 19:35 | To: Simon Peyton-Jones | Cc: Bulat Ziganshin; Malcolm Wallace; libraries@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