I have no idea why both you and Brendan assert that I was arguing/
rehashing for deep delimited continuations (let alone call/cc).
Because you wrote:
1 can be worked around, but not with the usual tools of function
definitions and calls - yield forces use of function* and yield*
for
Hi Claus,
On Wed 24 Jul 2013 22:07, Claus Reinke claus.rei...@talk21.com writes:
2 generators do not compose as freely as iteration functions,
because they are tied to special syntax and restricted contexts
You place blame on generators here, but beside the laments about deep
coroutines --
2 generators do not compose as freely as iteration functions,
because they are tied to special syntax and restricted contexts
You place blame on generators here, but beside the laments about deep
coroutines -- totally understandable, but Brendan is right that that
they are pointless -- your
Claus Reinke wrote:
I have no idea why both you and Brendan assert that I was arguing/
rehashing for deep delimited continuations (let alone call/cc).
Because you wrote:
1 can be worked around, but not with the usual tools of function
definitions and calls - yield forces use of function*
And why not? Because yield is a statement
Yield is an expression.
Thanks for the correction. Yes, yield expr is an expression, syntactically.
It doesn't have the nice composition and code transformation properties
that I usually associate with expressions, it imposes unusual restrictions
Claus Reinke wrote:
And why not? Because yield is a statement
Yield is an expression.
Thanks for the correction. Yes, yield expr is an expression,
syntactically.
It doesn't have the nice composition and code transformation
properties that I usually associate with expressions, it imposes
Hello,
On Wed 17 Jul 2013 10:50, Claus Reinke claus.rei...@talk21.com writes:
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
For the specific case of forEach et al
What do you mean by et al? I don't believe .map, .reduce or .filter
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
I have been thinking and with for..of, I can't find a good reason to use
.forEach instead of for..of.
for..of does what you need here with generators too.
I've been looking at this
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
I have been thinking and with for..of, I can't find a good reason to use
.forEach instead of for..of.
for..of does what you need here with generators too.
Perhaps you're right that .forEach
2013/7/17 Claus Reinke claus.rei...@talk21.com
For the specific case of forEach et al
What do you mean by et al? I don't believe .map, .reduce or .filter are
any interesting to use alongside generators.
And why not? Because yield is a statement, and because those
operations have not
[Freaking Gmail shortcuts! Sorry about that]
2013/7/17 David Bruant bruan...@gmail.com
Interestingly, myArray.filter(filterG).map(mapG) could be sort-of a lazy
value. Actual computation filterG and mapG happens only when generating
values from the
final generator.
This might enable
...@gmail.com; es-discusses-discuss@mozilla.org
Subject: RE: generators vs forEach
Bruno, wouldn't yield* work here to delegate the inner yields?
Sent from my Windows Phone
--
From: Bruno Jouhier bjouh...@gmail.com
Sent: 7/15/2013 4:12 PM
To: es-discuss es-discuss
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
This would make generators deep, violating the non-interleaving assumptions
of intermediate callers on the call stack. This is why we accepted
generators only on condition that they be
Mark S. Miller wrote:
On Tue, Jul 16, 2013 at 10:54 AM, Claus Reinke
claus.rei...@talk21.com mailto:claus.rei...@talk21.com wrote:
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
This would make generators deep,
Le 16/07/2013 19:54, Claus Reinke a écrit :
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
I have been thinking and with for..of, I can't find a good reason to use
.forEach instead of for..of.
for..of does what you need here with
On Tue, Jul 16, 2013 at 3:45 PM, David Bruant bruan...@gmail.com wrote:
Le 16/07/2013 19:54, Claus Reinke a écrit :
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
I have been thinking and with for..of, I can't find a good reason to
[prompted by this nodejs list thread
Weird error with generators (using suspend or galaxy)
https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4 ]
1. higher order functions are used to model control structures
2. generators/yield are designed to allow for suspend/resume
of control
Alternatively, could `yield` simply be lexically bound to the nearest
GeneratorFunction scope, rather than the nearest Function?
E.g., instead of:
suspend(function* (resume) {
yield setTimeout(resume, 1000);
console.log('foo');
yield setTimeout(resume, 1000);
console.log('bar');
})();
... we
I believe duplicating the `Array.prototype` built-ins as generator versions, in
user-code, is the expected path forward. Perhaps an itertools-like module
will be standardized and added in ES7, after that cowpath has been paved.
This pain is somewhat alleviated by generator expressions (which
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint satisfy
the shallow generator requirement? As I understand it, the issue with deep
generators and CPS transformations is that the transformations have to be
applied to functions that aren't even lexically inside the
On 7/15/2013 10:24 AM, Jeremy Martin wrote:
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint
satisfy the shallow generator requirement? As I understand it, the
issue with deep generators and CPS transformations is that the
transformations have to be applied to functions
That means CPS transforming functions based on whether they call a
yielding function.
Well, yes :) Admittedly, that does seem messy. Not to sound defeatist,
but I'm sensing that I don't actually have the necessary knowledge to
further argue this. I'll just end with saying that it'll be
Jeremy Martin wrote:
Regardless of whatever solutions may or may not be appropriate, I at
a minimum echo Claus' sentiment - it seems like there's a nice
opportunity here to improve the modeling of control structures.
You're right, but the problem Mark cites is a big one and it stops any
There is no need to CPS transform functions and there is no need for
deferred functions either. It can all be done with today's generators and a
little helper library.
With the C# async/await notation:
- The yield keyword is your await keyword.
- The little * in function* is your async
Bruno, wouldn't yield* work here to delegate the inner yields?
Sent from my Windows Phone
From: Bruno Jouhiermailto:bjouh...@gmail.com
Sent: 7/15/2013 4:12 PM
To: es-discussmailto:es-discuss@mozilla.org
Subject: Re: generators vs forEach
There is no need
...@gmail.com;
es-discussmailto:es-discuss@mozilla.org
Subject: RE: generators vs forEach
Bruno, wouldn't yield* work here to delegate the inner yields?
Sent from my Windows Phone
From: Bruno Jouhiermailto:bjouh...@gmail.com
Sent: 7/15/2013 4:12 PM
To: es
26 matches
Mail list logo
