April 10 2014 Meeting Notes

[Andreas Rossberg]

> ## Revisiting: Generator Issues
> (Jafar Husain)
>
> [...]
>
> JH: The crucial problem: the iterator claims to be an iterable and it's not.
> ...If async generators return Iterables, not Iterators.
>
> WH: How
>
> JH: If I accept an iterable and invoke `@@iterator`, I would expect to get a
> fresh iterator from each call
>
> MM: everythime you for-of you expect to see "the stuff"
>
> JH: Iterators are claiming to Iterables, which is a lie.

I argued this very point in the past (after a discussion with Dmitry),
but wasn't very successful:

https://mail.mozilla.org/pipermail/es-discuss/2013-March/029004.html

I agree with you on this point, and still think that the current
iterator/iterable model is rather incoherent and the iterable concept
thus not really useful -- you cannot reliably write abstractions based
on it.


> Proposal:
>
>     - for...of always assume generator creation
>     - for...of alwayss terminates generator function
>
> Lost in cross talk...
>
> NM: If you know that iterable creates a fresh iterator, it's very reasonable
> to close it every time. If you don't know that, then Andy's argument holds.
>
> JH: The value proposition of for-of is that you don't need to work with
> iterators
>
> AWB: We _could_ add a `return()` method.
> ... It's a bigger change, but we could make for-of invoke `return()` on exit
> or completion

This would be a _significant_ cost. One reason we got rid of the
StopIteration protocol was the performance cost incurred by having to
wrap all loops into implicit try-statements, which are costly. This
proposal asks for re-introducing the same cost.

I'm strongly opposed, as it would likely put for-of at a measurable
performance disadvantage against for-in, which we'd like to deprecate.


> YK: doubt we can come to a conclusion on this
>
> AWB: We _must_ come to a tentative conclusion
>
> JH: Confirm, let's try.
>
> MM: Agree with Allen
>
>
> #### Plausible Solution:
>
> MM:
> - continue to have iterators have an @@iterator, classified as iterables
> - continue to have generators return an  iterator+
> - continue to for-of on an iterator
> - we change:
> - generator instances have a `return` that when invoked, caused the yield
> point to take the return path, returning the argument that was provided to
> the return method. [AWB: actually, needs to return a IteratorResult object:
> {done: true, value: returnMethodArgument} ]
> - the for-of behaviour is extended with an equivalent of a finally cause
> that feature tests for presence of return, if present, call it on any
> abnormal exit from the loop, normal or abnormal. [AWB:no change is necessary
> for normal loop complextion because the return from the generator body that
> sets the completion object to {done: true} will run any finally code in the
> generator body]

And given that everything in JavaScript is mutable under your feet,
when would the check for the presence of this method occur? As a
programmer, I'd expect it to happen at the exit point, but then you
can almost never optimise away the cost of the try-wrapper.

Similar issues apply to yield*, btw.

/Andreas