Re: Proposal: deepseq should not depend on containers

Am 29.12.2010 18:36, schrieb Johan Tibell:

On Wed, Dec 29, 2010 at 2:41 PM, Christian Maeder wrote:

...

I don't think, that orphaned instances can be avoided in the long run. Therefore I would rather see a separate package for the NFData instances of container types.

Why not? The general recipe is to define type classes in separate packages so they can appear on the bottom of the dependency pyramid.

classes and data types are usually created independently and one cannot expect all data type maintainers to continuously adapt their packages to provide instances for new classes. Will the next step be to move the Binary instances from the binary package to containers, too? (There are plenty of other serialization classes!)

That way any package that defines a data type can depend on the package that defines the type class and thus avoid creating orphan instances.

Surely, non-orphaned instances ensure the existence of a single instance.

Orphan instances should be avoided as they can cause hard to prevent and hard to fix breakages in large code bases.

The problem with large code bases are only duplicate orphaned instances that are added only as non-separated parts of other code. If all code would be based on the same instances (provided by a central package on hackage!) I see no problem. The question is what package granularity we want. I think a larger group of instances makes sense to put into an extra package. Avoiding orphaned instances obviously enforces less granular dependencies for either classes or data types. If NFData is such an important class it should go into the base package. Since other data types depend on base anyway, then there is no need to change the dependency from "base" to "base, deepseq" for many data packages. Is it possible to find out where (if) NFData instances of container types are actually used (for hackage packages)? Cheers Christian

Johan