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.
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 :)