+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 <[email protected]> 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 >>> <[email protected]> wrote: >>> On 15 April 2014 18:06, Allen Wirfs-Brock <[email protected]> >>> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
