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, because the default definition of fail is error, which would
render the Monad instance useless (unless I'm missing something?).
You would just use Left instead of 'fail' if you want to show failure in an Either value.
a) you are suggesting to bypass a method of the proposed Monad
instance because it isn't useful, I am suggesting not to define a
Monad instance with unusable methods
b) desugaring of pattern-match failure in Monads calls fail, not Left
Claus
PS. I just remembered that I have used 'Monad (Either a)', for
'a' other than String (a parser with error information in addition
to plain error message). That application didn't use
Control.Monad.Errror or Control.Monad.Instances - it could
have been made to fit the current Control.Monad.Error design
but not the proposed design, because it relied on
'fail s `mplus` return x == return x'.
A reasonable case can be made for the existence of a monad that does something useful with fail. I don't think that that monad should be Either.
'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.
The obvious name for such a monad would be Error, to go with ErrorT, but the Error class conflicts with that name, but perhaps:
data Fail e a = Error e | OK a
would be worth adding to Control.Monad.Error, during the same general timetable as this change, to provide users who really want the existing mtl Either semantics an upgrade path.
In the interest of not killing this proposal with bikeshedding concerns over what to call it (Fail, Err, Error, etc), we should probably put that forward as a completely separate libraries proposal though.
It would address the confusion caused to new users who often on #haskell ask why 'Left' is the error case, and would address your use case explicitly, and even less verbosely. ;)
-Edward Kmett