Proposal: deepseq should not depend on containers

[Ian Lynagh]

On Thu, Jan 06, 2011 at 12:06:11PM -0500, Daniel Peebles wrote:
> Same here. Is it really that big a deal to add deepseq to the boot
> libraries?

Every extra boot library causes more headaches and work, and I don't see
any good motivation for adding deepseq.

The 'monoids' package declares instances for the containers types too;
should that become a bootlib?

And 'json'?

How about 'safecopy'?

> It seems like GHC might eventually want to use some of its own
> parallelism constructs for compilation, and then deepseq could be required
> anyway?

Like I said:

    If we decided to add NFData to bootlibs in its own right (e.g. if we
    wanted to use it in GHC or haddock) then reversing the dependency would
    make sense, but I don't think it's worth doing just for the sake of it.

> On Thu, Jan 6, 2011 at 11:23 AM, Iavor Diatchki <iavor.diatchki at gmail.com>wrote:
> 
> > 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.

It's a bootlib. It comes with GHC. It's a prerequisite for being able to
build the next GHC release. It's a dependency of the ghc package. It's
in the Haskell Platform. You can 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".

Like Simon said:

    It seems a little weird, but I don't think it has any undesirable
    consequences in practice, does it?


Thanks
Ian