domenic at domenicdenicola.com (2013-09-18T18:55:42.152Z)
On Fri, Sep 6, 2013 at 10:59 AM, David Bruant <bruant.d at gmail.com> wrote:
> The presence of .next and .throw will be unnecessarily confusing to authors.
Well, if you need to explain generator comprehensions to someone, I
suggest saying something like:
> "It's just shorthand for a generator"
If we changed it, so that generator comprehensions were simply
iterators, then you could simply explain:
> "It works like a generator, but it gets desugared into an iterator, so there's this one method that you probably won't ever call directly anyway, that isn't there. Oh, what's desugaring? It's when one language feature is explained in terms of others. So for example `(for (x of y) x+1)` desugars into something like `{_it: y[@@iterator](), next() { var st = this._it.next(); if (!st.done) return {value: st.value + 1, done: false}; return st; }}`"
On second thought, maybe equivalences are not so confusing. Maybe
gratuitous inconsistencies are confusing.
I don't really see .throw() on a generator-expression as a "footgun"
either. It does exactly what the .throw() method does for any
user-defined generator, most of which, in practice, will just rethrow
the exception—which by happy coincidence is exactly what it says on
the label:
```js
gen.throw(exc); // shockingly, this will often throw exc
```
People will probably be somewhat disoriented the first time they
encounter generator comprehensions anyway. Coroutines are a little
mind-bending. But throw() really has nothing to do with it. The fact
that these expressions produce an object that's exactly the same as
another language feature is not an obstacle. I expect it'll help.
On Fri, Sep 6, 2013 at 10:59 AM, David Bruant <bruant.d at gmail.com> wrote: > The presence of .next and .throw will be unnecessarily confusing to authors. Well, if you need to explain generator comprehensions to someone, I suggest saying something like: > "It's just shorthand for a generator" If we changed it, so that generator comprehensions were simply iterators, then you could simply explain: > "It works like a generator, but it gets desugared into an iterator, so there's this one method that you probably won't ever call directly anyway, that isn't there. Oh, what's desugaring? It's when one language feature is explained in terms of others. So for example (for (x of y) x+1) desugars into something like {_it: y[@@iterator](), next() { var st = this._it.next(); if (!st.done) return {value: st.value + 1, done: false}; return st; }}" On second thought, maybe equivalences are not so confusing. Maybe gratuitous inconsistencies are confusing. I don't really see .throw() on a generator-expression as a "footgun" either. It does exactly what the .throw() method does for any user-defined generator, most of which, in practice, will just rethrow the exception—which by happy coincidence is exactly what it says on the label: gen.throw(exc); // shockingly, this will often throw exc People will probably be somewhat disoriented the first time they encounter generator comprehensions anyway. Coroutines are a little mind-bending. But throw() really has nothing to do with it. The fact that these expressions produce an object that's exactly the same as another language feature is not an obstacle. I expect it'll help. -j