Proposal: deepseq should not depend on containers
igloo at earth.li
Thu Jan 6 19:15:10 CET 2011
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
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?
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
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?
More information about the Libraries