April 10 2014 Meeting Notes
rossberg at google.com
Fri Apr 25 07:07:40 PDT 2014
On 25 April 2014 00:16, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> On Apr 24, 2014, at 2:33 PM, Mark S. Miller wrote:
>> Excellent. Given that, how realistic is the performance concern for the non-exceptional situation? Where is the overhead?
> the body of the for-of loop could directly or indirectly throw an exception or contain a break.The break can presumably be statically detected and cleanup handled by the break logic. But the loop still needs the equivalent of a finally around it, just in case an exception is thrown from the body. It's hander needs to invoke @@return on the generator.
> The point of debate is the cost of setting up that finally-equivalent, potentially for every for-of loop. The argument is that for some/most(??) current implementations there is significant runtime overhead to this setup.
The broader argument is that this cost is imposed on the common use
case and has to be weighed against the utility it adds for a case that
is (1) rare, and (2) not well-motivated according to some participants
of the discussion (e.g., it's not necessarily a good idea to rely on
finally-blocks for scarce resource management in the first place,
since they provide only weak guarantees either way).
> The contra argument is that there are technique that have zero to very low setup costs and that implementations may need to evolve to use them.
To be sure, AFAICT none of these techniques have been demonstrated in
a JS-like language. Even in C++ land they have been a pipe dream for a
More information about the es-discuss