Generator Arrow Functions

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

Generator Arrow Functions

Brandon Benvie-2
Currently, it's not allowed that arrow functions be generators. I did a
bit of searching and couldn't find the original reasoning behind this.
`*() => {}` doesn't seem to be a problematic grammar since `foo * () =>
{}` isn't valid. The problem I do see is the mismatch between the
generator class hierarchy and the fact that arrow functions don't have
prototypes. I think this could be worked around somehow though.

The use case I've started running into a lot is using Task.js with methods:

```js
class Foo {
   foo() { //--> Promise
     return Task.spawn(*() => {
       const value = yield this.get(this.base + "/foo");
       if (yield this.bar(value)) {
         return true;
       }
     });
   }

   bar(value) { //--> Promise
     /***/
   }

   get(url) { //--> Promise
     /***/
   }
}
```

Without generator arrows, I'm back to using `var self = this` or
`.bind(this)`.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Generator Arrow Functions

Allen Wirfs-Brock
Everybody should probably review esdiscuss.org/topic/why-do-generator-expressions-return-generators where we discussed this before.  

It wasn't that there was necessarily anything bad about them, but there also didn't seem to be a strong enough case made in that thread to justify the work necessary to add them at this late data.

As you mention, there are issues with arrow functions not being constructors, although it probably could be dealt with similarly to how generator comprehensions are handled (generator comprehensions are essentially treated in the spec. as a special form of generator function). 

I also need to think a bit about whether there might be any this binding issues.

Allen




On Nov 12, 2013, at 4:37 PM, Brandon Benvie wrote:

Currently, it's not allowed that arrow functions be generators. I did a bit of searching and couldn't find the original reasoning behind this. `*() => {}` doesn't seem to be a problematic grammar since `foo * () => {}` isn't valid. The problem I do see is the mismatch between the generator class hierarchy and the fact that arrow functions don't have prototypes. I think this could be worked around somehow though.

The use case I've started running into a lot is using Task.js with methods:

```js
class Foo {
 foo() { //--> Promise
   return Task.spawn(*() => {
     const value = yield this.get(this.base + "/foo");
     if (yield this.bar(value)) {
       return true;
     }
   });
 }

 bar(value) { //--> Promise
   /***/
 }

