On Tue, Dec 28, 2010 at 11:03 PM, Alexander Dunlap
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