await enhancement proposal: Wrap Array return values with Promise.all

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

await enhancement proposal: Wrap Array return values with Promise.all

Rudi Cilibrasi
Greetings,

I have enjoyed using the `await` keyword tremendously in async code. One point I notice in using it is that it is ideal in terms of clarity and composability but limited in a sense to sequential composition. That is, I cannot easily use `await` (by itself) to do parallel calculations.

A few times, I have myself hit a bug where I return (without thinking) an Array of Promise only to find that none will resolve using `await` on the Array. I noticed others have similar bugs. [1,2] I frequently wind up wrapping them in one of two ways: a) occasionally a for loop that awaits each in sequence, but b) more often a `Promise.all`. I think the current `await` syntax makes every kind of sequential composition quite simple to read, write, and maintain, but the fact that we have to introduce `Promise.all` for each case of parallel (overlapping) execution seems to be a common cause of bugs and a minor aesthetic issue to me as well as perhaps maintenance. It occurs to me that for my cases, and indeed perhaps others, a useful rule would be that all `await` on `Array` behave as if the Array were wrapped in `Promise.all`.  Then we can have a nice parallel composition syntax built into the language with the keyword using Array and lists can become idiomatic and concise parallel composition operators. I feel like this could improve the readability, power, and real time responsiveness of the language without necessarily sacrificing quality nor clarity.

await on an Array value v acts as await Promise.all(v)

Weighing against this idea seems to be the usual: operator tricks are unsearchable via keywords compared to `Promise.all`. So there is a style question however with the latest addition of the great new optional-chaining and pipeline ideas I thought it might be a good time to give this idea a try.

What does the group think about this await enhancement proposal?

Best regards,

Rudi Cilibrasi


--

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: await enhancement proposal: Wrap Array return values with Promise.all

Logan Smyth
Making `await` itself do this would be a breaking change, so that'd be very unlikely. There was discussion around an `await*` similar to the existing `yield*` for generators, but I think it was deemed unneeded complexity since `Promise.all` was already pretty easy to use, especially since it isn't 100% obvious from the usage of an array what should be done. For instance `Promise.race` also works on an iterable value. I'm not really involved with the process, so I can't say more though.

On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi <[hidden email]> wrote:
Greetings,

I have enjoyed using the `await` keyword tremendously in async code. One point I notice in using it is that it is ideal in terms of clarity and composability but limited in a sense to sequential composition. That is, I cannot easily use `await` (by itself) to do parallel calculations.

A few times, I have myself hit a bug where I return (without thinking) an Array of Promise only to find that none will resolve using `await` on the Array. I noticed others have similar bugs. [1,2] I frequently wind up wrapping them in one of two ways: a) occasionally a for loop that awaits each in sequence, but b) more often a `Promise.all`. I think the current `await` syntax makes every kind of sequential composition quite simple to read, write, and maintain, but the fact that we have to introduce `Promise.all` for each case of parallel (overlapping) execution seems to be a common cause of bugs and a minor aesthetic issue to me as well as perhaps maintenance. It occurs to me that for my cases, and indeed perhaps others, a useful rule would be that all `await` on `Array` behave as if the Array were wrapped in `Promise.all`.  Then we can have a nice parallel composition syntax built into the language with the keyword using Array and lists can become idiomatic and concise parallel composition operators. I feel like this could improve the readability, power, and real time responsiveness of the language without necessarily sacrificing quality nor clarity.

await on an Array value v acts as await Promise.all(v)

Weighing against this idea seems to be the usual: operator tricks are unsearchable via keywords compared to `Promise.all`. So there is a style question however with the latest addition of the great new optional-chaining and pipeline ideas I thought it might be a good time to give this idea a try.

What does the group think about this await enhancement proposal?

Best regards,

Rudi Cilibrasi


--
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: await enhancement proposal: Wrap Array return values with Promise.all

Michael Rosefield
Would it be possible to extend `await` such that you could `await.all()`?

