Re: Why can’t for-of be applied to iterators?

Andreas Rossberg rossberg at google.com
Tue Jun 11 03:50:46 PDT 2013


On 11 June 2013 11:34, Andy Wingo <wingo at igalia.com> wrote:
> On Tue 11 Jun 2013 11:08, Axel Rauschmayer <axel at rauschma.de> writes:
>
>>     The idea that iterators return themselves from their @@iterator
>>     (__iter__) hook has years of actual programmer mileage in Python. I
>>     take that experience seriously, compared to arguments from purity
>>     that tax the common use-cases.
>>
>> I’d be happy with either solution, but let’s compare:
>>
>> AFAICT, the tax is on for-of (and Array.from()): they need to
>> additionally check whether an object is an iterator.
>
> So, my proposal would be to make the for-of RHS expect an iterator, and
> remove the concept of "iterable".  So there's no need to check for
> anything; you just assume you have an iterator.
>
> I don't find the cost of this change (let's not say "tax" ;) terrible:
>
>   for (x of y.values()) f(x);
>
> Or
>
>   for (x of values(y)) f(x);
>
> Though the former seems more javascripty, my impression was that we were
> not adding more prototype methods, in favor of using modules instead.  I
> don't have a @horse_js in that race though.
>
> The reason I think this is OK is because:
>
>   for (x in y) f(x)
>
> translates as
>
>   for (x of keys(y)) f(x)
>
> so to me it is natural that values should also come from a
> function/method call:
>
>   for (x of values(y)) f(x)
>
> As iterators and for-of become more prevelant, I think there are
> actually few times that you want the default iterator -- the reason
> being that you will deal more with iterators and less with reified
> containers like arrays.  The evolution of Python seems to show this, and
> (dare I mention it?) Dart also seems to be going in this direction.
>
> So that's the "cost" side.  The benefit of expecting the RHS to be an
> iterator is that itertools-like combinators become easier to write, and
> that can only be a good thing, as we avoid making intermediate garbage
> containers and eager computation.  As a side benefit, we could remove
> the concept of "iterable" from the spec.  Also we remove the opaque
> @@iterator call from for-of, which can have better error-reporting
> characteristics.

I think Andy is right. The story with iterables is rather messy, and
their benefits (default iterators) might not outweigh their cost (and
in fact, introduce their own usability costs downstream). I like the
suggestion of just dropping them altogether.

/Andreas


More information about the es-discuss mailing list