_______________________________________________Sorry, I mangled that. I meantcatchError (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 thatcatchError (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 awas 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 see1. catchError (pure a) h = pure a
2. catchError (throwError e) h = h e3. throwError e >>= f = throwError ewhich would rule out silly instances likeinstance 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
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries