Re: Proposal: deepseq should not depend on containers

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 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