Proposal: `await.all {...}` for parallelism

manuelbarzi manuelbarzi at gmail.com
Thu Nov 21 09:40:54 UTC 2019


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 promises

results.forEach(result => ...)
```



On Thu, Nov 21, 2019 at 3:37 AM Isiah Meadows <contact at isiahmeadows.com>
wrote:

> 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 experience, committee members are in general
> very hesitant to add syntax for anything that doesn't pay for itself
> well. Similar questions have come up a few times in the past, too, and
> I've commented on two of them. [4] [5]
>
> If anything, I don't feel we know the problem space well enough, and
> the language lacks the primitives needed to really dig into it. (This
> is why I came up with my generator forking strawman. [6])
>
> [1]: https://github.com/isiahmeadows/non-linear-proposal
> [2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
> [3]:
> https://esdiscuss.org/topic/observable-promise-parallel-control-flow-proposal
> [4]: https://esdiscuss.org/topic/stream-async-await
> [5]:
> https://esdiscuss.org/topic/improved-syntax-for-observable-mapping-and-subscribing
> [6]: https://github.com/isiahmeadows/proposal-generator-fork
>
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
>
> On Wed, Nov 20, 2019 at 6:16 PM Jacob Bloom <mr.jacob.bloom at gmail.com>
> wrote:
> >
> > ...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:
> >
> > ```javascript
> > const x = doSomethingAsync();
> > const y = doSomethingElseAsync();
> > await x, await y;
> > // all promises are resolved by now, but
> > // still need to use await to unbox the values
> > someFunction(await x, await y);
> > ```
> >
> > On Wed, Nov 20, 2019 at 3:28 PM Jacob Bloom <mr.jacob.bloom at gmail.com>
> wrote:
> > >
> > > >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 motivation?
> > >
> > > It doesn't seem like the `await.all` block is doing anything in that
> > > case. That code seems equivalent to this:
> > >
> > > ```javascript
> > > const x = doSomethingAsync();
> > > myFunction(await x)
> > > ```
> > >
> > > >```javascript
> > > >await.all {
> > > >  const x = await doSomethingAsync();
> > > >  //x is still undefined here!
> > > >}
> > > >```
> > >
> > > You bring up a good point about scoping and race conditions. It's a
> > > little tricky since the curly braces create a block scope but none of
> > > the parallel statements should be allowed to access each-other's
> > > variables, it's almost like each statement should have its own scope.
> > > Maybe it'd be better to have a syntax that ensures a set of curly
> > > braces for each parallel task? Async do-expressions could be a good
> > > solution (assuming they'd work kind of like an async IIFE):
> > >
> > > ```javascript
> > > async function initialize() {
> > >   let foo, bar, baz;
> > >   await Promise.all([
> > >     async do { foo = (await request('foo.json')).data },
> > >     async do { bar = (await request('bar.json')).data },
> > >     async do { baz = (await request('baz.json')).data },
> > >   ]);
> > >   render(foo, bar, baz);
> > > }
> > > ```
> > >
> > > (this is also a less drastic syntax change that piggybacks on an
> > > existing proposal)
> > >
> > > On Wed, Nov 20, 2019 at 11:50 AM Bergi <a.d.bergi at web.de> wrote:
> > > >
> > > > 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 stuff concurrently *is*
> > > > fundamentally different from doing it serially, and should be
> reasoned
> > > > about every time you use it.
> > > >
> > > > kind regards,
> > > >  Bergi
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > es-discuss at mozilla.org
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20191121/afcbee0f/attachment-0001.html>


More information about the es-discuss mailing list