Translate SyncIO to F[_]: Sync

[vasilmkd]

Resolves #1790.

[djspiewak]

Aside from my one note, I quite like this!

[oleg-py]

Looks like the translation can work for any F[_]: Sync, avoiding the SyncIO <-> IO dependency question entirely.

Another thing is that we might want to make it uncancelable. If we consider code like this valid:

def thing[F[_]](implicit F: MonadCancelThrow[F]) = F.rootCancelScope match {
  case Uncancelable =>
    // We aren't gonna be cancelled, so no need for special handling
    F.delay(...).flatMap(...).attempt.flatMap(...).rethrow
  case Cancelable => F.raiseError(new Exception("Operation not supported for cancelable monads"))
}

then doing thing[SyncIO].toIO would break the assumption of thing that it can't be canceled.

[vasilmkd]

Oof, you're so right about this being uncancelable. I don't know if we want to code it against Sync though. We had a to[F[_]: Async] on IO before and we deleted it, because there is no way for effects that support more features than the Async interface to translate all of their features in terms of Async. I understand that SyncIO is not that complicated, but still, there is a precedent where we had this and there was a decision to remove it.

cc @djspiewak

[vasilmkd]

Made the resulting IO uncancelable.

[vasilmkd]

@djspiewak I rebased this branch and addressed the comments.

I need your resolution on @oleg-py's comment about to[F[_]: Sync]. IMO, we removed this method on IO, because it was tying us to the typeclass hierarchy, so there is precedent to not proceed with this suggestion.

If that is the case, this PR is ready for merging.

[oleg-py]

IMO, we removed this method on IO, because it was tying us to the typeclass hierarchy, so there is precedent to not proceed with this suggestion.

"Tying to typeclass hierarchy" sounds odd as a justification. Sync is an "interface" both SyncIO and IO know about (yes, you "implement" it in the companion object, but it's already tied there), whereas there's no reason they, as concrete implementations, should know about each other. Isn't the point of typeclasses to allow reasonable abstraction over implementations?

We had a to[F[_]: Async] on IO before and we deleted it, because there is no way for effects that support more features than the Async interface to translate all of their features in terms of Async

It's the other way around, I suppose. You can't translate all of IO features (*looks at IOLocal*) in terms of Async alone. However it seems that, especially with changes to clock-related methods, SyncIO has become just free/initial encoding (+ an impure interpreter) of a Sync algebra, hasn't it? And therefore it should be perfectly reasonable to interpret it to any other Sync[F], also leaving our hands less tied w.r.t. #1861.

I guess the question is whether SyncIO is going to remain just a simplest Sync possible, or it's gonna have more custom features added. But 1) please don't and 2) SyncIO is most useful in places that are really different from places where IO is useful (notably places where you can't code to Sync[F] algebra).

[vasilmkd]

I agree with these points. Do you think it would be strange to have a SyncIO#to[F[_]: Sync] but no IO#to[F[_]: Async]? If we can live with that difference, then I'm all for it. I also personally don't see SyncIO evolving any further than what it supports at the moment.

[oleg-py]

Do you think it would be strange to have a SyncIO#to[F[]: Sync] but no IO#to[F[]: Async]?

I think SyncIO.to[F[_]: Sync] fits "simplest Sync that's still handy" that SyncIO came out to be. That point doesn't apply to IO since CE3 has shifted its IO to being "best main effect type of your app", instead of "simplest XXX" that CE2 and before tried to have.

Also users will be asking about conversions of IO <-> Async[F] whether SyncIO has this method or not 😅

[vasilmkd]

Great! Thanks for the discussion @oleg-py. I'll push out the changes later.

[vasilmkd]

This is ready for merging.