monad library
Alastair Reid
alastair@reid-consulting-uk.ltd.uk
Thu, 31 Jul 2003 18:08:59 +0100
> Hmmm, they account for less than 3% of the object code
> of the base package, and requiring "-package monad" would immediately
> break lots of build scripts out there. I'm not sure if this is a good
> deal...
I think a world with many small packages is better than one with a few large
packages^* so I think we should move stuff out of the base package but, as we
do so, we should look for ways to make the number of packages more
manageable. Some ideas:
1) Package management systems could provide a package grouping feature
where you can define groups like:
good_stuff = haskell98 + base + posix + network
This kind of thing is common in Debian packages. For example,
installing the 'kde' package sucks in 50-100 other packages like
mailers and editors.
2) Instead of specifying which packages you want when you invoke the
compiler, the compiler could automatically give you all you have
installed.
This is probably what Hugs is going to do and will work as long as
the hierarchial namespace is used to avoid name conflicts instead of
using packages to avoid name conflicts.
We will also have to make sure that our package mechanism has effective
version-dependency features and that package descriptions use them. This
is partly a technical issue and partly a social one.
--
Alastair
* My view that many small packages is better than a few big ones partly
comes from my experience with Debian which does this very well.
Although Redhat does have packages too, people tend to rely more on
getting a fresh redhat CD (cf. installing the latest GHC with all the
libraries it includes) so package granularity, accuracy of version
dependencies isn't so important and, I think, doesn't receive
as much attention as if it was relied on and tested by many people
per day.
People with experience of more monolithic systems (and who want
Haskell packages to be that way too), should speak up.