simonmarhaskell at gmail.com
Fri Mar 3 12:15:04 EST 2006
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
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:
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.
More information about the Libraries