#4159: move Monad and MonadFix instances for Either from mtl to base

Yitzchak Gale gale at sefer.org
Wed Jun 30 12:19:04 EDT 2010

Ross Paterson wrote:
>> The proposal is to move the Monad and MonadFix instances for Either
>> (currently in the mtl package) to Control.Monad.Instances and
>> Control.Monad.Fix respectively (both in the base package).  The Monad
>> instance is still an orphan, to retain Haskell 98 compatibility, but the
>> MonadFix instance is together with its class.  The Error constraint is
>> removed from both instances, and the default definition of fail is used.

+1 Yay!

Claus Reinke wrote:
> -1, because the default definition of fail is error, which would
> render the Monad instance useless (unless I'm missing something?).

It would certainly not render it useless. When using Either as an error
monad, the usual way to throw an error is with throwError if you are
using the MonadError class, or with Left if not.

At least on the surface, "fail" has nothing to do with the concept of failure
that Control.Monad.Error is modeling. Instead, it is referring to "failure
of a pattern match in the do-block variable binding syntax" (and its
extension to list comprehensions).

In my opinion, relying on a failed pattern match to result
in a Left value when using the Either monad for error processing
is poor programming technique. As is using the "pattern match
failure" function directly in place of throwError or Left.
There are plenty of better and safer ways to achieve polymorphism.
However, some may disagree, so that would be a downside
to this proposal. Even so, I am still strongly in
favor, for the reasons well-explained by Edward.

Another downside is that there may be some code out there
that does use the "pattern match failure" function in this way
(erroneously in my opinion). I am still strongly in favor.
However, it would be a good idea to search Hackage to get
an idea of the scope of the breakage ahead of
time, so that we can prepare for it.


More information about the Libraries mailing list