Skip to content
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

Closed
wants to merge 15 commits into from
Closed

HoistFail #7

wants to merge 15 commits into from

Conversation

lrworth
Copy link

@lrworth lrworth commented Aug 23, 2023

Adds a new typeclass HoistFail analogous to HoistError but for hoisting into MonadFail. This is concretely useful for writing aeson and cassava parsers; both of these libraries use MonadFail to support parse errors, and our parsers tend to be littered with variations of either fail pure.

To support common use cases I've added some functions with mnemonic suffixes:

  • a family of functions ending with ', which simplify hoisting from different monads with the same error type
  • a family of functions with E in the suffix, which set the input monad to Either to support hoisting from types where the monad is polymorphic.

@endgame
Copy link

endgame commented Aug 27, 2023

I would be OK with dropping support for ancient GHC.

src/Control/Monad/Fail/Hoist.hs Outdated Show resolved Hide resolved
src/Control/Monad/Fail/Hoist.hs Outdated Show resolved Hide resolved
`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.
@lrworth lrworth marked this pull request as ready for review August 28, 2023 02:02
Comment on lines +79 to +81
-- '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
Copy link
Author

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.

Copy link

@endgame endgame left a 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".

src/Control/Monad/Error/Hoist.hs Outdated Show resolved Hide resolved
@lrworth
Copy link
Author

lrworth commented Aug 30, 2023

I wonder if the basic design of this library could be better?

Sounds great, but it'll be a breaking change so should happen in a different PR.

@JackKelly-Bellroy
Copy link

In the spirit of "make the hard change easy, then make the easy change", I think we should look at the InspectError refactor first.

In particular this meant the operators didn't work with Maybe.
@JackKelly-Bellroy JackKelly-Bellroy mentioned this pull request May 3, 2024
@endgame endgame closed this in #8 May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants