April 10 2014 Meeting Notes

[Filip Pizlo]

+1. 

This is neither the first nor the last time that implementations will have to do smart things to make a language performant. Let's get the semantics right. 

-Fil

> On Apr 24, 2014, at 9:50 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
> 
>> On Apr 24, 2014, at 7:49 AM, Erik Arvidsson wrote:
>> 
>> I completely agree. Adding return() will make adoption suffer.
> 
> I don't think that should be the high order-bit on this decision.
> 
> There are ways to implement finally unwinding that have zero to very low dynamic setup cost so there is only a significant cost when unwinding actually occurs. This would probably be a good thing for implementations to move towards.
> 
> If (and it's still an open question) it make sense semantically to call "return" on for-of initiated  generators on unwind, then that is what we should do. Implementations can catch up, but specified semantics is forever.
> 
> Allen
> 
> 
>> 
>>> On Thursday, April 24, 2014 4:05:14 AM, Andreas Rossberg <rossberg at google.com> wrote:
>>> On 15 April 2014 18:06, Allen Wirfs-Brock <allen.wirfsbrock at gmail.com> wrote:
>>> >>> 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.
>>> 
>>> I'm very doubtful, given how VMs currently handle these features. I'm
>>> pretty sure the consequence will be that the golden new future with
>>> for-of and generators will be significantly slower than manual for-in
>>> or for-;; loops for a long time, if not forever. And consequently,
>>> adoption would suffer.
>>> 
>>> And FWIW, it would have similar effects on yield* and generator
>>> expressions as well.
>>> 
>>> (We already see a similar effect with higher-order array functions: we
>>> get regular complaints that they are slower than for-loops, but there
>>> is only so much we can do given their more expensive spec'ed
>>> semantics.)
>>> 
>>> /Andreas
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140424/6fff57f9/attachment-0001.html>