Difference between revisions of "Multiple instances"
m |
m (type parameter order) |
||
| Line 1: | Line 1: | ||
== Question == |
== Question == |
||
| − | I like to define multiple [[type class instance]]s for the same pair of class and type |
+ | I like to define multiple [[type class instance]]s for the same pair of class and type. |
| − | How is it possible |
+ | How is it possible? |
== Answer == |
== Answer == |
||
| Line 12: | Line 12: | ||
since instance declarations are automatically imported and cannot be hidden. |
since instance declarations are automatically imported and cannot be hidden. |
||
Even more also modules which import conflicting modules only indirectly conflict itself. |
Even more also modules which import conflicting modules only indirectly conflict itself. |
||
| + | It is also not possible to define instances with respect to different type parameter orders, |
||
| + | as it is required for type constructor classes like <hask>Functor</hask>, <hask>Monad</hask>, and others. |
||
Thus multiple instances should be avoided, and a safe way to do this is to avoid orphan instances. |
Thus multiple instances should be avoided, and a safe way to do this is to avoid orphan instances. |
||
Revision as of 15:34, 20 January 2009
Question
I like to define multiple type class instances for the same pair of class and type. How is it possible?
Answer
You can achieve it if you keep class and type definitions in other modules than the instance declarations.
These instances are then called orphan instances.
However you won't be lucky with this solution, since you must ensure,
that two modules with conflicting instances declarations are never imported together,
since instance declarations are automatically imported and cannot be hidden.
Even more also modules which import conflicting modules only indirectly conflict itself.
It is also not possible to define instances with respect to different type parameter orders,
as it is required for type constructor classes like Functor, Monad, and others.
Thus multiple instances should be avoided, and a safe way to do this is to avoid orphan instances.
You can achieve this by wrapping the type in a newtype and lift all required instances to that new type.
If you do not fear language extensions you can simplify this task considerably using the GeneralizedNewtypeDeriving feature.
The custom instance can be defined for the class/newtype pair and it is not orphan, if it is defined where newtype is introduced.