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,
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
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
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
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
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
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,
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
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
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
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
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) { /*...*/
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
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,
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
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.
16 matches
Mail list logo