Re: library reorganisation

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