On Fri, Mar 03, 2006 at 11:46:30AM +0000, Simon Marlow wrote:

I just had an interesting idea though: if a package could re-expose modules from a dependent package, then we could provide a new view of the base package with the GHC.* modules hidden. This is tantalising, because it seems easy to implement... I must think about this some more.

FWIW, this is what I plan to allow in jhc for just that reason. (it would also allow the reexporting module to be re-optimized with a smaller world assumption, with the caveat being possible code duplication for programs that use Jhc.* directly) although jhc libraries and ghc packages arn't quite the same, they are pretty similar in most user-visible ways. John -- John Meacham - ⑆repetae.net⑆john⑈

Malcolm Wallace wrote:

Simon Marlow wrote:

...

I almost suggested removing Text.Printf, but it seems too small to put in a package of its own and I don't know where else to put it :-)

Is there some "ideal" package size? If one module is too small, but the current size of the base package is too large...

Heh. Good question. Packages are the unit of versioning, distribution, licensing, and a few other things. Given this, you put the boundaries where they are most useful: if you want to version and upgrade a set of modules as a unit, then it makes sense to make them a package. If a set of modules is under a particular license, then they have to be packaged separately from modules under different licenses. There are a bunch of practical issues to deal with too, though. Too many tiny packages would get confusing. Huge packages take a long time (and a lot of memory) to compile, and generate huge library files, which take a long time to link against. Recursive module dependencies determine boundaries to some extent, because packages can't be mutually recursive. So by "too large" I mean too large mainly for practical reasons, any by "too small" I mean that the unit doesn't really merit having a package all to itself, because it wouldn't be useful.

A separate 'text' package seems like a useful concept, to accumulate various textual file formats and text-processing libraries. How about it initially contains these:

Text.Html Text.Regex Text.PrettyPrint.* Text.ParserCombinators.* Text.Printf

Sounds good. I was wondering about putting Text.Regex into a separate regex package. Text.ParserCombinators.ReadP is required to be in base at the moment, BTW. Cheers, Simon