[Haskell] base libraries
simonpj at microsoft.com
Fri Nov 24 12:35:31 EST 2006
In the wiki page that Simon and I put up, we attempt to identify
* terminology (E.g. Core Packages, Hugs Install Packages, etc)
and we make a straw-man proposal for how to proceed.
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.
| -----Original Message-----
| From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org] On Behalf Of Bulat
| Sent: 24 November 2006 16:29
| To: Malcolm Wallace
| Cc: libraries at haskell.org
| Subject: Re: [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 at gmail.com
| Libraries mailing list
| Libraries at haskell.org
More information about the Libraries