You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently avocADO parallelizes the following comprehension:
for {
a <- doStuff1
b <- doStuff2(a)
c <- doStuff3
} yield combine(a, b, c)
to sth conceptually like:
for {
a <- doStuff1
(b, c) <- doStuff2(a).zip(doStuff3)
} yield combine(a, b, c)
The reasoning behind it is that if one wants to parallelize comprehensions that have the effect monad abstracted away, the concrete monad at the end might use a sequential state. In that case, there can't be any parallelization done, because that would affect the end result of the program. In such cases, it should still be possible to use ado, but just provide a different AvocADO instance (with a sequential implementation of zip).
Though for use cases that are more concrete, like programs based on god monads (ZIO etc.), a more aggressive parallelization should be available. One that can also reshuffle (change the order of) the expressions.
Concretely, it should be possible to convert our example (with a more aggressive strategy) to sth conceptually like:
for {
(a, c) <- doStuff1.zip(doStuff3)
b <- doStuff2(a)
} yield combine(a, b, c)
The text was updated successfully, but these errors were encountered:
for {
a <- doStuff
a <- doStuff1(a)
c <- doStuff2
a <- doStuff
} yield combine(a, c)
The most obvious desugaring of this comprehension will be wrong since the as will be shadowing each other (possibly in incorrect order). We use symbols though, so maybe we just need to be smart about the order of bindings picked.
Currently
avocADO
parallelizes the following comprehension:to sth conceptually like:
The reasoning behind it is that if one wants to parallelize comprehensions that have the effect monad abstracted away, the concrete monad at the end might use a sequential state. In that case, there can't be any parallelization done, because that would affect the end result of the program. In such cases, it should still be possible to use
ado
, but just provide a differentAvocADO
instance (with a sequential implementation ofzip
).Though for use cases that are more concrete, like programs based on god monads (ZIO etc.), a more aggressive parallelization should be available. One that can also reshuffle (change the order of) the expressions.
Concretely, it should be possible to convert our example (with a more aggressive strategy) to sth conceptually like:
The text was updated successfully, but these errors were encountered: