Just wanted to drop in and remind people of this by me earlier in the thread: https://esdiscuss.org/topic/proposal-await-all-for-parallelism#content-10
The way things are shaping up, it's starting to look like an ad-hoc version of this proposal of mine: https://github.com/isiahmeadows/non-linear-proposal As I stated earlier, I feel it's premature, especially before we figure out how observables fit into it all. On Tue, Nov 26, 2019 at 09:48 Naveen Chawla <[email protected]> wrote: > If I have, as per your examples, > > x1 = await||actionAsync1() > x2 = await||actionAsync2(x1) //x1 is undefined here, only resolved on the > next "non-parallel-await" > > vs adding a line between the two calls: > > x1 = await||actionAsync1() > let c; > x2 = await||actionAsync2(x1) > > ...does the `let c` automatically break the parallel grouping since it's a > non-parallel operation (thereby making x1 defined)? > > It seems to me like you are doing block logic without blocks, which I > think increases the chances of bugs. Also you're not leveraging the > existing parallel execution pattern for async functions (which is just to > omit the `await`), so it would seem you would be increasing learning > overhead. And, you're not really allowing for submitting more sophisticated > mixtures of serial async, parallel async and synchronous code for "parallel > completion" guarantee, by requiring that parallel calls be "grouped" > together in terms of lines of code, almost allowing for nothing beyond the > current "Promise.all" pattern, logically. I don't think this is satisfying > the original motivation. > > For a `awail.all { ... }` block, maybe allowing a "return"/"yield" value > could neaten up the block scope separation, but maybe that could be left to > the "do" expression if that were adopted. But I don't think it's a big > sacrifice if neither exist. > > > On Tue, 26 Nov 2019 at 14:14, manuelbarzi <[email protected]> wrote: > >> >> OK I'm even more confused now. x1 is surely not a resolved value until >>> all the next "non parallel await" so is it "undefined" until then? >>> >> >> as a `const` x1 does not exist until those parallel awaits `await||` (for >> p1 and p3) are resolved (same for x3). then p2 is resolved after that. >> >> what it tries to bring is a simplification of syntax. >> >> Could you give an example of what you mean by the `await.all { ... }` >>> block syntax bringing "complexity on returning values assignment, >>> specially when" "about constants (`const`)", as I'm unclear what you are >>> referring to >>> >> >> `const` and `let` are block-scoped, so this is referring to avoid that >> block notation, and then keep coherent with the possibility to directly >> infer in current scope references without extra segments / blocks. >> >> >>> On Tue, 26 Nov 2019 at 13:35, manuelbarzi <[email protected]> wrote: >>> >>>> >>>> >>>>> Why not just maximally preserve current JavaScript for parallel >>>>> execution, just by omitting `await` in multiple async calls, simply >>>>> wrapping it in an `await.all` block to ensure completion before code >>>>> continues past the block. This surely is the more straightforward way to >>>>> satisfy the same goals? >>>>> >>>> >>>> because wrapping it an `await.all` on the one hand explicitly groups >>>> promises, but brings complexity on returning values assignment, specially >>>> when is about constants (`const`). so, if you avoid blocks, just marking >>>> parallel awaits with, for example, a suffix `await||`, or whatever other >>>> more convenient way, you can just write the code in series as normally, and >>>> avoid that complexity. the transpiler would just require to group the >>>> consecutive marked parallel awaits (`await||`) into a Promise.all() and >>>> that's it. following i reproduce the demo before: >>>> >>>> ``` >>>> // NOTE p? = function call that returns a promise (? = just and index) >>>> >>>> // NOTE s? = function call that runs synchronously and returns a value (? >>>> = just and index) >>>> >>>> const x0 = await p0() >>>> >>>> const x11 = s11() // sync code in-the-middle >>>> >>>> const x1 = await || p1(x0) >>>> const x3 = await || p3(x11) >>>> const x2 = await p2(x1) >>>> const x10 = await p10(x2, x3) >>>> >>>> const x12 = s12() // sync code in-the-middle >>>> >>>> const x4 = await || p4(x1, x2) >>>> const x5 = await || p5(x2, x3, x12) >>>> const x6 = await p6(x4, x5, x10) >>>> >>>> const x7 = await || p7(x4, x6) >>>> const x9 = await || p9(x5, x6) >>>> const x8 = await p8(x6, x7) >>>> >>>> await p11(x8, x9) >>>> >>>> >>>> // it would resolve a tree of parallel and series like following with >>>> traditional promises >>>> >>>> p0 >>>> .then(x0 => { >>>> const x11 = f11() >>>> >>>> return Promise.all([p1(x0), p3(x11)]) >>>> .then((x1, x3) => >>>> p2(x1) >>>> .then(x2 => >>>> p10(x2, x3) >>>> .then(x10 => { >>>> const x12 = s12() >>>> >>>> return Promise.all([p4(x1, x2), p5(x2, >>>> x3, x12)]) >>>> .then((x4, x5) => >>>> p6(x4, x5, x10) >>>> .then(x6 => Promise.all([p7 >>>> (x4, x6), p9(x5, x6)]) >>>> .then((x7, x9) => p8(x6 >>>> , x7) >>>> .then(x8 => p11(x8 >>>> , x9)) >>>> ) >>>> ) >>>> ) >>>> }) >>>> ) >>>> ) >>>> }) >>>> ``` >>>> >>> _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- ----- Isiah Meadows [email protected] www.isiahmeadows.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
