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

Edward Kmett ekmett at gmail.com
Wed Jun 30 16:05:04 EDT 2010


On Wed, Jun 30, 2010 at 10:25 AM, Tyson Whitehead <twhitehead at gmail.com>wrote:

> On June 29, 2010 18:32:51 Edward Kmett wrote:
> > 'Either' takes on the connotation of being the 'sum type' for the
> category
> > of Haskell types. This sum type has a very well formed and simple monad,
> > that has a lot of useful theoretical properties, and is useful in a
> > strictly larger array of scenarios than the monad with the error
> > constraint, with the one notable exception that it doesn't handle the
> > 'fail' property that was bolted into Monad in Haskell 98.
>
> On the topic of 'fail' being an abomination, is there any hope of fixing
> this?
>

There was a hotly debated discussion about this during Haskell 98.

What happened was we lost the notion of 'failure free' patterns, and the
commitee at the time opted in favor of making it so that changing a pattern
wouldn't cause your type signature to change. In retrospect, this was
probably a bad idea. The cases where you want to pattern match on the left
hand side, you probably do want to know that your operation can fail.
Universally quantifying over Monad would then give you a guarantee that you
don't fail just due to desugaring, but then universal quantification wasn't
a tool in the toolchest at the time.

Erik Meijer fought the good fight trying to preserve the semantic purity of
"Monad", but ultimately was crushed under the press of bodies on the other
side of the debate.

I think this is one of those cases where Einstein's "Everything should be
made as simple as possible, but no simpler" rule was violated through excess
simplification. ;)

http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg03267.html

As with all bad things Monad, like the lack of Functor as a superclass, the
current situation is a result of a pile of perhaps pretty-bad-in-retrospect
decisions made at the time. (In the case of Functor it was seen as an extra
burden on the Monad implementor, but in practice, everyone who builds a
Monad builds it anyways, and with transformers, you don't 'roll your own'
nearly as often as you used to.)

I'd welcome the re-opening of both issues: fail and instance Functor m =>
Monad m, but those discussions are better reserved for Haskell 201x, since
changing it impacts support for Haskell 98.

-Edward Kmett


> Perhaps it could be pushed it into it's own type class, which would then
> required by the do notation?  Exactly like mdo required MonadFix.  I
> understand there was one called MonadZero for this at some time?
>
> I could see one route would be to add a compiler flag that would switch the
> do
> notation requirement from Monad to MonadZero.  Instances could then be
> added
> to code until at some point it could become the default.  A bit longer
> after
> that, it could be dropped altogether along with fail in the Monad class.
>
> Cheers!  -Tyson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100630/2a532ce0/attachment.html


More information about the Libraries mailing list