> Domenic Denicola <mailto:domenic at domenicdenicola.com>
> September 6, 2013 7:44 AM
> Why can't they just return iterable-iterators?
> ...
>
> What does having these be generators buy us? I am almost sure I'm 
> missing something.

The semantics is specified in terms of a generator function 
(non-escaping), with lexical environment inside it.

Anything else that's sane (i.e., that doesn't turn implicit let bindings 
in the for heads into heap properties of hidden objects) would involve 
desugaring into closures (nested if for-of heads nest) to keep the local 
let-bound variables alive.

The spec does not use desugaring, of course. While it could be done, in 
a debugger the results would differ observably from a generator function 
with let bindings. I think the spec should talk about this level of 
observability.

I keep forgetting how the ES6 draft uses "generator comprehension", not 
"generator expression" (the latter is a generator function expression). 
Contrast with Python.

/be

Domenic Denicola <mailto:domenic at domenicdenicola.com> September 6, 2013 7:44 AM
> Why can't they just return iterable-iterators?
> ...
>
> What does having these be generators buy us? I am almost sure I'm 
> missing something.

The semantics is specified in terms of a generator function 
(non-escaping), with lexical environment inside it.

Anything else that's sane (i.e., that doesn't turn implicit let bindings 
in the for heads into heap properties of hidden objects) would involve 
desugaring into closures (nested if for-of heads nest) to keep the local 
let-bound variables alive.

The spec does not use desugaring, of course. While it could be done, in 
a debugger the results would differ observably from a generator function 
with let bindings. I think the spec should talk about this level of 
observability.

I keep forgetting how the ES6 draft uses "generator comprehension", not 
"generator expression" (the latter is a generator function expression). 
Contrast with Python.