On Fri, Sep 6, 2013 at 10:48 AM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
>> The name works because they're sugar for a generator function immeidately invoked:
>
> I mean, that's true, but *why* is that true?

It's the simplest way to achieve the desired behavior.

> What is the value of allowing you to send in values via `.next(v)`, or send in exceptions via `.throw(e)`? Why not just make them sugar for creating custom iterable-iterators without shallow coroutine capabilities?

The coroutine-ness of a generator comprehension seems inherent to me.
It creates lexical environments. You can observe this if the generator
comprehension creates any closures (or the like) over the variables.

    var it = (for (a of A) () => a++);

Other variations on the theme reveal other aspects of the lexical
environments; direct eval exposes a bunch more and I think rules out
any non-coroutine-based desugaring.

In another, tidier language, perhaps.

So, it's a coroutine. That doesn't mean it must be exposed as a
generator. But why not? Having an extra constructor, prototype, and in
general an extra concept in the spec for objects that are exactly like
generators in every way, but it's maybe not very *useful* to do
certain operations on them, seems like optimizing for the wrong good.

-j

On Fri, Sep 6, 2013 at 10:48 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
>> The name works because they're sugar for a generator function immeidately invoked:
>
> I mean, that's true, but *why* is that true?

It's the simplest way to achieve the desired behavior.

> What is the value of allowing you to send in values via `.next(v)`, or send in exceptions via `.throw(e)`? Why not just make them sugar for creating custom iterable-iterators without shallow coroutine capabilities?

The coroutine-ness of a generator comprehension seems inherent to me.
It creates lexical environments. You can observe this if the generator
comprehension creates any closures (or the like) over the variables.

```js
var it = (for (a of A) () => a++);
```

Other variations on the theme reveal other aspects of the lexical
environments; direct eval exposes a bunch more and I think rules out
any non-coroutine-based desugaring.

In another, tidier language, perhaps.

So, it's a coroutine. That doesn't mean it must be exposed as a
generator. But why not? Having an extra constructor, prototype, and in
general an extra concept in the spec for objects that are exactly like
generators in every way, but it's maybe not very *useful* to do
certain operations on them, seems like optimizing for the wrong good.