Personal tools

Orphan instance

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(hints for avoiding orphan instances)
(making the presentation a bit more balanced with more related reading)
Line 17: Line 17:
   
   
A last advice:
+
==When Orphan Instances can be useful==
If you encounter a missing instance for a class or a type of a package,
+
It is worth noting that Orphan Instances can be viewed as a mechanism for writing modules of code with a fixed typed interface, but parameterized over the choice of implementation. In this case, Orphan Instances act as a sort of plugin architecture for providing alternative implementations with a uniform interface.
resist to define your own orphan instance, because it will likely collide with such instances of other packages,
 
or it will collide with new instances added in later versions of that package.
 
Instead ask the package author to add your instance.
 
Sometimes it turns out that the instance was not included for the good reason
 
that there is more than one reasonable instance definition.
 
If your instance cannot be included, follow the advices in the article about [[multiple instances]].
 
 
 
== Avoiding orphan instances ==
 
 
If you encounter an
 
<haskell>
 
instance C T
 
</haskell>
 
which is orphan, then you can try to
 
 
* move the instance declaration to the module defining class <hask>C</hask>,
 
* move the instance declaration to the module defining type <hask>T</hask>,
 
* wrap the type <hask>T</hask> in a custom type, like so
 
<haskell>
 
newtype N = N T
 
instance C N
 
</haskell>
 
* define a custom class (unlikely to be useful), like so
 
<haskell>
 
class C => S
 
instance S T
 
instance S X -- for all X where an instance C X already exist
 
</haskell>
 
* not use the class <hask>C</hask> at all.
 
   
  +
A basic treatment of the relationship between type classes and modules (in the SML sense of modules) can be found at http://www.mpi-sws.org/~dreyer/papers/mtc/main-short.pdf and http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf
   
 
== See also ==
 
== See also ==

Revision as of 06:39, 23 June 2013

An orphan instance is a type class instance for class C and type T which is neither defined in the module where C is defined nor in the module where T is defined.

Type class instances are special in that they don't have a name and cannot be imported explicitly. This also means that they cannot be excluded explicitly. All instances defined in a module A are imported automatically when importing A, or importing any module that imports A, directly or indirectly.

Say you want to define an alternative instance to an existing instance. This is a bad thing, since if two instances for the same class/type pair are in scope, then you cannot describe in Haskell 98 which instance to use. If you want to use multiple instances for the same class/type, you have to ensure that they are never imported together in a module somewhen. It is almost impossible to assert that, or put differently, it would reduce the composability of libraries considerably.

The
Monad
instance of
Either
is a good example. It is not defined where
Either
is defined, thus all of its
Monad
instances must be orphan. Instead it is defined both in
Control.Monad.Error
of the Monad Transformer Library and in
Control.Monad.Trans.Error
of its lightweight cousin the 'transformers' package.

Since some packages use MTL and others 'transformers' it becomes difficult to use that instance at all, although both instances are equivalent! Practical advice:

The explicit-exception package with its
Exceptional
might be a better choice to use since it avoids the current problem with orphan Monad instances of
Either
.

Actually, non-orphan instances can avoid definition of multiple instances. For defining an instance you have to import the class and the type and then you will automatically have the according non-orphan instances imported, too. If you want to define a new instance then the compiler will reject it immediately.


1 When Orphan Instances can be useful

It is worth noting that Orphan Instances can be viewed as a mechanism for writing modules of code with a fixed typed interface, but parameterized over the choice of implementation. In this case, Orphan Instances act as a sort of plugin architecture for providing alternative implementations with a uniform interface.

A basic treatment of the relationship between type classes and modules (in the SML sense of modules) can be found at http://www.mpi-sws.org/~dreyer/papers/mtc/main-short.pdf and http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf

2 See also