-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HoistFail #7
HoistFail #7
Conversation
Useful to fix the type of the monad so that it works with polymorphic functions.
I would be OK with dropping support for ancient GHC. |
`hoistFailE` and co mean you don't have to use type applications as often, so order doesn't matter as much. The alternative to this was changing the order of `HoistError` params for consistency, but this would not be backward-compatible and would require a major version bump.
-- 'hoistError' :: 'MonadError' e m => (() -> e) -> 'Maybe' a -> m a | ||
-- 'hoistError' :: 'MonadError' e m => (a -> e) -> 'Either' a b -> m b | ||
-- 'hoistError' :: 'MonadError' e m => (a -> e) -> 'ExceptT' a m b -> m b |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has been a long time coming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I keep wondering, "what if the new typeclasses aren't necessary?" From there, I wonder if the basic design of this library could be better?
The core class of hoist-error
is:
class Monad m => HoistError m t e e' | t -> e where
hoistError :: (e -> e') -> t a -> m a
It tells us which error/partiality functor t
is in play (e.g., Maybe
, Either e
, ExceptT e m
), what the error type e
is for t
(Maybe
-> ()
; Either e
-> e
) and which error type is used by the monad m
. If we separate the ideas of "identifying the error" and "hoisting the error into some other monad", then maybe we can avoid rewriting all machinery for MonadError
and MonadFail
. Perhaps something like this?
class InspectError e t m | t -> e where
inspectError :: t a -> m (Either e a)
instance Applicative m => InspectError () Maybe m where
inspectError = pure . \case
Nothing -> Left ()
Just a -> Right a
instance Applicative m => InspectError e (Either e) m where
inspectError = pure
instance InspectError e (ExceptT e m) m where
inspectError = runExceptT
hoistError :: (MonadError e' m, InspectError e t m) => (e -> e') -> t a -> m a
hoistError f = either (throwError . f) pure <=< inspectError
hoistFail :: (MonadFail m, InspectError e t m) => (e -> String) -> t a -> m a
hoistFail f = either (fail . f) pure <=< inspectError
I'd probably put the InspectError
class in Control.Monad.Error.Hoist
, put all the fail
-based machinery in Control.Monad.Fail.Hoist
, and then everything should "just work".
Sounds great, but it'll be a breaking change so should happen in a different PR. |
In the spirit of "make the hard change easy, then make the easy change", I think we should look at the |
In particular this meant the operators didn't work with Maybe.
Adds a new typeclass
HoistFail
analogous toHoistError
but for hoisting intoMonadFail
. This is concretely useful for writing aeson and cassava parsers; both of these libraries useMonadFail
to support parse errors, and our parsers tend to be littered with variations ofeither fail pure
.To support common use cases I've added some functions with mnemonic suffixes:
'
, which simplify hoisting from different monads with the same error typeE
in the suffix, which set the input monad toEither
to support hoisting from types where the monad is polymorphic.