domenic at domenicdenicola.com (2013-09-17T19:59:15.269Z)
David Bruant <mailto:bruant.d at gmail.com> September 6, 2013 8:59 AM > There is also a non-generator desugaring (exercise left to the reader). There's always a lambda encoding. So what? First, ES6 doesn't use desugaring to specify its semantics. Second, the closure or closures (plural, for nested for heads) cases are distinct in real implementations from a single generator with blocks. See message sent two back by me. > I don't really care for the name, but I agree with Domenic that there > is no need for the expression to create a generator. > The presence of `.next` and `.throw` will be unnecessarily confusing to > authors. Now you are disagreeing with Domenic on .next. How pray tell would you have an iterator without .next? If you mean that a useless argument can be passed into .next, that is allowed with any iterator too. As for .throw being confusing, I doubt it. Throwing into something that can't catch is like using throw (the keyword) directly. Users can write all sorts of direct and indirect throws already.
> David Bruant <mailto:bruant.d at gmail.com> > September 6, 2013 8:59 AM > Le 06/09/2013 17:39, Brendan Eich a écrit : >> Brandon Benvie wrote: >>> I don't think you're missing anything. They seem to be more >>> accurately described as Iterator Expressions than Generator >>> Expressions. It might be interesting if you could use yield inside >>> them, which would then make sending a value in useful. But without >>> that they don't expose any generator interface externally. >> >> They could be called something else, for sure. The name works because >> they're sugar for a generator function immeidately invoked: >> >> (for (x of [1,2, 3]) x * x) >> >> is >> >> (function*() { for (let x of [1,2, 3]) yield x * x; })() > There is also a non-generator desugaring (exercise left to the reader). There's always a lambda encoding. So what? First, ES6 doesn't use desugaring to specify its semantics. Second, the closure or closures (plural, for nested for heads) cases are distinct in real implementations from a single generator with blocks. See message sent two back by me. > >> The name also may have Python roots that predate Python 2.5's more >> complete (send as well as next; throw; close) generator interface. >> >> I think we should keep the name, because it's more precise. Iterator >> expression could be taken to mean other things a bit too easily. > I don't really care for the name, but I agree with Domenic that there > is no need for the expression to create a generator. > The presence of .next and .throw will be unnecessarily confusing to > authors. Now you are disagreeing with Domenic on .next. How pray tell would you have an iterator without .next? If you mean that a useless argument can be passed into .next, that is allowed with any iterator too. As for .throw being confusing, I doubt it. Throwing into something that can't catch is like using throw (the keyword) directly. Users can write all sorts of direct and indirect throws already. /be