broken Monad Either instance?

Christian Maeder Christian.Maeder at dfki.de
Tue Nov 29 12:36:45 CET 2011


Am 28.11.2011 15:30, schrieb Ben Millwood:
>> Any comments (or notes) that I missed?
>>
>> Cheers Christian
>>
>
> It's not exactly a bug, it's a change in behaviour. Beforehand, there
> was no overlapping instance, the instance was just
> 'instance (Error e) =>  Monad (Either e) where' but the Error
> constraint proved to be more a hindrance than a help, since it
> prevented the instance being used with Left things that weren't
> Errors, even though that's often a useful thing to do. So it was
> agreed that the Error constraint should be removed, breaking 'fail'
> but making the instance much more generally applicable.

Was there a library proposal that I've missed? Does any release note 
mention this change?

Previously correct programs can now crash quite unpredictably without 
warnings!

> Overlapping instances could be added for individual types, but
> overlapping instances are usually considered to cause more problems
> than they solve – ambiguity can easily arise in polymorphic functions
> over Either.

> Either still works as Maybe with added information, except now you
> lose the do-pattern-matching magic. Sometimes I use something like
> this:
>
>> maybe (Left "oh no!") Right $ do
>>    x:xs<- Just blah
>>    [...]
>
> to use little bits of Maybe inside an Either do. Notice I get control
> of the error message here, too, so I can usually make it more useful.

My use case is (or better was) monadic code like:

   typeCheck :: Monad m => ... -> m (...)

where I used the "Either String" Monad instance to extract the fail 
messages:

   case typeCheck ... of
     Right ... -> ...
     Left ... -> ....

For this I now need another monad! Which one is recommended?

Cheers Christian



More information about the Libraries mailing list