
Hello,
I agree with Johan that the dependency seems backward. "containers" is a
perfectly fine package but there is no reason to assume that everyone has
it. Consider, for example, a situation where I want to write a replacement
for "containers"---it would certainly be undesirable for my package to
depend on "containers".
-Iavor
On Wed, Jan 5, 2011 at 2:45 PM, Simon Marlow
On 05/01/11 22:10, Johan Tibell wrote:
On Wed, Jan 5, 2011 at 9:24 PM, Ian Lynagh
wrote: However, I think types in the GHC bootlibs should be an exception to this rule. Otherwise any classes that someone wants the bootlibs to have an instance for will need to be added to the bootlibs, and we'd like to keep the set of bootlibs as small as possible.
What would happen if GHC HQ find an interesting package on Hackage and put it in bootlib because they found it useful for GHC? Would that library author then not be allowed to add new dependencies to his/her package? I find that to be quite a weird model. Normally you don't get to dictate what the respective authors of packages you depend on do with their packages. (You can ask nicely of course.)
Of course we don't get to dictate. If the library grew some dependencies that we couldn't put in bootlibs we have two options: stop using the library in GHC, or carry on using the old version.
We already have one library like this: binary, which is shipped as ghc-binary so that users can install and upgrade binary without breaking GHC. The renaming is only necessary due to limitations in Cabal and the package system, which don't know that binary is only used internally in GHC and could safely be mixed with another version of binary without problems.
The reason I want to get rid of the container dependency is that I
don't want the data structure package I'm working depend on another data structure package that provides similar functionality. That seems, weird. I'd rather just skip the NFData instances.
It seems a little weird, but I don't think it has any undesirable consequences in practice, does it?
Cheers, Simon
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries