Skip to content

Error.Class: add convenice lifting functions #140

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

Merged
merged 1 commit into from
Jul 11, 2021

Conversation

hexagonal-sun
Copy link
Contributor

Add functions that allow Either and Maybe to be easily lifted to a
MonadThrow monad.


Checklist:

  • Added the change to the changelog's "Unreleased" section with a reference to this PR (e.g. "- Made a change (#0000)")
  • Linked any existing issues or proposals that this pull request should close
  • Updated or added relevant documentation
  • Added a test for the contribution (if applicable)

@hexagonal-sun hexagonal-sun force-pushed the monadThrow-lift-fns branch from cdcd375 to ff1dc48 Compare June 4, 2021 21:54
@JordanMartinez
Copy link
Contributor

I can see why you'd want to use this, but I don't see why it should be merged into this library. Is there a precedent for this elsewhere?

@hexagonal-sun
Copy link
Contributor Author

@JordanMartinez Thanks for taking a look.

Haskell's MTL does provide liftEither for lifting Either values into the MonadError monad. Interestingly, I can't seem to find a similar function for lifting Maybe values in hackage. However, if we're providing lifting functions for Either values, why not also provide them for Maybe values?

@JordanMartinez
Copy link
Contributor

@hexagonal-sun Thanks for clarifying! In that case, I think it makes sense to add the liftEitherM and liftMaybeM functions to this repo. I'm not sure about the flipped version of liftMaybeM though.

I don't think we should add an infix for liftMaybeM.

@hexagonal-sun hexagonal-sun force-pushed the monadThrow-lift-fns branch from ff1dc48 to 8ef85dc Compare June 5, 2021 20:31
@hexagonal-sun
Copy link
Contributor Author

@JordanMartinez Great! No problem, I've removed those functions.

@thomashoneyman
Copy link
Member

What do y'all think of liftEither / liftMaybe instead of liftEitherM / liftMaybeM? iirc we don't usually include the M postfix.

@JordanMartinez
Copy link
Contributor

We sometimes do include the M prefix. Consider

@thomashoneyman
Copy link
Member

I’m thinking more of the liftEffect, liftAff variety in this case, though you’re right that we do sometimes use the suffix.

@JordanMartinez
Copy link
Contributor

Since Haskell uses liftEither, we should probably follow suit with naming these liftEither/liftMaybe. This is a case where I don't think following Haskell is wrong and it'll help others who are already familiar with Haskell's liftEither.

@hdgarrood
Copy link
Contributor

I think the M suffix is only appropriate when there already exists a version of the function without the suffix, which is less monad-y.

Add functions that allow `Either` and `Maybe` to be easily lifted to a
MonadThrow monad.
@hexagonal-sun
Copy link
Contributor Author

Agreed. I've changed the function names as discussed.

@hexagonal-sun
Copy link
Contributor Author

If this could get merged, that would be great! Thanks.

@JordanMartinez JordanMartinez merged commit 254c3f2 into purescript:master Jul 11, 2021
@JordanMartinez
Copy link
Contributor

Thanks for the reminder!

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.

4 participants