Questions/issues regarding generators

Brendan Eich brendan at mozilla.com
Thu Mar 14 16:14:28 PDT 2013


Andreas Rossberg wrote:
> On 14 March 2013 23:38, Brendan Eich<brendan at mozilla.com>  wrote:
>> Andreas Rossberg wrote:
>>> That leaves my original proposal not to have generator application
>>> return an iterator, but only an iterable. Under that proposal, your
>>> example requires disambiguation by inserting the intended call(s) to
>>> .iterator in the right place(s).
>> That's horribly inconvenient. It takes Dmitry's example:
>>
>>   function* enum(from, to) { for (let i = from; i<= to; ++i) yield i }
>>
>>   let rangeAsGenerator = enum(1, 4)
>>   let dup = zip(rangeAsGenerator, rangeAsGenerator)  // Oops!
>>
>> which contains a bug under the Harmony proposal, to this:
>>
>>   function* enum(from, to) { for (let i = from; i<= to; ++i) yield i }
>>
>>   let rangeAsGenerator = enum(1, 4)
>>   let dup = zip(rangeAsGenerator[@iterator](), rangeAsGenerator[@iterator]())
>
> No, why? The zip function invokes the iterator method for you.

Sure, but only if you know that. I thought you were advocating explicit 
iterator calls.

A call expression cannot be assumed to return a result that can be 
consumed by some mutating protocol twice, in general. Why should 
generator functions be special?

I agree they could be special-cased, but doing so requires an extra 
allocation (the generator-iterable that's returned).

Meanwhile the Pythonic pattern is well-understood, works fine, and 
(contra Dmitry's speculation) does not depend on class-y OOP in Python.

I guess it's the season of extra allocations, but still: in general when 
I consume foo() via something that mutates its return value, I do not 
expect to be able to treat foo() as referentially transparent. Not in JS!

/be


More information about the es-discuss mailing list