In the wiki page that Simon and I put up, we attempt to identify * goals * terminology (E.g. Core Packages, Hugs Install Packages, etc) and we make a straw-man proposal for how to proceed. 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 also think it'd be helpful to use a common terminology; we propose one on the wiki. Let's use it -- or choose an alternative. As ever, discussion by email; design choices, alternative proposals, pros & cons etc can go on the wiki. Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Bulat | Ziganshin | Sent: 24 November 2006 16:29 | To: Malcolm Wallace | Cc: libraries@haskell.org | Subject: Re[2]: [Haskell] base libraries | | Hello Malcolm, | | Friday, November 24, 2006, 6:36:03 PM, you wrote: | | >> In 6.6 you can, in theory, upgrade the base package. | | > This, I think, is the heart of Bulat's complaint: namely, that until | > recently it was not possible to upgrade the 'base' package in ghc. | | as i many times said, the problem is two-sided: first, Base can't be | upgraded without upgrading ghc. second, Base contains many different | functionality which is artificially tied together. this has cumulative | effect. for example, i want to use old arrays and new foreign ptrs | both with 6.4 and 6.6. there are no technical problems here - both | arrays and fptrs implementations don't rely on compiler version | specific apis. but due to this tieing, i should use old arrays and old | array with 6.4 and new ones with 6.6. this leads to #ifdefs in program | as far as i want to support both ghc versions and to poor performance | with 6.4 | | | > All the other implementations of Haskell do permit the base package to be | > upgraded (or downgraded) separately from upgrading the compiler itself. | | never known about it! but it is only theoretical advantage - while | Base developed as all-in-one package, we don't have any real upgrade | offers on this market | | | > All of the questions about whether such-and-such a library belongs in | > the 'base' package or in some separate package, are questions of policy. | > The answers really don't matter quite so much, provided the mechanism | > exists to choose to install whatever version of whatever packages you | > like. | | unfortunately, it's not enough. it easy part of problem, but we | should also work on splitting Base into natural parts. currently, it's | more than 2 megs. maintainable parts should be about 100-300k, i | think. rather obvious splitting is at upper level of module names: | Control, Data, so on. Another possible criterion is that everything | which can be detached from Base should be extracted and put into | separate library | | | -- | Best regards, | Bulat mailto:Bulat.Ziganshin@gmail.com | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries