[Haskell] base libraries

[Simon Peyton-Jones]

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 at haskell.org [mailto:libraries-bounces at haskell.org] On Behalf Of Bulat
| Ziganshin
| Sent: 24 November 2006 16:29
| To: Malcolm Wallace
| Cc: libraries at 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 at gmail.com
|
| _______________________________________________
| Libraries mailing list
| Libraries at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries