13

The general question is which module structure is more convenient when adding instances for existing objects? Which pros and cons there are?

Let's say I want to add NFData instance for Seq type. I can place it in:

  • Data.Sequence.Extra (as the same thing is done in the vty package)
  • Data.Sequence.Instances.NFData (more precise)
  • Control.DeepSeq.Instances
  • Control.DeepSeq.Instances.Sequence

It's the case when I don't own neither the type class nor the data type. The other common situation is when I own a type type class and want to add instances for data type(s) from some "heavy" package from Hackage, like OpenGL. Let's say the type class I designed is very light and has no direct relation to OpenGL. I don't want my type class depend on "heavy" package, so I want to place OpenGL instances in a separate module (it's my intuitive feeling, if you have other opinion, let's discuss it). So, what this module should be:

  • MyClass.Instances.OpenGL
  • Graphics.Rendering.OpenGL.Extra (together with instances for other classes)
  • Graphics.Rendering.OpenGL.Instances.MyClass

What is more flexible solution? At some point OpenGL can be replaced with other library, or MyClass can be replaced too. Are there any subtle nuances?

Also, which scheme is better if choose MyClass.Instances variant:

  • MyClass.Class module for the class itself and basic instances and MyClass module reexports it (and maybe MyClass.Instances)
  • MyClass module for the class and basic instances, and MyClass.All reexports everything
  • MyClass module for the class and basic instances and no module for reexporting.
modular
  • 1,099
  • 9
  • 22
  • What you are doing is called "orphan instances" and is considered evil because they make it easy to define multiple instances of the same class for the same type and make otherwise good libraries incompatible with each other. There was that other question discussing them in detail: http://stackoverflow.com/questions/3079537/orphaned-instances-in-haskell . – Rotsor Jul 10 '11 at 14:29
  • For Rotsor's problem - a "general" library shouldn't be in the business of implementing instances for classes / datatypes that it doesn't define. It's fine for a private library or an executable / application to do this - but a public library shouldn't do it. For the original problem - the problem is not really where in the namespace the instance is defined but that there can be more than one library providing an instance. The best solution is probably to have "instances" packages on Hackage where developers provide canonical instances for classes / datatypes outside Base. – stephen tetley Jul 10 '11 at 14:50
  • @Rotsor, that's a good point (while there is no common opinion at the comment at the link). Does it follow from there that when I own a type class, I shall tie instances to it? – modular Jul 10 '11 at 14:53
  • @stephen tetley, I don't see how your suggestion of 'no orphan instances in libraries' is compatible with '"instances" packages on Hackage'. I see this as an open problem for Haskell community. @user713303, as you said yourself, there is no consensus on this, so do what you feel is right, but be aware of the possible problems (orphan instance nightmares vs. unnecessary dependencies). – Rotsor Jul 10 '11 at 15:34
  • Hi @Rotsor - I said no orphans in "general" libraries, so VTY shouldn't define an instance of Deepseq for Data.Sequence (qualification - I'm not sure it does in the package on Hackage). It's fine for "instance" packages to provide instances - it's their job e.g. http://hackage.haskell.org/package/fixed-point-vector which provides Data.Vector instances for Data.Fixed. – stephen tetley Jul 10 '11 at 15:50

1 Answers1

13

The usual process of deciding where to put an instance goes something like this:

  1. If you're making a new data type and want an instance for an existing class:

    Put the instance in the same module as the data type.

  2. If you're making a new type class and want to make instances for existing types.

    Put the instances in the same module as the type class.

  3. Both the type class and the data type already exist (your case).

    If the instance is sufficiently general, I'd contact the author of either the type class or the data type and try to convince them to add the instance in their package.

    Otherwise, create a newtype wrapper and write an instance for that.

    Only as a last resort consider making an orphan instance.

hammar
  • 138,522
  • 17
  • 304
  • 385