Hi Ian, The base package is still a large, unwieldy beast, making it hard to

develop and debug. If possible, I'd like to cut it down a bit more before the 6.10 release.

I won't inline all the details here, as it's a huge amount of text and an image, but basically I'm proposing to:

* Create packages: timeout, unique, concurrent, st, system, numeric, generics, version, getopt, debug, printf ghc-exts

I have a very strong request to name the "generics" package something else. The reason is that this not the only flavor of generic programming. Many others are available and/or will be made available. (We [1] are working on a few.) For example, if you go to the Hackage package list [2] and grep for "generic," you'll find a number of packages, not to mention Uniplate and Strafunski (a.k.a. StrategyLib). If you go to the wiki on research papers in the area of generics [3], you find a lot. Only 2 of those cover the Data.Generics library. Naming the package "generics" is deceiving, because it conveys that it is the only (or main) generics library. I would recommend calling it "syb," because that is its more popular name based on the research that has been done, esp. considering the continuing use of "Scrap Your ..." in titles. ;) As a side note, it appears that I am not the first person to say this. [4] Thanks, Sean [1] http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/WebHome [2] http://hackage.haskell.org/packages/archive/pkg-list.html [3] http://www.haskell.org/haskellwiki/Research_papers/Generics [4] http://hackage.haskell.org/trac/ghc/ticket/1338#comment:3

On Wed, 2008-08-06 at 21:37 +0100, Ian Lynagh wrote:

Hi all,

This is trac #1338: http://hackage.haskell.org/trac/ghc/ticket/1338#comment:14 http://hackage.haskell.org/trac/ghc/attachment/ticket/1338/packagegraph.png

Initial deadline: 21 Aug (2 weeks).

Generally this looks good if a little on the ultra-fine-grained side. If we can fold back a few of those tiny single-module packages that'd probably be good. I think we should not move the Applicative class however. It belongs in the same package as Functor and Monad (and we should be encouraging everything to be an instance of Applicative). Similarly, I think the Monoid class should stay in base. I don't care so much about the extra Monoid types currently defined in Data.Monoid but the class should stay. I don't think it makes any sense to put Monoid and Applicative in the containers package. They're almost completely unrelated. One reason is that classes (but not their instances) are common interfaces and so belong further down in the package dep graph. People tend to try to reduce package dependencies so making people depend on containers to give an applicative instance will mean that in many cases people simply will not. I'll let other people comment on Data.Foldable and .Traversable since I don't use them. Duncan