<div><div dir="auto">OK but would `await||` return a promise? If so, then it would seem redundant compared to just omitting the `await`, as it would offer nothing different, and again, something new to learn for the same logical behaviour. Otherwise, it can only really return `undefined`, which would seem inconstent with both using `await` and omitting `await`. Therefore, I would recommend just omitting await inside an await.all block as the pattern for doing “await until all done” parallelism.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Dec 2019, 07:48 Jacob Bloom, <<a href="mailto:mr.jacob.bloom@gmail.com" target="_blank">mr.jacob.bloom@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> It seems to me like you are doing block logic without blocks, which I think<br>
> increases the chances of bugs.<br>
<br>
I agree. Without curly braces, it's not always clear when the parallel<br>
code is guaranteed to have executed by. The first version of my<br>
proposal did something similar:<br>
<br>
```javascript<br>
const a = await|| doSomethingAsync();<br>
const b = await|| doSomethingElseAsync();<br>
const [aValue, bValue] = await async.all;<br>
```<br>
<br>
...where `async.all` represents something like<br>
`Promise.all(promises)`. The problem is, if you forget the `await<br>
async.all` then your promises never execute (within the function), so<br>
accidentally using `await||` instead of `await` would have the<br>
opposite of the intended effect.<br>
<br>
`async { await|| ... }` sidesteps both of these issues: it makes it<br>
clear when the promises have all settled by, and if `await` isn't<br>
allowed in the curly brackets then it avoids the "wrong operator"<br>
confusion issue as well.<br>
<br>
> you're not leveraging the existing parallel execution pattern for async<br>
> functions (which is just to omit the `await`), so it would seem you<br>
> would be increasing learning overhead.<br>
<br>
If `await||` (or whatever) is learned in conjunction with `async {}`<br>
blocks, and is only allowed within them, then it just becomes "this is<br>
the syntax for parallelism." And as already stated, you'd need an<br>
explicit marker for which expressions are being awaited in parallel<br>
for any reasonable transpilation.<br>
<br>
> `const` and `let` are block-scoped, so this is referring to avoid that block<br>
> notation, and then keep coherent with the possibility to directly infer in<br>
> current scope references without extra segments / blocks.<br>
<br>
Yeah, it'd be nice to have a syntax that doesn't create a block scope.<br>
But that strikes me as less important than making it obvious where the<br>
nondeterminism is.<br>
<br>
I assume making these braces not create a block scope is unacceptable.<br>
And using an alternative bracket (maybe `async [ await|| foo ]`) would<br>
be too different from everything else in the language and might read<br>
as an array, which discourages using non-expression statements inside<br>
it<br>
<br>
<br>
<br>
On Wed, Nov 27, 2019 at 9:57 AM Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com" rel="noreferrer" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
><br>
> I don't know that an `await.all { ... }` block would be premature, especially since it's straightforward, so I can't see it clashing with anything in the future e.g. on the "observables" front, if that were to become a thing. If the semantics of `await` were to be extended somehow, then identically and naturally would the semantics of `await.all { ... }`.<br>
><br>
> On Wed, 27 Nov 2019 at 01:43, Isiah Meadows <<a href="mailto:contact@isiahmeadows.com" rel="noreferrer" target="_blank">contact@isiahmeadows.com</a>> wrote:<br>
>><br>
>> Just wanted to drop in and remind people of this by me earlier in the thread:<br>
>> <a href="https://esdiscuss.org/topic/proposal-await-all-for-parallelism#content-10" rel="noreferrer noreferrer" target="_blank">https://esdiscuss.org/topic/proposal-await-all-for-parallelism#content-10</a><br>
>><br>
>> The way things are shaping up, it's starting to look like an ad-hoc version of this proposal of mine:<br>
>> <a href="https://github.com/isiahmeadows/non-linear-proposal" rel="noreferrer noreferrer" target="_blank">https://github.com/isiahmeadows/non-linear-proposal</a><br>
>><br>
>> As I stated earlier, I feel it's premature, especially before we figure out how observables fit into it all.<br>
>><br>
>> On Tue, Nov 26, 2019 at 09:48 Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com" rel="noreferrer" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
>>><br>
>>> If I have, as per your examples,<br>
>>><br>
>>> x1 = await||actionAsync1()<br>
>>> x2 = await||actionAsync2(x1) //x1 is undefined here, only resolved on the next "non-parallel-await"<br>
>>><br>
>>> vs adding a line between the two calls:<br>
>>><br>
>>> x1 = await||actionAsync1()<br>
>>> let c;<br>
>>> x2 = await||actionAsync2(x1)<br>
>>><br>
>>> ...does the `let c` automatically break the parallel grouping since it's a non-parallel operation (thereby making x1 defined)?<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>><br>
>>> On Tue, 26 Nov 2019 at 14:14, manuelbarzi <<a href="mailto:manuelbarzi@gmail.com" rel="noreferrer" target="_blank">manuelbarzi@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>>> 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?<br>
>>>><br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> what it tries to bring is a simplification of syntax.<br>
>>>><br>
>>>>> 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<br>
>>>><br>
>>>><br>
>>>> `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.<br>
>>>><br>
>>>>><br>
>>>>> On Tue, 26 Nov 2019 at 13:35, manuelbarzi <<a href="mailto:manuelbarzi@gmail.com" rel="noreferrer" target="_blank">manuelbarzi@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>>><br>
>>>>>>> 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?<br>
>>>>>><br>
>>>>>><br>
>>>>>> 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:<br>
>>>>>><br>
>>>>>> ```<br>
>>>>>> // NOTE p? = function call that returns a promise (? = just and index)<br>
>>>>>> // NOTE s? = function call that runs synchronously and returns a value (? = just and index)<br>
>>>>>><br>
>>>>>> const x0 = await p0()<br>
>>>>>><br>
>>>>>> const x11 = s11() // sync code in-the-middle<br>
>>>>>><br>
>>>>>> const x1 = await || p1(x0)<br>
>>>>>> const x3 = await || p3(x11)<br>
>>>>>> const x2 = await p2(x1)<br>
>>>>>> const x10 = await p10(x2, x3)<br>
>>>>>><br>
>>>>>> const x12 = s12() // sync code in-the-middle<br>
>>>>>><br>
>>>>>> const x4 = await || p4(x1, x2)<br>
>>>>>> const x5 = await || p5(x2, x3, x12)<br>
>>>>>> const x6 = await p6(x4, x5, x10)<br>
>>>>>><br>
>>>>>> const x7 = await || p7(x4, x6)<br>
>>>>>> const x9 = await || p9(x5, x6)<br>
>>>>>> const x8 = await p8(x6, x7)<br>
>>>>>><br>
>>>>>> await p11(x8, x9)<br>
>>>>>><br>
>>>>>> // it would resolve a tree of parallel and series like following with traditional promises<br>
>>>>>><br>
>>>>>> p0<br>
>>>>>>     .then(x0 => {<br>
>>>>>>         const x11 = f11()<br>
>>>>>><br>
>>>>>>         return Promise.all([p1(x0), p3(x11)])<br>
>>>>>>             .then((x1, x3) =><br>
>>>>>>                 p2(x1)<br>
>>>>>>                     .then(x2 =><br>
>>>>>>                         p10(x2, x3)<br>
>>>>>>                             .then(x10 => {<br>
>>>>>>                                 const x12 = s12()<br>
>>>>>><br>
>>>>>>                                 return Promise.all([p4(x1, x2), p5(x2, x3, x12)])<br>
>>>>>>                                     .then((x4, x5) =><br>
>>>>>>                                         p6(x4, x5, x10)<br>
>>>>>>                                             .then(x6 => Promise.all([p7(x4, x6), p9(x5, x6)])<br>
>>>>>>                                                 .then((x7, x9) => p8(x6, x7)<br>
>>>>>>                                                     .then(x8 => p11(x8, x9))<br>
>>>>>>                                                 )<br>
>>>>>>                                             )<br>
>>>>>>                                     )<br>
>>>>>>                             })<br>
>>>>>>                     )<br>
>>>>>>             )<br>
>>>>>>     })<br>
>>>>>> ```<br>
>>><br>
>>> _______________________________________________<br>
>>> es-discuss mailing list<br>
>>> <a href="mailto:es-discuss@mozilla.org" rel="noreferrer" target="_blank">es-discuss@mozilla.org</a><br>
>>> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>><br>
>> --<br>
>> -----<br>
>><br>
>> Isiah Meadows<br>
>> <a href="mailto:contact@isiahmeadows.com" rel="noreferrer" target="_blank">contact@isiahmeadows.com</a><br>
>> <a href="http://www.isiahmeadows.com" rel="noreferrer noreferrer" target="_blank">www.isiahmeadows.com</a><br>
><br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" rel="noreferrer" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" rel="noreferrer" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</div>