Thanks for the post! I'm coming mostly from a Scala background, so it's good to get to know what's happening in Kotlin, especially that Java seems to be taking a similar route with Loom.
I've got a question though about the programming model. When working with IO, we're working with side-effect-free/pure functions, and get a number of benefits like referential transparency (we also get some non-benefits, but that's covered in your article). However, when we shift to working with suspended functions, don't we once again move back to working with side-effecting code?
That is, moving from IO to suspended functions would mean moving from FP to imperative/procedural programming. (And maybe that's fine - for performance and readability reasons.)
Another question is can you "lift" a suspended function to a value? While I see how suspended functions provide for much more readable code when it comes to sequential logic, I think for writing concurrent programs (even something as simple as running computations in parallel and combining their results) the lifted representation might be better.
Hi Adam,
thank you for reading it! Well the thing is that suspended functions are not like usual functions and need a context (a CoroutineContext) to be run in.
In that sense they are special and can be considered like descriptions of a side effect because, as for IO monad and monads in general, once you work with a supended function it "infects" all calling functions, meaning you either provide a coroutine context, same as unwrapping the IO by running it, or mark also the caller function as suspended (use map or flatMap).
In that sense I don't think it fosters an imperative style (from a phylosophical point of view you could also say that Monads enable an imperative style in the FP world).
To answer your second question I think a suspended identity function is an equivalent of pure/point/return/just whatever you want to call it.
About concurrent facilities I invite you to have a look at arrow-fx-coroutines, it provides all the functions you may already know (tupledN, parMapN, raceN, and others) ant it is designed with suspended functions.
Thanks! This definitely makes sense - so a suspended function is automatically lazily evaluated, which is really what IO is under the covers (a lazily evaluated function () => T or () => Future[T]).
And you are right that monads enable imperative style in FP - nothing wrong with that I suppose, depending of course on the definition of imperativeness and FP (as these unfortunately aren't that precise). But imperative understood as running a sequence of steps is something that's very natural and common in programming.
Here's what I found for raceN. As far as I see, it's taking suspend () -> A parameters to avoid eager evaluation of the computations that are being passed in. So in a way, these values are double-lazy (one because of the suspension, two because of the () ->)?
So I guess (thinking aloud here) you could say that the representation of a computation as a value is suspend () -> T (where T is the result of the computation).
One problem that I would see here is that the representation of a computation isn't uniform. Sometimes it's () => T, sometimes it's just T. If I would e.g. want to race a two processes, I would write something like val result1 = raceN(() -> a, () -> b).
But if I want to race this with yet another computation at some point in the future, it's not enough to write val result2 = raceN(() -> result, () -> c). I have to go back and change result1 to be a no-params function. Thinking about it, I think I just described lack of referential transparency of the Kotlin solution.
Not sure how much of a problem it is in practice. But for sure it's some departure from what IO and "pure FP" (again, depending how you define FP) gives you.
Thanks for the link! I think my reservations come from the fact that with IO you have the following signature: race(a: IO[A], b: IO[B]): IO[Either[A, B]]. While with suspensions, you have: race(a: suspend () -> A, b: suspend () -> B): Either[A, B].
Note that the return type doesn't return our "effect type", that would be () -> Either[A, B], but an eagerly evaluated value (Either[A, B]). And this matters for composition, meaning that if you want to compose that process later with others, you'll have to keep that in mind when defining it.
Hence it seems we're trading the uniformity of IO and some composition properties for the better readability and performance of suspensions. As always, tradeoffs :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the post! I'm coming mostly from a Scala background, so it's good to get to know what's happening in Kotlin, especially that Java seems to be taking a similar route with Loom.
I've got a question though about the programming model. When working with
IO, we're working with side-effect-free/pure functions, and get a number of benefits like referential transparency (we also get some non-benefits, but that's covered in your article). However, when we shift to working with suspended functions, don't we once again move back to working with side-effecting code?That is, moving from IO to suspended functions would mean moving from FP to imperative/procedural programming. (And maybe that's fine - for performance and readability reasons.)
Another question is can you "lift" a suspended function to a value? While I see how suspended functions provide for much more readable code when it comes to sequential logic, I think for writing concurrent programs (even something as simple as running computations in parallel and combining their results) the lifted representation might be better.
Hi Adam,
thank you for reading it! Well the thing is that suspended functions are not like usual functions and need a context (a CoroutineContext) to be run in.
In that sense they are special and can be considered like descriptions of a side effect because, as for IO monad and monads in general, once you work with a supended function it "infects" all calling functions, meaning you either provide a coroutine context, same as unwrapping the IO by running it, or mark also the caller function as suspended (use map or flatMap).
In that sense I don't think it fosters an imperative style (from a phylosophical point of view you could also say that Monads enable an imperative style in the FP world).
To answer your second question I think a suspended identity function is an equivalent of pure/point/return/just whatever you want to call it.
About concurrent facilities I invite you to have a look at arrow-fx-coroutines, it provides all the functions you may already know (tupledN, parMapN, raceN, and others) ant it is designed with suspended functions.
Hope to have provided you an answer.
Thanks! This definitely makes sense - so a suspended function is automatically lazily evaluated, which is really what
IOis under the covers (a lazily evaluated function() => Tor() => Future[T]).And you are right that monads enable imperative style in FP - nothing wrong with that I suppose, depending of course on the definition of imperativeness and FP (as these unfortunately aren't that precise). But imperative understood as running a sequence of steps is something that's very natural and common in programming.
Here's what I found for raceN. As far as I see, it's taking
suspend () -> Aparameters to avoid eager evaluation of the computations that are being passed in. So in a way, these values are double-lazy (one because of the suspension, two because of the() ->)?So I guess (thinking aloud here) you could say that the representation of a computation as a value is
suspend () -> T(whereTis the result of the computation).One problem that I would see here is that the representation of a computation isn't uniform. Sometimes it's
() => T, sometimes it's justT. If I would e.g. want to race a two processes, I would write something likeval result1 = raceN(() -> a, () -> b).But if I want to race this with yet another computation at some point in the future, it's not enough to write
val result2 = raceN(() -> result, () -> c). I have to go back and changeresult1to be a no-params function. Thinking about it, I think I just described lack of referential transparency of the Kotlin solution.Not sure how much of a problem it is in practice. But for sure it's some departure from what
IOand "pure FP" (again, depending how you define FP) gives you.In your example about race keep in mind that saying it takes
suspend () -> Ais equivalent to taking as inputIO[A](as far as I understood).For a better explanation read here, especially the sections
Arrow Fx vs Tagless FinalandGoodbye Functor, Applicative, and Monad.Thanks for the link! I think my reservations come from the fact that with
IOyou have the following signature:race(a: IO[A], b: IO[B]): IO[Either[A, B]]. While with suspensions, you have:race(a: suspend () -> A, b: suspend () -> B): Either[A, B].Note that the return type doesn't return our "effect type", that would be
() -> Either[A, B], but an eagerly evaluated value (Either[A, B]). And this matters for composition, meaning that if you want to compose that process later with others, you'll have to keep that in mind when defining it.Hence it seems we're trading the uniformity of
IOand some composition properties for the better readability and performance of suspensions. As always, tradeoffs :)