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