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@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@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@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 https://hackage.haskell.org/package/mtl-2.3/docs/Control-Monad-Error-Class.html#t:MonadError 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 https://typelevel.org/blog/2018/04/13/rethinking-monaderror.html which suggests the same laws.

I propose adding these 3 laws to MonadError haddocks.
AFAICT the IO/Maybe/Either/ExceptT instances in https://hackage.haskell.org/package/mtl-2.3/docs/src/Control.Monad.Error.Class.html%20 all obey the laws.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries