Proposal: deepseq should not depend on containers

[Christian Maeder]

Am 29.12.2010 18:36, schrieb Johan Tibell:
> On Wed, Dec 29, 2010 at 2:41 PM, Christian Maeder
> <Christian.Maeder at dfki.de> 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