Difference between revisions of "Orphan instance"
(short introduction) |
(Either is not an orphan in base 4.6) |
||
| (12 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| ⚫ | |||
| − | == Question == |
||
| + | 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. |
||
| − | What is an Orphan instance and why is it bad? |
||
| + | 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. |
||
| − | == Answer == |
||
| + | 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. |
||
| ⚫ | |||
| + | ==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 |
||
== See also == |
== See also == |
||
| + | * [[Multiple instances]] |
||
| − | * Libraries mailing list on [http://www.haskell.org/pipermail/libraries/2008-August/010399.html |
+ | * Libraries mailing list on [http://www.haskell.org/pipermail/libraries/2008-August/010399.html Orphan instances can be good] |
| + | * [http://www.haskell.org/pipermail/haskell-cafe/2011-July/094014.html Ideas] on possible compiler warnings for coping with orphan instances |
||
| + | * Libraries mailing list on [http://www.haskell.org/pipermail/libraries/2012-September/018398.html Relaxin the PVP with regards to adding instances] |
||
| + | * [http://modula3.elegosoft.com/pm3/pkg/modula3/src/discussion/partialRev.html Partial Revelation feature] of Modula-3 which causes similar problems like Haskell's type class instances |
||
[[Category:FAQ]] |
[[Category:FAQ]] |
||
| + | [[Category:Style]] |
||
Revision as of 14:07, 21 August 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.
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.
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
See also
- Multiple instances
- Libraries mailing list on Orphan instances can be good
- Ideas on possible compiler warnings for coping with orphan instances
- Libraries mailing list on Relaxin the PVP with regards to adding instances
- Partial Revelation feature of Modula-3 which causes similar problems like Haskell's type class instances