Proposal: deepseq should not depend on containers

[Johan Tibell]

On Tue, Dec 28, 2010 at 11:03 PM, Alexander Dunlap
<alexander.dunlap at gmail.com> wrote:
> It seems like a huge number of packages depend on containers, and
> almost everyone seems to have it installed anyway, so I don't see what
> we gain by removing the dependency on containers.

Problems with the current state of affairs:

* The current NFData instances for the containers data types are
inefficient, as deepseq don't have access to the internals of the
containers package. For example, here's the Map instance

    instance (NFData k, NFData a) => NFData (Data.Map.Map k a) where
        rnf = rnf . Data.Map.toList

This causes unnecessary allocation of list cells.

In addition, the correctness of this definition assumes something
about how the Map data type looks like internally. Forcing the keys
and values might not be enough to fully evaluate a Map value. It
happens to work in this case but could break if the Map data type ever
added a non-strict field other than the one the holds the value.

* Having containers below deepseq in the dependency hierarchy slightly
increases the risk of diamond dependencies. Example:

1. A new major version of containers is released, version X.Y.
2. Package foo depends on containers-X.Y.* and the latest version of deepseq.
3. deepseq hasn't been updated yet so it depends on containers.X-1.Y.*

foo is now unbuildable as the containers constraints can't be satisfied.

* Why should containers be treated specially? Should deepseq depend on
all libraries that want to provide NFData instances?

* The dependency hierarchy gets weird. Why does text depend on
containers? It's logically at the same or a lower level than
containers.

Johan