According to current documentation,
Task.map2 (and other mapN functions) combine tasks such that they “run in order so the first task will be completely finished before the second task starts”. In general, such constraint is not imposed by type of this function, i.e. the same function could have semantics to run provided tasks in parallel.
Are these current semantics intentional? Or is this, maybe, constrained by the WIP Process library (section Future Plans) in which case it would be reconsidered once the Process library reaches stability? Is it possible to implement
(a -> b -> result) -> Task x a -> Task x b -> Task x result function type, with parallel semantics, without relying on native code, right now?
Warning! Reference to Haskell-like FP abstractions ahead. If you are not interested in this kind of content, please skip reading.
Task could be seen as an instance of
Applicative typeclass, and
map2 function could be implementation of
liftA2 function type. In general,
Applicative describes combining independent computations, so in case of
Task that would mean running asynchronous processes in parallel. For example Task from the Monix scala library is an instance of
Applicative, and it’s function family zipMapN have parallel semantics.
I believe parallel semantics of
Task.map2 function would be more inline with similar abstractions in FP community.