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?

Related issues:

### 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.