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

```Nevermind, AFAICT it's s always the case that
catchError m throwError = m

On Sat, 10 Sept 2022, 19:41 Alexandre Esteves, <
alexandre.fmp.esteves at gmail.com> wrote:

> 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