jdegoes
commented
6 years ago There can be no principled, leak-free, monadic concurrency in functional programming without MonadBracket and MonadFork, or equivalents, including interruption semantics analogous to Scalaz 8 / Haskell / PureScript.
Interruption is fundamental to composability, and must be baked into the lowest layer of the stack, which is the effect monad that drives the application.
Not only is such a thing possible to do in a lawful fashion with precise semantics, but it has been done, in Scalaz 8 IO and elsewhere. The fact that existing libraries do not support these semantics is irrelevant because (a) existing libraries can always be improved, or alternatively (b) type class laws can be weakened so as to permit "no op" implementations.
I happily donate the following type classes to the project:
trait Forked[F[_], A] {
def interrupt(t: Throwable): F[Unit]
def join: F[A]
}
trait MonadBracket[F[_]] extends MonadError[F, Throwable] {
def bracket[A, B](acquire: F[A])(use: A => F[B])(release: (A, Either[Throwable, B]) => F[Unit]): F[B]
def never[A]: F[A]
}
trait MonadFork[F[_]] extends MonadBracket[F] {
def fork[A](fa: F[A]): F[Forked[F, A]]
def raceWith[A, B, C](l: F[A], r: F[B])(
finish: Either[(A, Forked[F, B]), (B, Forked[F, A])] => F[C]): F[C]
}These are very small and flexible type classes, while providing just enough power to construct correct, composable, and leak-free software. All methods have low-cost implementations which may not have the full capabilities of more extensive implementations but which can lessen author burden.
MonadBracket must be a super class of Sync. That is to say, it does not make any sense to have a Sync without the ability to bracket (bracket gives meaning to the notion of monadic operations on foreign effectful code). Separately, I'd also argue that Async and Sync should be unified because there is nothing intrinsically useful which is a Sync and not Async.
MonadFork is necessary for safe, leak-free concurrency. That is, any F[_] which does not have a MonadFork should not be used for concurrency. In no case should concurrency be implemented on top of an F[_] that does not support MonadFork because it will be broken by construction.
Of course, a concurrent F[_] could support more than just MonadFork, but MonadFork provides the bare essentials necessary to implement higher-level, composable, safe combinators on top (parMap2, concurrently, etc.).
Concurrent libraries like FS2 and http4s must be able to rely on existence of MonadFork. Simpler libraries that do not have concurrent needs do not have to use MonadFork and will therefore benefit from much simpler IO implementations.
@alexandru
Scalaz 8 IO fully linearizes interruption / finalization. Finalization will never occur out of order or concurrently, but rather, it will be done in the correct order and fully sequentially, post-successful interruption, after user-defined effects have returned control to the runtime. This ensures implementation details are not leaked (the logical model of a linear fiber is maintained) and provides a simple reasoning model that makes it easy to write correct code.
alexandru
I raised this issue on the gitter channel and got a lot of positive feedback. We removed
IO#ensuringsome time ago and realizedMonadErroris not powerful enough to implement it (See here). I'd like to propose something in the vein ofMonadBracketdescribed in this article. It might also help with providing a resource safeParallelexperience.Relevant gitter discussion: