April 10 2014 Meeting Notes

[Allen Wirfs-Brock]

On Apr 15, 2014, at 8:24 AM, Andreas Rossberg wrote:
> 
>> 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.

Essentially it means that all generator based loops need to be wrapped in a finally. Whether or not this has a significant cost or is a equivalent to an exception handler depends upon implementation specific details of the runtime design.

Note that only for-loops that that are using a generator (or more generally) expose @@return need the implicit finally.  This certainly seems like a case that an optimizing JIT could dynamically specialize.

> 
> 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.

It can be specified so that the @@return method is captured in the loop head.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140415/ef2540c7/attachment-0001.html>