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
> 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
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
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:
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`
however, i find yet things to solve with it, like how to face two
consecutive and depending parallel blocks (no series awaits neither sync
statements in the middle). for that, the initial proposal using arrays
would fit, but i understand is what you trying to avoid.
const [x1, x2] = await||
> 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
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?
Could you give an example of what you mean by the `await.all { ... }` block
syntax bringing "complexity on returning values assignment, specially when"
"about
> 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
Hi Manuel, I think your idea is too much magic, in the sense of not being
straightforward to understand. It actually executes subsequent code first,
e.g.
async {
x1 = await || doStuffAsync1();
x2 = await doStuffAsync2();
x3 = await || doStuffAsync3();
}
In your idea, `doStuffAsync3()`
by the way, i think it can also be improved without the need of `async {}`
blocks, just marking together the parallel awaits (`await||`) and write the
code like in series, but grouping the parallel awaits when transpiling:
// NOTE async {} = asynchronous scope (it groups parallel awaits =>
hi Tom
So the parallel awaits would execute before the series awaits?
>
not exactly. it would group the parallel awaits at the position the first
parallel await|| is sentenced.
following the demo i sent:
// NOTE async {} = asynchronous scope (it groups parallel awaits => `await||`)
// NOTE p?
>
> I don't think I like "await ||" as a syntax, because it doesn't have
> anything to do with the "OR" operator.
>
it is just a quick proposal to symbolise parallelism easily (||), but just
that, of course it could be any other more convenient symbol
> Manuel, I am not sure I understand your
I don't think I like "await ||" as a syntax, because it doesn't have
anything to do with the "OR" operator.
It does avoid adding a bunch of potentially optimization-breaking if
statements to the transpiled output for synchronous code like in my
example, though, because you only get the behavior
yet smaller, as Promise.resolve() was totally redundant here...
// NOTE async {} = asynchronous scope (it groups parallel awaits => `await||`)
// NOTE p? = function call that returns a promise (? = just and index)
async {
const x1 = await || p1()
const x2 = await p2(x1)
const x3 =
a few little corrections...
// NOTE async {} = asynchronous scope (it groups parallel awaits => `await||`)
// NOTE p? = function call that returns a promise (? = just and index)
async {
const x1 = await || p1()
const x2 = await p2(x1)
const x3 = await || p3()
const x10 = await
>
> Hi Manuel! Would you mind explaining the added value of your proposal? I
> am only seeing it being more verbose, but I've not found any added
> functionality or benefit from it
>
the proposal combines parallel and series async / await and could resolve
complex trees, like the following
Hi Tom! Would you mind clarifying the performance hit you are referring to?
I'm seeing that the "synchronous" calls wouldn't be added to the array you
used in your example, so it's not clear to me to which performance hit you
are referring.
Hi Manuel! Would you mind explaining the added value of
another example, that may "normalize" it a bit more:
```
async { // ... = returns a promise
const x1 = await|| ...
const x2 = await ... (x1)
const x3 = await|| ...
const x10 = await ... (x2, x3)
let x4, x5, x6
async {
x4 = await|| ... (x1, x2)
x5 =
why not making it work with the addition of a new keyword suffix for
parallel awaits (for example, `||`), grouping the mid blocks that require
parallelism. playing with your example and going a bit further:
```
async {
const v0 = await|| returnsAPromise(); // to be grouped in parallel
for
There is however a performance concern with your code that we should talk
about.
If I write this:
await.all {
returnsAPromise();
for (let i = 0; (i < 10); i++) {
doesSimpleFastSynchronousMath();
}
returnsAnotherPromise();
}
Then Babel will have no choice but to compile this to:
Hey, you're absolutely right! It's OK because it just means things are more
deterministic before the block exits. It doesn't impact any reasonable
expectations *during* the block.
I am convinced that your syntax is useful and does not introduce any new
confusion.
I wonder, then, if it is also
Hi! It does not change the meaning of the ";" at all. As you may already
know, omitting `await` already invokes multiple async function calls in
parallel, in current JavaScript, so absolutely no change in that respect.
The only thing this `await.all` suggestion does, is ensure that all
This is very interesting, but this code:
await.all {
x = getXAsync();
y = getYAsync();
}
processXAndY(x, y);
Still carries within it the problem that if I'm looking at just the middle
of the { ... } block — if "await.all" has scrolled offscreen — I'll be
completely wrong about what ";"
However, if `await.all { ... }` were to mean "wait for all non-awaited
async function calls made within this block to complete before proceeding",
as I suggested earlier, I think that could satisfy determinism for "await"
wherever it is used, and satisfy the original motivation:
```
await.all {
I am very sympathetic to pitches to allow more common cases for promise
libraries to be written in an "awaitful" syntax without thinking explicitly
about promises.
Howeever I think that changing the meaning of the semicolon in a particular
context has too much potential for confusion. As others
I do find the pattern of promise "all" combined with destructuring the
easiest way to handle parallelism. I think it's the only "deterministic"
parallel pattern code wise.
I think non determinism in code increases the probability of bugs.
On Thu, 21 Nov 2019, 23:42 Jacob Bloom, wrote:
> >>This
>>This [current] structure is also just fundamentally different from working
>>serially in async/await and it forces you to reason about the problem in a
>>specific way. This doesn't appear to be a conscious decision to force good
>>code practices
>
>Actually I'd argue that it is. Doing stuff
Yes of course, I was responding to your proposal and the subsequent email
about it being incompatible with existing JavaScript because "await" on its
own accepts non-promises, so wouldn't return an array of results from an
array of promises, hence why I proposed await.all etc.
On Thu, 21 Nov 2019
> I have a solution for that:
>
> const promises = [...]
> await.all promises //returns an array of results
> await.race promises //returns a single result
>
well, my proposal is exactly that, but doing `await.all` by default with
just `await`.
___
>```javascript
>const promises = [...]
>await.all promises //returns an array of results
>await.race promises //returns a single result
>```
One of the goals of this proposal is to simplify the process of
collecting the promises in an array and then having to get them out of
another array.
>Why
Why not just use a combination of `async`/`await` and `.then`?
```javascript
async function initialize() {
const [foo, bar, baz] = await Promise.all([
request('foo.json').then(t => t.data),
request('bar.json').then(t => t.data),
request('baz.json').then(t => t.data),
I have a solution for that:
const promises = [...]
await.all promises //returns an array of results
await.race promises //returns a single result
etc.
On Thu, 21 Nov 2019 at 09:51, manuelbarzi wrote:
> AFAIK `await` can only accept an `expression` as a `Promise`, not other
> thing:
>
AFAIK `await` can only accept an `expression` as a `Promise`, not other
thing:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await
On Thu, Nov 21, 2019 at 10:46 AM Jacob Bloom
wrote:
> >why not just `await` as already is, but supporting an
> >iterable / array of
>why not just `await` as already is, but supporting an
>iterable / array of promises, as `Promise.all` already does
`await` can already accept a non-promise, so I believe that'd be
breaking syntax if `Array.prototype.then` is set. It also requires
collecting the promises in an array, which is
why not just `await` as already is, but supporting an iterable / array of
promises, as `Promise.all` already does, automatically discerning single
promises vs multiple ones:
```
const promises = [...]
// in parallel (`await` automatically acts as `Promise.all` here)
const results = await
>Just FYI, I previously suggested a couple things substantially more
>flexible than this
Ah, thank you for bringing those proposals to my attention. I looked
through the archives for relevant discussions but I must've missed
them.
It seems like we converged on a similar syntax for what you
Just FYI, I previously suggested a couple things substantially more
flexible than this [1] [2] (originated from this [3]), and it mostly
fell flat due to being highly premature. Anything exclusive to
promises is unlikely to win as library methods exist for basically all
use cases and from my
...strike that, I misread the "but that still waits for the async
functions to complete" part. So what you're proposing is that
everything functions normally inside the curly braces, but execution
doesn't continue until all promises have resolved? So your example
would work essentially like this:
>Maybe if you drop the "await" in your example:
>
>```javascript
>await.all {
>const x = doSomethingAsync();
>//x is just the promise here
>}
>```
>
>...but that still waits for the async functions to complete, I think it would
>cause fewer bugs and would seem to still satisfy the
Hello!
> This [current] structure is also just fundamentally different from working
> serially in async/await and it forces you to reason about the problem
> in a specific way. This doesn't appear to be a conscious decision to
> force good code practices
Actually I'd argue that it is. Doing
I don't like the idea of await behaving differently inside vs outside of
the "await.all" block, and I think is a source of bugs:
await.all {
const x = await doSomethingAsync();
//x is still undefined here! Not the case outside of an await.all block
}
Maybe if you drop the "await" in your
There's `for await` loops since recently, there could be `await for` loops
for wrapping the whole execution of a loop
```js
console.time(1);
await for (const fn of [()=>delay(50).then(()=>'a'),
()=>delay(80).then(()=>'b')]) {
console.timeLog(1, await fn());
}
console.timeEnd(1);
```
This would
Regarding parallel for-loops: I'd consider that a separate problem.
You'd want parallel for-loops for things like requests to the same
API, where each promise is handled the same way. `await.all` is more
for handling disparate tasks in parallel without having to resort to
thinking in terms of
Regarding the other `Promise` methods, this syntax could certainly
extend to all of them (that's part of the reason I chose this syntax,
to leave that option open).
`await.any` and `await.race` would work analogously to `await.all`,
but since we're no longer dealing with return values there's no
Typically I find I want to loop over an iterator of items and apply a
function body of work on them in parallel.
So it would be nice to support full blocks of statements that can do this
work in parallel, instead of relying on just expressions or functions to
achieve this.
Extending for loops to
If we have `await.all`, what about `await.race`, `await.allSettled`,
`await.any`?
On Tue, Nov 19, 2019 at 7:45 PM Jacob Bloom
wrote:
> To simplify the problem of working with promises in parallel, I
> propose this new syntax:
>
> ```javascript
> async function initialize() {
> let foo, bar,
47 matches
Mail list logo
