Ciao, I'm a FP and arrow newbie. I'm trying to fol...

# arrow

[franztesca]

Ciao, I'm a FP and arrow newbie.
I'm trying to follow the updates relative to the PR https://github.com/arrow-kt/arrow/pull/2797 and have a couple of questions:

In Arrow 1 the short circuit (shift) is throwing a ControlThrowable (which is not a CancellationException), in the PR with the inline fold the shift throws a ShiftCancellationException , which is a CancellationException ... Therefore Arrow 2 is going to have a different behavior when interacting with the Kotlin coroutines, as stated here (and the conclusion of that was "It seems that continuing to use ControlThrowable for shifting/short-circuiting is the best option."). Why have you chosen to use a CancellationException instead of ControlThrowable ?

Question 2: It seems to me that the new solution (the inline fold and ShiftCancellationException implementing the short circuit) is much simpler than the one implemented using continuations. Why did you choose the continuation approach in the first place and is there any drawback with the simpler throw/catch ShiftCancellationException ?

Thank you!

[simon.vergauwen]

Hey @franztesca 👋

Thank you for your deep interest in Arrow, and great questions!

1. There was quite some discussion on the I would say subtle change, and there is a design document that stayed behind comparing the two here. https://github.com/nomisRev/Continuation/blob/main/ContAndStructuredConcurrency.md We felt this didn't belong in the official documentation, not sure if we can find a better place for it. If you have any follow-up questions, or doubts be sure to ask them!
2. I think the new design is much simpler, and will bring us a lot of benefits in usage without any drawbacks. The first approach with the lower-level continuation implementation was just a natural evolution from the original solution. I don't think we could've came to this solution, without all the knowledge/experience we have now surrounding coroutines, and this DSL based monadic system.