Proposal: Bounded instance for IntSet (ticket #1953)

[Yitzchak Gale]

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