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

Specialization for IO? #6

Closed
jatcwang opened this issue Jun 30, 2024 · 6 comments · Fixed by #7
Closed

Specialization for IO? #6

jatcwang opened this issue Jun 30, 2024 · 6 comments · Fixed by #7

Comments

@jatcwang
Copy link
Contributor

Are you open to contributions for API specialized for IO? I want to make this as simple as possible to adopt for those using IO and suffering for EitherT

@ValdemarGr
Copy link
Owner

That is a good idea. The docs (README) would also be more concise 🎉

@ValdemarGr
Copy link
Owner

What does your idea for a simpler API entail? Something like import catcheffect.io.* maybe?

@jatcwang
Copy link
Contributor Author

jatcwang commented Jun 30, 2024

I've put in a very barebone PR in #7. Let me know what you think!

Some other unrelated ideas from my own prototyping:

Instead of Raise I named it Abort, and instead of a Raise#raise method, I have Abort#apply, which allows the following API:

def doSomething()(implicit abort: Abort[DomainError]): IO[String] = {
  for {
    _ <- ...
    _ <-  abort(DomainError.Err1(..))
  } yield ...
}

I think raise(DomainError.Err1(..)) will work well too but abort definitely catches my attention more 😄

@ValdemarGr
Copy link
Owner

ValdemarGr commented Jul 1, 2024

It looks nice to not have to wire a Catch instance through the whole application 👍

The naming and structure of the current algebra stems from cats-mtl.

Have you also handled naming for the IO-specialized instance of Handle in your prototype?

I don't think I have seen apply on an algebra before, I think Abort[F]("error") looks a bit funny, but maybe I have been trained to always expect a method after typeclass summoning 😃.

The only case of a specialized (and IO in fact) MTL typeclass is IOLocal, they also have another naming scheme for IO specialized datatypes here (a bit funny that one starts with IO[Local] and others end with [Outcome]IO).

Maybe we could add something akin to MTL extension methods?

// not entirely sure this works nice with type inference
extension [A](a: A)
  def abort[F[_], E >: A, C](using raise: Raise[IO, E]): IO[C] = raise.raise(a: E)

def doSomething()(implicit raise: Raise[IO, DomainError]): IO[String] = {
  for {
    _ <- ...
    _ <-  DomainError.Err1(..).abort
  } yield ...
}

This needs more work since there are 3 type parameters which I get the feeling will cause inference problems. This is how cats-mtl does it.

@jatcwang
Copy link
Contributor Author

jatcwang commented Jul 1, 2024

No I didn't have a equivalent for Handle. Was just a clean room minimal prototype and I needed an alternative name for Raise 😄

As for the extension methods, I think for readability I prefer "operation first", so R.raise(..) is fine to me.

If you're happy with the IO API I'll continue to polish it 👍 Thanks!

@ValdemarGr
Copy link
Owner

I think the current implementation looks good 👍.

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 a pull request may close this issue.

2 participants