What exactly would be the semantic difference between this and just using
'yield'?
Sam
On Apr 22, 2013 5:40 PM, "Domenic Denicola" <domenic at domenicdenicola.com>
wrote:
> From: Sam Tobin-Hochstadt [samth at ccs.neu.edu]
>
> > I don't see what the point of `await` is in your gist. It looks like
> all of the work is being done by `function^`, which looks to be sugar for
> creating a function and passing it to a scheduler like `Q.async` or
> `taskjs.spawn`. We could add that sugar if we wanted, and not need to add
> `await`.
>
> It's all a bit fuzzy in my head, I admit, but the idea is that `yield`
> should not have its meaning "taken over" by the promises-scheduler meaning.
> E.g. you could envision something that used both promises and generators,
> perhaps to yield a list of values retrieved asynchronously:
>
> ```js
> // ES6
>
> function* doubleSomeNumbers() {
> return getNumbersToDouble().then(function* (numbers) {
> for (var i = 0; i < numbers.length; ++i) {
> yield numbers[i] * 2;
> }
> });
> }
>
>
> // ES-after-6:
>
> function*^ doubleSomeNumbers() {
> const numbers = await getNumbersToDouble();
>
> for (var i = 0; i < numbers.length; ++i) {
> yield numbers[i] * 2;
> }
> }
> ```
>
> This is obviously contrived, but I think illustrates how you might want to
> use both `yield` and `await` for their different meanings, instead of
> letting the wait-for-a-promise meaning take over `yield`.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130422/1b3d0fa7/attachment.html>
github at esdiscuss.org (2013-07-12T02:26:57.835Z)
What exactly would be the semantic difference between this and just using `yield`?
What exactly would be the semantic difference between this and just using 'yield'? Sam On Apr 22, 2013 5:40 PM, "Domenic Denicola" <domenic at domenicdenicola.com> wrote: > From: Sam Tobin-Hochstadt [samth at ccs.neu.edu] > > > I don't see what the point of `await` is in your gist. It looks like > all of the work is being done by `function^`, which looks to be sugar for > creating a function and passing it to a scheduler like `Q.async` or > `taskjs.spawn`. We could add that sugar if we wanted, and not need to add > `await`. > > It's all a bit fuzzy in my head, I admit, but the idea is that `yield` > should not have its meaning "taken over" by the promises-scheduler meaning. > E.g. you could envision something that used both promises and generators, > perhaps to yield a list of values retrieved asynchronously: > > ```js > // ES6 > > function* doubleSomeNumbers() { > return getNumbersToDouble().then(function* (numbers) { > for (var i = 0; i < numbers.length; ++i) { > yield numbers[i] * 2; > } > }); > } > > > // ES-after-6: > > function*^ doubleSomeNumbers() { > const numbers = await getNumbersToDouble(); > > for (var i = 0; i < numbers.length; ++i) { > yield numbers[i] * 2; > } > } > ``` > > This is obviously contrived, but I think illustrates how you might want to > use both `yield` and `await` for their different meanings, instead of > letting the wait-for-a-promise meaning take over `yield`. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130422/1b3d0fa7/attachment.html>