Alexandre Esteves alexandre.fmp.esteves at gmail.com
Sat Sep 10 18:41:23 UTC 2022

```How about instead a distributive law of sorts:
catchError (m >>= f) h
= catchError (catchError m throwError >>= f) h

On Sat, 10 Sept 2022, 01:56 David Feuer, <david.feuer at gmail.com> wrote:

> Sorry, I mangled that. I meant
>
> catchError (m >>= f) h = catchError (Right <\$> m) (pure . Left) >>=
>   either h ((`catchError` h)  . f)
>
>
> On Fri, Sep 9, 2022, 8:49 PM David Feuer <david.feuer at gmail.com> wrote:
>
>> I agree. These are still insufficient for much reasoning, however. I
>> would intuitively expect that
>>
>> catchError (m >>= f) h = catchError (Right <\$> m) (pure . Left) >>=
>>   either throwError ((`catchError` h)  . f)
>>
>> But I have no idea whether all "reasonable" instances obey that.
>>
>> Is there anything useful to say about the case when the argument to
>> mapError is sufficiently nice (a monad morphism with some extra property,
>> for instance?
>>
>> On Fri, Sep 9, 2022, 5:43 PM Alexandre Esteves <
>> alexandre.fmp.esteves at gmail.com> wrote:
>>
>>> I ran into a scenario where the use of MonadError would only be valid if
>>>   catchError (pure a) h = pure a
>>> was a law, so I looked up the laws in
>>> but surprisingly found none.
>>>
>>> One would expect to see
>>>   1. catchError (pure a) h = pure a
>>>   2. catchError (throwError e) h = h e
>>>   3. throwError e >>= f = throwError e
>>>
>>> which would rule out silly instances like
>>>   instance MonadError () Maybe where
>>>     throwError ()        = Nothing
>>>     catchError _ f = f ()
>>>
>>> Searching for "monad error laws" gives me no haskell results, only
>>> suggests the same laws.
>>>
>>> AFAICT the IO/Maybe/Either/ExceptT instances in
>>> all obey the laws.
>>> _______________________________________________
>>> Libraries mailing list