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.