Add compute combinators

[BalmungSan]

Related to #3353

Adds a couple of useful combinators related to compute-bound operations.
How best to suspend compute-bound operations is a FAQ in Discord, thus I believe having some combinators for the simple use cases is a good idea.

[satorg]

I would like to weigh in a little.
I'm not sure that adding these two methods: computeAttempt and computeMapAttempt is really worth it:

def expensiveComputation: Either[Throwable, TheResult] = ???

computeAttempt { expensiveComputation } <=?=> compute { expensiveComputation }.rethrow

Thereby, computeAttempt doesn't look like a big win.

Is it really important to have rethrow executed before the finalizing cede rather than after it?

[satorg]

That said, compute and computeMap look like a big deal to me...

[BalmungSan]

I'm not sure that adding these two methods: computeAttempt and computeMapAttempt is really worth it:

As with any combinator is hard to argue both ways IMHO.
They are there for convenience, but I do agree it is impractical to add each and every combinator, as Fabio points regularly.
Like, compute is also just convenience, but I do agree the name would help and it seems folks are reluctant of using cede.

Personally, I like avoiding the rethrow but I also understand that it may not be seen as much, so I am happy to remove them if others agree.

[reardonj]

I'd also be inclined to remove the attempt versions. These combinators are already slightly niche, and having Either[Throwable, A] is an unusual situation to me. I'm not sure how you end up with that without already having a try and conversion to Either, but IO already will capture the exception and throw. So why even try?

Also, the -attempt suffix feels odd since a regular attempt turns an error into an Either while this one goes backwards, turning an Either into an error.

[BalmungSan]

I'd also be inclined to remove the attempt versions. These combinators are already slightly niche, and having Either[Throwable, A] is an unusual situation to me.

Well, actually, the last time I needed this it was with that shape :p
It was a heavy Json parser which returned Either[Throwable, A]. But sure, adding a rethrow at the end wouldn't have been a big deal.

As I said in my previous message, it is hard to argue which combinators should exist and which should not. I just think we need at least the two basic compute and computeMap

[reardonj]

As I said in my previous message, it is hard to argue which combinators should exist and which should not. I just think we need at least the two basic compute and computeMap

Ya, those made sense to me. It's just the attempt shape and name I object to. I could see an argument that only IO.compute is needed and you can just flatMap if you need a map too, but getting an A from something and doing compute on it is such an obvious use case that computeMap makes sense to have.

---

I worry a little this whole exercise will result in people casually throwing a compute on anything that does CPU bound work at all, but that's not even a footgun.

[reardonj]

This having to be in Async feels bad. Is there a reason we shouldn't implement it as F.defer(F.pure(thunk)) instead of delay(thunk)? delay is supposed to be for side effects, but the computations should be pure.

[reardonj]

Or even a cheeky F.unit.map(_ => thunk). It wouldn't be the first use of the trick in this codebase.