On 12 June 2013 14:12, Claude Pache <claude.pache at gmail.com> wrote:
>
> Le 12 juin 2013 à 12:55, Andreas Rossberg <rossberg at google.com> a écrit :
>
>> On 11 June 2013 21:19, Brendan Eich <brendan at mozilla.com> wrote:
>>> Andreas Rossberg wrote:
>>>>
>>>> That makes a terrible API, though. I think Axel has a valid point that
>>>> the distinction between iterators and iterables is fuzzy enough to be
>>>> more confusing and error-prone than useful.
>>>
>>> Have you actually used Python or JS1.7 much, though?
>>>
>>> Have to ask, since throwing "confusing" and "error-prone" charges demands
>>> evidence or at least anecdotes.
>>
>> It is confusing me, for one -- I don't really understand the
>> difference anymore, nor the intended use cases. Granted, I might be
>> the only one confused. I'm not ready to believe that, though. ;)
>>
>> You see, initially the iterator proposals tried to suggest a simple
>> and understandable model: iterators were objects with a 'next' method,
>> iterables were objects with an @@iterator method that produces an
>> iterator. But neither is true anymore:
>>
>> - Iterators are iterables, they are supposed to have a 'next',
>> optionally a 'throw', and an @@iterator method that returns itself.
>> That is, the iterator interface has become considerably more
>> complicated and is mutually intertwined with iterables.
>>
>> - Iterables are iterators most of the time, except when they aren't.
>> Their @@iterator method may produce a new iterator or, in most cases,
>> not. That is, there is no useful contract of what an iterable is, and
>> it is useless as a concept to implement abstractions against.
>> Nevertheless, people will probably try, and then build something that
>> does not reliably work for all iterables. Thus error-prone.
>>
>> Where things stand now, the only reason we have @@iterator at all is
>> as a hook to provide implicit user-defined conversions from objects to
>> iterators, invoked by the for-of loop (and by extension, yield*).
>>
>> We could simplify spec _and_ programmers' life by explicitly
>> recognizing it as such. That is, for-of invokes a ToIterator
>> conversion meta function, which is the identity for any 'nextable',
>> and tries to invoke @@iterator for others. Thereby drop the misleading
>> notion of iterable, and drop the weird requirement for iterators to be
>> iterables themselves.
>>
>> WDYT?
>>
>> /Andreas
>
> Well, as currently specced, the operation that serves as `ToIterator` conversion meta function is:
>
>         itr => itr[@@iterator]()
>
> If I understand you correctly, you propose that it should be changed to:
>
>         itr => @@iterator in itr ? itr[@@iterator]() : itr
>
> The only place where it would simplify programmers' life, is where they try to define manually an iterator, which I expect to be quite rare.

Maybe, but it's a simplification nevertheless. Moreover, removing a
concept as such reduces cognitive load for everybody. Mind you, these
advantages are minor.

> On the other hand, I see a small advantage of the "weird" requirement for iterators to be iterables themselves: It allows to discriminate between true iterators and merely  "nextable" objects.

And in the spirit of "duck typing", why would you want to do that? And
how do you want to treat an iterable with a 'next' method, but whose
@@iterator method does not return 'this'? Is that a "true" iterator?
(The fact that such a beast can even exist shows how fuzzy those
notions are.)

/Andreas

On 12 June 2013 14:12, Claude Pache <claude.pache at gmail.com> wrote:
> Well, as currently specced, the operation that serves as `ToIterator` conversion meta function is:
>
>         itr => itr[@@iterator]()
>
> If I understand you correctly, you propose that it should be changed to:
>
>         itr => @@iterator in itr ? itr[@@iterator]() : itr
>
> The only place where it would simplify programmers' life, is where they try to define manually an iterator, which I expect to be quite rare.

Maybe, but it's a simplification nevertheless. Moreover, removing a
concept as such reduces cognitive load for everybody. Mind you, these
advantages are minor.

> On the other hand, I see a small advantage of the "weird" requirement for iterators to be iterables themselves: It allows to discriminate between true iterators and merely  "nextable" objects.

And in the spirit of "duck typing", why would you want to do that? And
how do you want to treat an iterable with a 'next' method, but whose
@@iterator method does not return 'this'? Is that a "true" iterator?
(The fact that such a beast can even exist shows how fuzzy those
notions are.)