yield* desugaring

Kevin Gadd kevin.gadd at gmail.com
Tue Apr 30 02:05:09 PDT 2013


My apologies. I read your statement "Also it seems to me to be an
unnecessary restriction that originated in Python's desire to always run
the finally blocks -- not a goal of ES6" as if it were suggesting that ES6
had an existing design philosophy that meant finally blocks would not be
reliable in generators. It's fine if a generator's finally block doesn't
run if you never terminate the generator (whether through close or through
iter.throw or through calling iter.next until it completes).

However, I would definitely expect a given finally block to run if i use
for-of or similar on the generator. This is the intent, I hope?


On Tue, Apr 30, 2013 at 1:49 AM, Andy Wingo <wingo at igalia.com> wrote:

> On Tue 30 Apr 2013 10:23, Kevin Gadd <kevin.gadd at gmail.com> writes:
>
> > Is the reason why you wouldn't want to run finally blocks in generators
> > described elsewhere on the list?
>
> I am not sure I understand the question.  Certainly you want run finally
> blocks in response to normal control flow in a generator:
>
>   function* g() {
>     try {
>       yield 1;
>       try { yield 2; } catch (e) { yield e; }
>       yield 3;
>     } finally {
>       yield 4;
>     }
>     yield 5;
>   }
>   function Sentinel() {}
>   function Sentinel2() {}
>   var iter;
>
>   iter = g();
>   assertEquals(1, iter.next());
>   assertEquals(2, iter.next());
>   var exn = new Sentinel;
>   assertEquals(exn, iter.throw(exn));
>   assertEquals(3, iter.next());               // ***
>   assertEquals(4, iter.throw(new Sentinel2));
>   assertThrows(function() { iter.next(); }, Sentinel2);
>   assertThrows(function() { iter.next(); }, Error);
>
> However.  If I understand your question correctly, your question is, if
> we just stop after the line marked "***" above, does the "finally {yield
> 4}" block ever run?
>
> To run finally blocks when a generator object is suspended within the
> try{} of a try/finally block is to introduce finalizers into ECMAScript.
> So if this is really what you want, then your question is "why is it a
> bad idea to add finalizers to ECMAScript".  I think these slides from
> Hans Boehm fairly describe the situation:
>
>
> http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf
>
> Finalizers can be useful but they are not a great interface, they
> introduce concurrency, and they are otherwise not currently part of the
> language, and so for example V8's great GC hasn't had to deal with
> them, which is a win for web performance.  Better to avoid adding them
> to the language, especially in this oblique way.
>
> Andy
>



-- 
-kg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130430/cfaa5a87/attachment.html>


More information about the es-discuss mailing list