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