Proposal: deepseq should not depend on containers

[Simon Marlow]

On 05/01/11 22:10, Johan Tibell wrote:
> On Wed, Jan 5, 2011 at 9:24 PM, Ian Lynagh<igloo at earth.li>  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