If not, one minor thing that might help cut down the noise (if it works with native Promises without this-binding; I've done it with RSVP):

```
const { all } = Promise;

await all(/* */);
```

On Sun, 23 Sep 2018, 02:53 Logan Smyth, <[hidden email]> wrote:
Making `await` itself do this would be a breaking change, so that'd be very unlikely. There was discussion around an `await*` similar to the existing `yield*` for generators, but I think it was deemed unneeded complexity since `Promise.all` was already pretty easy to use, especially since it isn't 100% obvious from the usage of an array what should be done. For instance `Promise.race` also works on an iterable value. I'm not really involved with the process, so I can't say more though.

On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi <[hidden email]> wrote:
Greetings,

I have enjoyed using the `await` keyword tremendously in async code. One point I notice in using it is that it is ideal in terms of clarity and composability but limited in a sense to sequential composition. That is, I cannot easily use `await` (by itself) to do parallel calculations.

A few times, I have myself hit a bug where I return (without thinking) an Array of Promise only to find that none will resolve using `await` on the Array. I noticed others have similar bugs. [1,2] I frequently wind up wrapping them in one of two ways: a) occasionally a for loop that awaits each in sequence, but b) more often a `Promise.all`. I think the current `await` syntax makes every kind of sequential composition quite simple to read, write, and maintain, but the fact that we have to introduce `Promise.all` for each case of parallel (overlapping) execution seems to be a common cause of bugs and a minor aesthetic issue to me as well as perhaps maintenance. It occurs to me that for my cases, and indeed perhaps others, a useful rule would be that all `await` on `Array` behave as if the Array were wrapped in `Promise.all`.  Then we can have a nice parallel composition syntax built into the language with the keyword using Array and lists can become idiomatic and concise parallel composition operators. I feel like this could improve the readability, power, and real time responsiveness of the language without necessarily sacrificing quality nor clarity.

await on an Array value v acts as await Promise.all(v)

Weighing against this idea seems to be the usual: operator tricks are unsearchable via keywords compared to `Promise.all`. So there is a style question however with the latest addition of the great new optional-chaining and pipeline ideas I thought it might be a good time to give this idea a try.

What does the group think about this await enhancement proposal?

Best regards,

Rudi Cilibrasi


--
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: await enhancement proposal: Wrap Array return values with Promise.all

Michał Wadas

On Mon, 24 Sep 2018, 16:21 Michael Luder-Rosefield, <[hidden email]> wrote:
Would it be possible to extend `await` such that you could `await.all()`?

If not, one minor thing that might help cut down the noise (if it works with native Promises without this-binding; I've done it with RSVP):

```
const { all } = Promise;

await all(/* */);
```

On Sun, 23 Sep 2018, 02:53 Logan Smyth, <[hidden email]> wrote:
Making `await` itself do this would be a breaking change, so that'd be very unlikely. There was discussion around an `await*` similar to the existing `yield*` for generators, but I think it was deemed unneeded complexity since `Promise.all` was already pretty easy to use, especially since it isn't 100% obvious from the usage of an array what should be done. For instance `Promise.race` also works on an iterable value. I'm not really involved with the process, so I can't say more though.

On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi <[hidden email]> wrote:
Greetings,

I have enjoyed using the `await` keyword tremendously in async code. One point I notice in using it is that it is ideal in terms of clarity and composability but limited in a sense to sequential composition. That is, I cannot easily use `await` (by itself) to do parallel calculations.

A few times, I have myself hit a bug where I return (without thinking) an Array of Promise only to find that none will resolve using `await` on the Array. I noticed others have similar bugs. [1,2] I frequently wind up wrapping them in one of two ways: a) occasionally a for loop that awaits each in sequence, but b) more often a `Promise.all`. I think the current `await` syntax makes every kind of sequential composition quite simple to read, write, and maintain, but the fact that we have to introduce `Promise.all` for each case of parallel (overlapping) execution seems to be a common cause of bugs and a minor aesthetic issue to me as well as perhaps maintenance. It occurs to me that for my cases, and indeed perhaps others, a useful rule would be that all `await` on `Array` behave as if the Array were wrapped in `Promise.all`.  Then we can have a nice parallel composition syntax built into the language with the keyword using Array and lists can become idiomatic and concise parallel composition operators. I feel like this could improve the readability, power, and real time responsiveness of the language without necessarily sacrificing quality nor clarity.

await on an Array value v acts as await Promise.all(v)

Weighing against this idea seems to be the usual: operator tricks are unsearchable via keywords compared to `Promise.all`. So there is a style question however with the latest addition of the great new optional-chaining and pipeline ideas I thought it might be a good time to give this idea a try.

What does the group think about this await enhancement proposal?

Best regards,

Rudi Cilibrasi


--
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss