monad library

Alastair Reid
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

   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.


* 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.