A modern programming language that makes developers happier.

kotlinlang

your implementation can be done (less optimally) using `swap().flatMap(block)`

Looks like handleErrorWith() preserves the same type of failure (the left type)

I should use swap().flatMap(block).swap(). But then I'd lose the inlining, and I need that because I'm running suspend functions inside that block.

`flatMapLeft` is a good name for this. I'm trying to remember why we didn't allow to change the error type on flatMap

I'm sure it's because the MonadError instance is fixed to one error type

This is the place where I'm using this: <https://gist.github.com/mel4tonin4/9c4a1fec2f3ddec401552823dece1a4c>

`processFlow` is a builder of `ProcessFlow` which is something like a kotlin `Flow` emitting progress events, followed by  a terminal event containing a result. The ``as`` infix operator embeds a ProcessFlow in the current `ProcessFlow`. `ProcessFlow` is actually a wrapper around a regular `Flow`, and that's where the need for using `suspend` functions comes from.

the fold inside `flatMapLeft` could happen outside

`doNotCompute? StoredEvaluationProblem.ComputationSkippedAsRequested.left() : computeFlow()`

Using these 3 extensions methods <https://gist.github.com/mel4tonin4/7472822197456889c2fd889b552431db> I reduced the code to <https://gist.github.com/mel4tonin4/10434d0d6f83773c57c9a374f558c83d>

I didn't need the `Option&lt;T&gt;.`if`` after all: <https://gist.github.com/mel4tonin4/a4257b83a4f609474a78471b21639ad2>.
This is the best I can do without using metaprogramming, I guess. If I keep using this `ProcessFlow` , I'll check _arrow-meta_ and see if I can remove  some boilerplate code (not visible here) and simplify the syntax even further.
Anyway, thanks again!