 get(url) { //--> Promise
   /***/
 }
}
```

Without generator arrows, I'm back to using `var self = this` or `.bind(this)`.
_______________________________________________
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: Generator Arrow Functions

Axel Rauschmayer

I’d still argue that generator arrow functions make more sense than generator function declarations.

Axel

On 13 Nov 2013, at 10:13 , Allen Wirfs-Brock <[hidden email]> wrote:

Everybody should probably review esdiscuss.org/topic/why-do-generator-expressions-return-generators where we discussed this before.  

It wasn't that there was necessarily anything bad about them, but there also didn't seem to be a strong enough case made in that thread to justify the work necessary to add them at this late data.

As you mention, there are issues with arrow functions not being constructors, although it probably could be dealt with similarly to how generator comprehensions are handled (generator comprehensions are essentially treated in the spec. as a special form of generator function). 

I also need to think a bit about whether there might be any this binding issues.

-- 
Dr. Axel Rauschmayer

blog: 2ality.com




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

Re: Generator Arrow Functions

David Bruant-5
Le 12/11/2013 18:30, Axel Rauschmayer a écrit :

I’d still argue that generator arrow functions make more sense than generator function declarations.
I don't have a strong opinion in this debate, but I've seen something relevant in Angus Croll's slides [1] recently:

  let idGenerator = (id=0) => () => id++;

  let nextFrom1000 = idGenerator(1000);
  nextFrom1000(); // 1000
  nextFrom1000(); // 1001

David

[1] https://speakerdeck.com/anguscroll/es6-uncensored?slide=42

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

Re: Generator Arrow Functions

Claus Reinke
In reply to this post by Allen Wirfs-Brock
> Everybody should probably review
> esdiscuss.org/topic/why-do-generator-expressions-return-generators where we discussed this before.

which suggests using generator expressions as arrow bodies to make
generator functions with arrows

    () => (for (y of gen) y)

What I don't understand is why generator expressions are not used
as the only way to create generators, leaving 'function' alone. There
would be

- comprehension-style generator expressions, with implicit yield
     (for (...) ...)

- block-style generator expressions, with explicit yield
     (do*{ ... yield value ... })

and generator functions would be build from generator expressions
and functions (arrows or classic). No need to mix up functions and
generators. At least none I can see...

Claus
 

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

Re: Generator Arrow Functions

Brendan Eich-3
Claus Reinke wrote:
> What I don't understand is why generator expressions are not used
> as the only way to create generators, leaving 'function' alone.

We have been over this before: to support flows that for-of loops cannot
expression, specifically coroutine libraries such as http://taskjs.org/.

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

Re: Generator Arrow Functions

Ѓорѓи Ќосев
On Thu 14 Nov 2013 11:16:22 PM CET, Brendan Eich wrote:
> Claus Reinke wrote:
>> What I don't understand is why generator expressions are not used
>> as the only way to create generators, leaving 'function' alone.
>
> We have been over this before: to support flows that for-of loops
> cannot expression, specifically coroutine libraries such as
> http://taskjs.org/.

The suggested topics seem to be ignoring that use case (using the result
of the yield expression) and only considering the iterator case. The
suggestion:

    () => (for (y of gen) y)

isn't going to work for generators that need the values of the yield
expression (like in task.js), right?

    spawn(() *=> yield (yield
this.user.getPendingFriendship(friendId)).setAccepted(true));

 From what I've seen, async generators are so popular (at least in
node-land) that people are building entire frameworks[1] and library
ecosystems[2] based on them even though they're only available behind a
flag, in an unstable version of node. Even more, a dedicated transpiler
was written[3] to support transpiling *just* generators, with the async
use case in mind.

Right now from where I stand, its almost as if the other use case of
generators (as iterators) is completely unimportant.

So I really don't see how there isn't a strong enough case for generator
arrow functions.

[1]: https://github.com/koajs/
[2]: https://github.com/visionmedia/co/wiki
[3]: http://facebook.github.io/regenerator/


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

Re: Generator Arrow Functions

Claus Reinke
In reply to this post by Brendan Eich-3
>> What I don't understand is why generator expressions are not used
>> as the only way to create generators, leaving 'function' alone.
>
> We have been over this before: to support flows that for-of loops cannot
> expression, specifically coroutine libraries such as http://taskjs.org/.

Which is why I keep suggesting block-style generator expressions
in addition to comprehension-style generator expressions. The
equivalent of today's

    function*() { ... yield value ... }

would be

    function() { return do* { ... yield value ... }}

or, if 'function' peculiarities don't matter, the simpler

   () => do* { ... yield value ... }

As far as I can tell, no functionality would go missing. 'function' and
arrow would remain on par and function and generators would
remain separate (but composable) building blocks, leading to a more
modular language spec. You could keep 'function*' as syntactic sugar.

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

Re: Generator Arrow Functions

Axel Rauschmayer
Caveat: with yield*, you want generators to be more like functions than like blocks.


[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer
[hidden email]
Home: http://rauschma.de
Blog: http://2ality.com

On 16.11.2013, at 10:28, "Claus Reinke" <[hidden email]> wrote:

>>> What I don't understand is why generator expressions are not used
>>> as the only way to create generators, leaving 'function' alone.
>> We have been over this before: to support flows that for-of loops cannot expression, specifically coroutine libraries such as http://taskjs.org/.
>
> Which is why I keep suggesting block-style generator expressions
> in addition to comprehension-style generator expressions. The
> equivalent of today's
>
>   function*() { ... yield value ... }
>
> would be
>   function() { return do* { ... yield value ... }}
>
> or, if 'function' peculiarities don't matter, the simpler
>
>  () => do* { ... yield value ... }
>
> As far as I can tell, no functionality would go missing. 'function' and arrow would remain on par and function and generators would
> remain separate (but composable) building blocks, leading to a more
> modular language spec. You could keep 'function*' as syntactic sugar.
>
> Claus
> _______________________________________________
> 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: Generator Arrow Functions

Brendan Eich-3
In reply to this post by Claus Reinke
Claus Reinke wrote:
>>> What I don't understand is why generator expressions are not used
>>> as the only way to create generators, leaving 'function' alone.
>>
>> We have been over this before: to support flows that for-of loops
>> cannot expression, specifically coroutine libraries such as
>> http://taskjs.org/.
>
> Which is why I keep suggesting block-style generator expressions
> in addition to comprehension-style generator expressions.

Which is why I keep responding that blocks are not functions, we do not
have expression continuations, or even block continuations, that can be
captured. (Remember, block lambdas fell in spring 2012). Only functions.

This is really tedious to rehash every few months!

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