Henning Thielemann wrote:
...it is not sensible to have different instances for the same type and class, because they will collide sooner or later.
True. That is why libraries should not define an instance at all, unless they are quite certain that it is by far the most important instance that anyone will ever want to use. Here is an example: Control.Monad.Error defines a Monad instance for Either. I understand why that seemed sensible at the time. But the Either type is useful for many other things, too, and now it can *only* be used as an exception type in a monadic setting. If I had to pick just one usage for Either as a monad, it would be as an exit monad. I would use a different name for the exception monad, not the other way around. But now I'm stuck - if I want to use Control.Monad.Error at all, I have to use its crippled monad instance for Either.
I think there is no much sense in defining instances privately in code that uses a class definition from a library, because the custom instance in turn may break other modules. In the past it happened for me at each GHC upgrade, that instances that I defined privately (like Show for FiniteMap) collide with new instances defined in the imported standard module.
OK, so not only should libraries avoid defining instances - users should also think carefully before defining them. Because of this current limitation in Haskell's module system, instances are like the magic in the Sorcerer's Apprentice - very powerful, and unstoppable, for good and for bad. (This is ticket #19 in Haskell', marked as "maybe". Vote for issue 19!) Regards, Yitz