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
Generator Arrow Functions
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). ___ 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: Modules vs Scripts
Could someone help me understand why two goals for parsing JS is a good
thing?
On Mon, Nov 11, 2013 at 3:30 PM, John Barton johnjbar...@google.com wrote:
Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import {WrapNewObjectTransformer} from './WrapNewObjectTransformer';
export function transcode(src, url) {
var file = new SourceFile(url, src);
var reporter = new ErrorReporter();
var tree = new Parser(reporter, file).parseProgram(true);
return (new WrapNewObjectTransformer()).transformAny(tree);
}
It fails on 'unexpected token export'. This was unexpected by me ;-)
However it does seem consistent with the grammar in
http://wiki.ecmascript.org/doku.php?id=harmony:modules. The |export|
keyword is part of an ExportDeclaration which appears in a ModuleElement
but not in a ScriptElement. The parser believes it is parsing a Script. So
the only way to legally parse JS as a Module is as a side-effect of module
loading?
I suppose that a Script is intended to be the root of the dependency tree,
so the error message is trying to tell me You are compiling an interior
node of the dependency tree silly. But both Script and Module are things
that JS devs will want to compile. Concretely I will want to be able to
copy the contents of a JS file and paste it into a repl window to analyze
it without having it die on syntax errors because it is a module.
hth,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
2013/11/11 Mark S. Miller erig...@google.com Much of the early Actors research DEC SRC Network Objects RMI Original-E before I arrived at Electric Communities Midori Orleans AmbientTalk Cap'n Proto While I'm honored to see AmbientTalk listed among these systems, I should note that, pertinent to this discussion, AmbientTalk made exclusive use of leasing to manage distributed resources. There was no other form of DGC. It was partly inspired by the leasing policies in .NET Remoting (.NET's counterpart of Java RMI). Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
2013/11/13 Mark S. Miller erig...@google.com * Weak consistency (I know, people hear CAP and give up too much) won, which surprised some. Because Promises are asynchronous, even locally, the state of the world when a promise-based request is made differs from the one in which the request is received. Since partition induces rejection of all promises across that partition, connection recovery takes distinct paths through the code where one copes, in an application dependent manner, with having been out of communication. Further support for weak consistency should come at a higher level, e.g., via the Unum model https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt. Promises are a good substrate on which to build Una. One of the most compelling approaches I've seen to date to enable eventual consistency at a higher level is the recent work out of Microsoft Research on cloud (data)types. See http://research.microsoft.com/apps/pubs/default.aspx?id=163842. Tim Coppieters, a student of mine, recently implemented the model as a pure JS library, enabling easy replication of state among client and server (node.js). His CloudTypes.js library is available at https://github.com/ticup/CloudTypes. I'm pretty excited about the elegance/simplicity of the model. The library is well-documented. Worth a look for those into distributed systems. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Formalize error.stack?
Column numbers are essential. On Nov 12, 2013 12:28 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I think V8's is preferred. IE10 adopted it, and there's a lot of stack-parsing going on in Node.js land. If SpiderMonkey and JSC would come around to that, it would be lovely. ___ 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
