Also, this doesn't mesh well with the portability notion in the new libraries proposal. The idea there is that certain libraries would be optional depending on whether the compiler implemented certain extensions - with your scheme this would have to be done at the package level.
Hmmm, my mental model of packages was a group of tightly coupled modules so I wasn't making this distinction.
Reasons to split groups of modules into packages: - to avoid polluting the module namespace (historical; not an issue with the new library scheme). - for separate distribution/installation - if you put all your code in one package, the .a library can get large which might slow down linking. Reasons not to use packages if you don't have to: - the user has to explicitly ask for a package (at least at the moment; it may be possible to remove this restriction in certain cases). - you can't have recursive dependencies between packages Additionally restricting a package to use a single set of extensions will probably be inconvenient both for the users and developers, at least for the core package.
I wanted to lump all the core libraries into a single package on GHC, but this would mean that package "core" for GHC would require a different set of extensions than the same package for NHC.
That's more because of conditional compilation than the library/package distinction right?
Hmmm, conditional compilation complicates the story for source packages. Choices:
o one package per combination of cpp flags
o one package with some sort of conditionals inside it:
deps = case COMPILER of __GHC__ => net, lang __NHC__ => lang __HUGS__ => greencard
Neither is very appealing. Is there an existing story for this sort of thing?
The second way seems to me to be the only option, if you want to go down this route. For example, some of the Monad libraries require MPTC, but I don't want to split these into a separate package - hence the core package requires MPTC. But NHC won't support these modules, so its core package will be different. It's more like conditional compilation at the module level - certain modules will just be omitted altogether for certain compiler/platform combinations. Some conditional compilation may additionally happen in the implementation, but the interface for a module should be static across all implementations that support it. Cheers, Simon