Prototype cats effect 2.0 about interop-cats HOT 10 CLOSED

@barambani
It's definitely relelant and would be highly appreciated!

from interop-cats.

I have been trying something in the past for a pet project of mine, so I would be happy to spend some time on this if it's still a relevant effort.

from interop-cats.

@barambani
We currently use a custom BIO* hierarchy instead of what should become CE 2, maybe useful as prior art: Split BIO into trait hierarchy, add conversions to cats-effect hierarchy

from interop-cats.

thanks @Kaishh , good help. 👍

from interop-cats.

@Kaishh (or @jdegoes but I know this is busy time), while playing around with some example I realised that I never use Guaranteed2.guarantee before deriving Concurrent2's methods. Errorful2's and Temporal2's don't use it at all. If that's the correct, the latter could avoid depending on it right ? Or there are other reasons ?

from interop-cats.

@barambani
API is simpler if most operations can be accessed from Errorful.
One rationalization I can give is that Guaranteed is more 'primitive', e.g. it's applicative, while Errorful is a monad. However, if we think of Errorful as just a copy of MonadError with bifunctor support, it indeed doesn't follow naturally that all Erroring effects should support finalizers.
TBQH I'd rather have an hierarchy like:

trait Guarantee extends Applicative
trait Errorful extends MonadError
trait Bracket extends Errorful & Guarantee

And have Bracket as the 'main' API entry point. This avoids the issue with Errorful extending Guaranteed and makes bracket accessible to non-concurrent, effects which I think makes sense. @jdegoes states that

In order to precisely state requirements on bracket, it is necessary to discuss interruption (neither acquire nor release may be interrupted),

But the same applies to guarantee too! guarantee must be uninterruptible, yet interruption doesn't appear until Concurrent. We actually want to use both of them without pulling in any concurrent infrastructure and have them 'upgraded' to support interruption automatically when using a Concurrent effect, instead of stuffing everything in Concurrent – we still have to 'upgrade' guarantee anyway, so moving bracket to Concurrent doesn't fundamentally change much.

from interop-cats.

Thanks @Kaishh . I like the idea, unfortunately with the approach taken, to derive bracket from guarantee we need also forking, so I guess bracket has to remain in Concurrent. We can still go with

trait Guaranteed2[F[+ _, + _]] // with an Applicative
abstract class Errorful2[F[+ _, + _]] extends Bifunctor[F] // with a Monad
abstract class Temporal2[F[+ _, + _]] extends Errorful2[F] with Guaranteed2[F]

and we can have

def uninterruptible[E, A](fa: F[E, A]): F[E, A]

moved to Guaranteed2.
Also, about your observation on pulling Concurrent, I notice that to implement Sync's test defaults for Zio I need Concurrent just to be able to propagate interruption.

override def runSync[G[+ _, + _], E, A](fa: IO[E, A])(implicit SG: Sync2[G], CG: Concurrent2[G]): G[E, A] =
  SG.suspend(
    runtime.unsafeRunSync(fa.either) match {
      case Success(ea) => ea.fold(SG.raiseError, SG.monad.pure(_))
      case Failure(_)  => CG.interrupted
    }
  )

What do you think about moving also

def interrupted: F[Nothing, Nothing]

to Guaranteed2 and having also Sync being a Guaranteed2 ?

abstract class Sync2[F[+ _, + _]] extends Errorful2[F] with Guaranteed2[F]

from interop-cats.

@barambani
We need fork to implement Concurrent bracket from guarantee.
We don't actually need it to implement bracket for a synchronous monad - we only need MonadError for that.
We also don't need forking to state the partial requirements of bracket, in the same capacity as we state them for guarantee.
We can just define a default implementation of bracket in Concurrent, but leave the abstract declaration in the superclass Bracket (as in current cats-effect) – this is not a fundamental problem IMHO, needing Concurrent to implement a Concurrent-aware bracket, only states that in presence of Concurrent, to hold bracket invariants, bracket implementation must be strengthened.

On propagating interruption – in the runSync above you also have to propagate die, not just interruption... One thing you can do is model these states in the exit case ExitCase[E,A] instead of separate methods, and a method to Errorful2 def exitWith[E, A](e: ExitCase[E, A]): F[E, A]. cats-effect IO does not support inner interruption and termination, I'm not sure they'll accept classes/methods for that, but they can always implement exitWith by converting branches of ExitCase into Throwable.

from interop-cats.

thanks @Kaishh , I was (and still probably am) missing some background about the reasoning behind this hierarchy. I will try to put the above together in the open pr. It makes perfectly sense the way you present it.

from interop-cats.

Closing this one, see #36 (comment)

from interop-cats.