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

Edward Kmett ekmett at gmail.com
Tue Jun 29 18:32:51 EDT 2010


On Tue, Jun 29, 2010 at 6:13 PM, Claus Reinke <claus.reinke at talk21.com>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, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100629/3b0fed84/attachment.html


More information about the Libraries mailing list