Re: Generator Arrow Functions
On 27 Nov 2013, at 3:29 , Brendan Eich bren...@mozilla.com wrote: [...] also some future-hostility to function! wanting =! (remember ! is a unary prefix operator). Other spellings all have ASI or other future-hostility woes. What is `function!` ? Or will that be explained in the meeting notes, too? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
It is one proposed syntax for async functions. On Nov 27, 2013 6:20 AM, Axel Rauschmayer a...@rauschma.de wrote: On 27 Nov 2013, at 3:29 , Brendan Eich bren...@mozilla.com wrote: [...] also some future-hostility to function! wanting =! (remember ! is a unary prefix operator). Other spellings all have ASI or other future-hostility woes. What is `function!` ? Or will that be explained in the meeting notes, too? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/26/2013 02:28 PM, Claude Pache wrote: From the thread [1], I guess that parsing correctly the following thing would be obnoxious (at best)? (a = yield/b/g) =* {} —Claude Indeed. And you can make even more obnoxious parses of the hypothetical combination of =*, default parameters, and retroactive yield-scope: (a = yield//) =* (//g) Are the two //'s regexps or is /) =* (/ a string token? Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/26/2013 02:28 PM, Claude Pache wrote: / From the thread [1], I guess that parsing correctly the following thing would be obnoxious (at best)? // // (a = yield/b/g) =* {} // // ---Claude / Indeed. And you can make even more obnoxious parses of the hypothetical combination of =*, default parameters, and retroactive yield-scope: (a = yield//) =* (//g) Are the two //'s regexps or is /) =* (/ a string token? Waldemar Are you sure? The `(a = yield/b/g)` part is parsed at first as a parenthesised expression and only later (after the `=` token) reinterpreted as an ArrowFormalParameters grammar production. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/26/2013 03:00 PM, André Bargull wrote: On 11/26/2013 02:28 PM, Claude Pache wrote: / From the thread [1], I guess that parsing correctly the following thing would be obnoxious (at best)? // // (a = yield/b/g) =* {} // // —Claude / Indeed. And you can make even more obnoxious parses of the hypothetical combination of =*, default parameters, and retroactive yield-scope: (a = yield//) =* (//g) Are the two //'s regexps or is /) =* (/ a string token? Waldemar Are you sure? The `(a = yield/b/g)` part is parsed at first as a parenthesised expression and only later (after the `=` token) reinterpreted as an ArrowFormalParameters grammar production. - André Fine, so do this one instead: (a = yield//g, b = yield//g) =* {} Does this generator have one or two parameters? Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/27/2013 12:07 AM, Waldemar Horwat wrote: On 11/26/2013 03:00 PM, André Bargull wrote: On 11/26/2013 02:28 PM, Claude Pache wrote: / From the thread [1], I guess that parsing correctly the following thing would be obnoxious (at best)? // // (a = yield/b/g) =* {} // // —Claude / Indeed. And you can make even more obnoxious parses of the hypothetical combination of =*, default parameters, and retroactive yield-scope: (a = yield//) =* (//g) Are the two //'s regexps or is /) =* (/ a string token? Waldemar Are you sure? The `(a = yield/b/g)` part is parsed at first as a parenthesised expression and only later (after the `=` token) reinterpreted as an ArrowFormalParameters grammar production. - André Fine, so do this one instead: (a = yield//g, b = yield//g) =* {} Does this generator have one or two parameters? It depends on the surrounding environment. Lexical token sequence in function environment: LP Ident[a] Assign Ident[yield] Div String Div Ident[g] RP Lexical token sequence in generator environment: LP Ident[a] Assign Yield RegExp Comma Ident[b] Assign Yield RegExp RP Reinterpreting the lexical token sequence per [14.2]: It is a Syntax Error if the lexical token sequence matched by CoverParenthesisedExpressionAndArrowParameterList cannot be parsed with no tokens left over using ArrowFormalParameters as the goal symbol. And applying the current (rev21) grammar production rule `FormalParameters[Yield,GeneratorParameter]` [14.4], gives either a generator with a single parameter (if in function environment) or a SyntaxError (if in generator environment). The SyntaxError is emitted because `FormalParameters[Yield,GeneratorParameter]` does not allow YieldExpressions [13.2.3], instead yield is treated as an IdentifierReference in function default parameters. If the term parsing a lexical token sequence allows you to go back to the source character level, the result will be different, of course. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
André Bargull wrote: If the term parsing a lexical token sequence allows you to go back to the source character level, the result will be different, of course. Just to let everyone know (meeting notes, coming soon, will make this clear), we agreed not to do generator arrows. Too much trouble of the kind identified here, also some future-hostility to function! wanting =! (remember ! is a unary prefix operator). Other spellings all have ASI or other future-hostility woes. Sorry, Brandon. Worth a try, but no go. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
+1 on arrowed generators! Have being actively using generators last month have being wishing they could be like arrows, although syntax I've being thinking of was (x, y) * { } BTW given that generators are used as a method on iterators wouldn't it make sense to consider syntax for generator members in a classes syntax ?? My hope is in ES6 we would just use class syntax for methods arros for functions making function a legacy On Monday, November 18, 2013, Brendan Eich wrote: Ѓорѓи Ќосев wrote: Its harder to scan whether this is a generator arrow function or a normal arrow function because the star is too far away: someFunction(*(someArgument, anotherArgument) = { ... code ... }); compared to this form, where its immediately obvious that this is not a regular function, just by looking at the composed symbol (arrow-star) someFunction((someArgument, anotherArgument) =* { ... code ... }); I buy it. This is what I'll propose next week as concrete syntax. It's a small point, but the rationale is the star goes after the first token that identifies the special form as a function form. For generator functions, that token is 'function'. For arrows, it is '='. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
+1 on arrowed generators! Have being actively using generators last month have being wishing they could be like arrows, although syntax I've being thinking of was (x, y) * { } BTW given that generators are used as a method on iterators wouldn't it make sense to consider syntax for generator members in a classes syntax ?? It’s already in the spec: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions My hope is in ES6 we would just use class syntax for methods arros for functions making function a legacy My hope, too. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Oh I must have missed that, never mind then thanks Axel for pointing out. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Wednesday, 2013-11-20 at 03:22 , Axel Rauschmayer wrote: +1 on arrowed generators! Have being actively using generators last month have being wishing they could be like arrows, although syntax I've being thinking of was (x, y) * { } BTW given that generators are used as a method on iterators wouldn't it make sense to consider syntax for generator members in a classes syntax ?? It’s already in the spec: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions My hope is in ES6 we would just use class syntax for methods arros for functions making function a legacy My hope, too. -- Dr. Axel Rauschmayer a...@rauschma.de (mailto:a...@rauschma.de) home: rauschma.de (http://rauschma.de/)twitter: twitter.com/rauschma (http://twitter.com/rauschma) blog: 2ality.com (http://2ality.com/) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/15/2013 06:18 PM, Claude Pache wrote: Le 15 nov. 2013 à 17:59, Rick Waldron waldron.r...@gmail.com mailto:waldron.r...@gmail.com a écrit : On Fri, Nov 15, 2013 at 11:34 AM, Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de wrote: (...) That would make the async programming code more compact, too (I’m assuming a nullary paren-free arrow variant and I prefer the asterisk after the arrow): To be clear, this preference is inconsistent with all other generator forms where the asterisk is before the params, per Brandon's original examples. The other point of view is that this preference is consistent with other generator forms where the asterisk is after the token that defines the general role of the construct as a procedure (either the `function` keyword, or the `=` token). Personally, I tend to read `function*`as a unit meaning generator function, and so would I for `=*`. There is one reason (that is beyond bikeshedding) why I think the star should be together with the arrow. (I have no opinion whether it should be before or after the arrow though) Its harder to scan whether this is a generator arrow function or a normal arrow function because the star is too far away: someFunction(*(someArgument, anotherArgument) = { ... code ... }); compared to this form, where its immediately obvious that this is not a regular function, just by looking at the composed symbol (arrow-star) someFunction((someArgument, anotherArgument) =* { ... code ... }); The arbitrary length of arguments, as well as the ability to split them to multiple lines makes it potentially even harder to reliably locate the star: someFunction(*(argument, anotherArgument, somethingThird) = { ... code ... }); vs someFunction((argument, anotherArgument, somethingThird) =* { ... code ... }); Here is the single-argument example, for completeness: someFunction(*singleArgument = yield asyncOp(singleArgument)); versus someFunction(singleArgument =* yield asyncOp(singleArgument)); in which it looks like the star is somehow related to the argument. If you're not convinced, you can try to find all the arrow-stars in the above code, then try to find all the arrows and determine whether they're generator arrows or regular arrows :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Ѓорѓи Ќосев wrote: Its harder to scan whether this is a generator arrow function or a normal arrow function because the star is too far away: someFunction(*(someArgument, anotherArgument) = { ... code ... }); compared to this form, where its immediately obvious that this is not a regular function, just by looking at the composed symbol (arrow-star) someFunction((someArgument, anotherArgument) =* { ... code ... }); I buy it. This is what I'll propose next week as concrete syntax. It's a small point, but the rationale is the star goes after the first token that identifies the special form as a function form. For generator functions, that token is 'function'. For arrows, it is '='. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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 a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com On 16.11.2013, at 10:28, Claus Reinke claus.rei...@talk21.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Heck, why not just add async functions to the agenda? There's: - Promises, yay - A well-establish use-case, which is awkward to implement without (as the original post demonstrates) - Strong syntactic precedent with C# - Strong semantic cowpath with TaskJS - Strong developer interest - A year to work out any kinks : ) By async function, I mean something like: async function F(p1, p2, ...pN) { await G(); } which would de-sugar to something like: function F(...args) { return Task.spawn(function(p1, p2, ...pN) { (yield G()); }.bind(this, ...args)); } With a [NoNewLine] after the async contextual keyword, obviously. Low-risk, high-reward? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Kevin Smith mailto:zenpars...@gmail.com November 16, 2013 6:56 AM Heck, why not just add async functions to the agenda? They are on the further-out agenda for ES7, but Object.observe is ahead, and it is driving the event-loop task/microtask specification, which async functions need too. None of this fits in ES6. In contrast, generator arrows are relatively straightforward and might fit in ES6. No schedule chicken, in either case, but no way do async functions + event loop full spec fit in ES6. There's: - Promises, yay - A well-establish use-case, which is awkward to implement without (as the original post demonstrates) More awkward without generator arrows, but survivable in any event. - Strong syntactic precedent with C# Syntax is the last of it. BTW Mark was advocating function!, not async function, so there will be bikeshedding. - Strong semantic cowpath with TaskJS No. That's not a scheduler + event loop spec, and the scheduler there is not the only one or even the default one people will agree to. - Strong developer interest That applies to a great many things, and libraries are go. - A year to work out any kinks : ) No, you're wrong -- ES6 is all but done by March, in the fussing over typography, heading toward Ecma CC approval in June and GA approval in December. There is no year. Any kinks would be set in stone and unchangable in a few months. By async function, I mean something like: async function F(p1, p2, ...pN) { await G(); } which would de-sugar to something like: function F(...args) { return Task.spawn(function(p1, p2, ...pN) { (yield G()); }.bind(this, ...args)); } With a [NoNewLine] after the async contextual keyword, obviously. Low-risk, high-reward? See above. You've completely ignored interoperable scheduler specification, which depends on event loop spec in full. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
- A year to work out any kinks : ) No, you're wrong -- I welcome correction as always, but I would appreciate being able to post to es-discuss without having to worry about this kind of backlash. Thanks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Kevin Smith wrote: - A year to work out any kinks : ) No, you're wrong -- I welcome correction as always, but I would appreciate being able to post to es-discuss without having to worry about this kind of backlash. Thanks. Sorry. How about you're mistaken? :-| Allen has laid out the schedule several times on this list. Excuse my grumpy tone. List search still isn't what it ought to be. On the other hand, with no spec for the event loop and the (pluggable, what's the default) scheduler, we are pretty far from async functions being something to push for in ES6. Do you see what I mean? I see your point(s) about generator arrows (both less important given async functions, and late for ES6). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Brendan Eich wrote: Sorry. How about you're mistaken? :-| Wow, still grumpy when I wrote that. Yikes. Ok, trying again: please accept my apology for laying about with the personal Y pronoun, the to-be verb, and wrong. That's never productive. The why leading to any such conclusion is the key to useful discussion. I'll keep focused on that. Sorry, for real. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Thanks - and thanks for pointing out the dependency on a scheduling specification. 3, for real. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 15 Nov 2013, at 08:47, Kevin Smith zenpars...@gmail.com wrote: From the examples I've seen so far in this discussion, it's likely that what is wanted isn't generator arrows, as much as syntactic support for asyc functions. Such a function, would, among other things, insure that all exceptions are converted to rejections, even exceptions occurring in the head (as can occur with argument destructuring and default parameter evaluation). +1. Although, the outer-this-capturing nature of arrow functions would probably be nice for some async functions too. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On Nov 15, 2013, at 5:54 AM, Domenic Denicola dome...@domenicdenicola.com wrote: On 15 Nov 2013, at 08:47, Kevin Smith zenpars...@gmail.com wrote: From the examples I've seen so far in this discussion, it's likely that what is wanted isn't generator arrows, as much as syntactic support for asyc functions. Such a function, would, among other things, insure that all exceptions are converted to rejections, even exceptions occurring in the head (as can occur with argument destructuring and default parameter evaluation). +1. Although, the outer-this-capturing nature of arrow functions would probably be nice for some async functions too. It would be great to have await, but in the meantime having generator functions would help male async methods tolerable. Await is ES7 at the earliest, generator arrow functions could be in ES6. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
It would be great to have await, but in the meantime having generator functions would help male async methods tolerable. Await is ES7 at the earliest, generator arrow functions could be in ES6. Couldn’t arrow generator functions replace generator function declarations? In other words: is the dynamic `this` in generator function declarations ever useful? Then we’d have a nice symmetry in ES6: – non-method function = const + arrow function. – method = concise method definition – non-method generator function = const + arrow generator function. – generator method = concise generator method definition That would make the async programming code more compact, too (I’m assuming a nullary paren-free arrow variant and I prefer the asterisk after the arrow): ```js spawn(=* { var data = yield $.ajax(url); $('#result').html(data); var status = $('#status').html('Download complete.'); yield status.fadeIn().promise(); yield sleep(2000); status.fadeOut(); }); ``` Versus: ```js spawn(function*() { var data = yield $.ajax(url); $('#result').html(data); var status = $('#status').html('Download complete.'); yield status.fadeIn().promise(); yield sleep(2000); status.fadeOut(); }); ``` [Example taken from task.js website.] -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On Fri, Nov 15, 2013 at 11:34 AM, Axel Rauschmayer a...@rauschma.de wrote: It would be great to have await, but in the meantime having generator functions would help male async methods tolerable. Await is ES7 at the earliest, generator arrow functions could be in ES6. Couldn’t arrow generator functions replace generator function declarations? In other words: is the dynamic `this` in generator function declarations ever useful? As useful as it is in non-generator function declarations and expressions. I agree that a generator arrow function adds balance, but replacement of generator function declarations contradicts a balance. Then we’d have a nice symmetry in ES6: – non-method function = const + arrow function. – method = concise method definition – non-method generator function = const + arrow generator function. – generator method = concise generator method definition Let me counter with: function declaration, generator function declaration function expression, generator function expression concise method, concise generator method arrow function (, generator arrow function) That would make the async programming code more compact, too (I’m assuming a nullary paren-free arrow variant and I prefer the asterisk after the arrow): To be clear, this preference is inconsistent with all other generator forms where the asterisk is before the params, per Brandon's original examples. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
It would be great to have await, but in the meantime having generator functions would help male async methods tolerable. Await is ES7 at the earliest, generator arrow functions could be in ES6. Adding new features to ES6 at this point in time? I don't know... Besides, with async functions, the use case established in this thread for generator arrows basically disappears. It's probably better not to introduce convenience features that will be made obsolete by the next version of the language. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Let me counter with: function declaration, generator function declaration function expression, generator function expression concise method, concise generator method arrow function (, generator arrow function) I don’t mind generator function declarations, but I personally will not use function declarations under ES6 (or at least try out const arrows and see how they feel). And I’ll do the same with generator function declarations, should we get generator arrow functions. If it works out then function declarations are a legacy feature (for me). That would make the async programming code more compact, too (I’m assuming a nullary paren-free arrow variant and I prefer the asterisk after the arrow): To be clear, this preference is inconsistent with all other generator forms where the asterisk is before the params, per Brandon's original examples. Ah, missed that. Thought it was *=. I don’t mind either way, my (admittedly weak) mnemonic would be “asterisk after function-defining token”. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Le 15 nov. 2013 à 17:59, Rick Waldron waldron.r...@gmail.com a écrit : On Fri, Nov 15, 2013 at 11:34 AM, Axel Rauschmayer a...@rauschma.de wrote: (...) That would make the async programming code more compact, too (I’m assuming a nullary paren-free arrow variant and I prefer the asterisk after the arrow): To be clear, this preference is inconsistent with all other generator forms where the asterisk is before the params, per Brandon's original examples. The other point of view is that this preference is consistent with other generator forms where the asterisk is after the token that defines the general role of the construct as a procedure (either the `function` keyword, or the `=` token). Personally, I tend to read `function*`as a unit meaning generator function, and so would I for `=*`. —Claude Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
On 11/15/2013 06:07 PM, Kevin Smith wrote: Besides, with async functions, the use case established in this thread for generator arrows basically disappears. It's probably better not to introduce convenience features that will be made obsolete by the next version of the language. Can someone explain how would that use case disappear with async functions? If by async functions you mean something that would allow await [1] - as far as I understand, this already works with generators: function* getAllUserDataLazily() { for (const userName of users) { yield getUserData(userName); } } function* outerGenerator() { for (const dataPromise of getAllUserDataLazily()) { console.log(yield dataPromise); } } The inner `getAllUserDataLazily` generator yields promise values to the `outerGenerator`, then pauses. The outer generator is run by the async task runner and it yields the promise, then it also pauses. The task runner's code now waits for the promise to resolve. Once the promise resolves, it resumes the `outerGenerator`. Once the `outerGenerator` resumes, it goes back to the beginning of the loop and resumes `getAllUserDataLazily`. Basically, as long as the outermost generator is run by an async runner, both lazy and async execution of all nested generators/iterators is possible. Another benefit is that this works with primitives other than promises. Current libraries will love that, as not all are based on promises. By the time ES7 is released, a large ecosystem of async generators will already be in place. Infact, its already here, right now - and ES6 isn't even finalized yet. This is a guess, but I'd say that at that point, a new async functions feature will be seen as unnecessary and async generators as good enough. IMO, the cat is already out of the bag. [1]: https://gist.github.com/domenic/6656283 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
I've added generator arrows to the TC39 meeting agenda for next week. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Basically, as long as the outermost generator is run by an async runner, both lazy and async execution of all nested generators/iterators is possible. Sure - it's the async runner part though (e.g. `spawn`), which is the use case presented here. async function F(p1, p2, ...pN) { /*...*/ } Would (very) approximately de-sugar to something like: function F(...args) { return spawn(this, args, function* (p1, p1, ...pN) { /* ... */ }); } ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
Le 12/11/2013 18:30, Axel Rauschmayer a écrit : This is relevant, too: http://esdiscuss.org/topic/function-declarations-with-lexical-this 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss