-
Notifications
You must be signed in to change notification settings - Fork 29
Monad Comprehensions without coroutine #12
Comments
@kalistace we agree and this is coming up for all data types that provide Monad around October https://github.com/47deg/arrow-meta-prototype/blob/rr-typeclasses-plugin/compiler-plugin/src/main/kotlin/arrow/meta/comprehensions/ComprehensionsPlugin.kt we are already working in a prototype that rewrites binds as flatMap because that is leaner than suspension. It will still use suspension for the code as it is today but will rewrite it to a nested flatMap |
Thanks for the answer ! Very happy to hear it is on the roadmap :) Looking forward to seeing it being rolled out. Great work. |
Hey @kalistace, The overhead is neglectable of using (See Roman's example on using suspend for stack safe functions or the sequence builder for similar low-cost implementations for suspend.) This also works in a suspended way by leveraging a small state-machine to keep track of the internal state, which can be done by simple You're correct that the current encoding in I hope that answers your questions, and what the current state is :) Thanks for the feedback! And if you have any questions feel free to ask questions here or on the Kotlin Slack in the #arrow channel ;) |
Hi,
As far as I understand, each binding steps in a monad comprehension will leverage kotkin suspended function feature, this great for IO, or very intensive task, but what if I just want to use it as syntactic sugar to avoid nested flatmap structures ? For instance to compute simple Task.
To illustrate, let's take an snippet from the documentation :
In the example, am I correct to think the runtime overhead of maintaining suspended functions will be greater than what it brings me ?
Although, this is an overly simplified example, in real applications such computation does happen, top of head, for instance to validate user input before sending it to a service or a IO function.
Is there a way to have binding steps running normally on the main thread ? The current workaround I can think of is to use nested flatmaps but it quickly gets unreadable.
Thanks
The text was updated successfully, but these errors were encountered: