library reorganisation

[Simon Marlow]

Malcolm Wallace wrote:
> Simon Marlow <simonmarhaskell at gmail.com> 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