> It seems to me like you are doing block logic without blocks, which I think
> increases the chances of bugs.
I agree. Without curly braces, it's not always clear when the parallel
code is guaranteed to have executed by. The first version of my
proposal did something similar:
```javascript
const a = await|| doSomethingAsync();
const b = await|| doSomethingElseAsync();
const [aValue, bValue] = await async.all;
```
...where `async.all` represents something like
`Promise.all(promises)`. The problem is, if you forget the `await
async.all` then your promises never execute (within the function), so
accidentally using `await||` instead of `await` would have the
opposite of the intended effect.
`async { await|| ... }` sidesteps both of these issues: it makes it
clear when the promises have all settled by, and if `await` isn't
allowed in the curly brackets then it avoids the "wrong operator"
confusion issue as well.
> 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.
If `await||` (or whatever) is learned in conjunction with `async {}`
blocks, and is only allowed within them, then it just becomes "this is
the syntax for parallelism." And as already stated, you'd need an
explicit marker for which expressions are being awaited in parallel
for any reasonable transpilation.
> `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.
Yeah, it'd be nice to have a syntax that doesn't create a block scope.
But that strikes me as less important than making it obvious where the
nondeterminism is.
I assume making these braces not create a block scope is unacceptable.
And using an alternative bracket (maybe `async [ await|| foo ]`) would
be too different from everything else in the language and might read
as an array, which discourages using non-expression statements inside
it
On Wed, Nov 27, 2019 at 9:57 AM Naveen Chawla <[email protected]> wrote:
>
> 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 { ... }`.
>
> On Wed, 27 Nov 2019 at 01:43, Isiah Meadows <[email protected]> wrote:
>>
>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
