April 10 2014 Meeting Notes

[Mark S. Miller]

On Fri, Apr 25, 2014 at 8:48 AM, Rick Waldron <waldron.rick at gmail.com>wrote:

> On Fri, Apr 25, 2014 at 11:16 AM, Mark S. Miller <erights at google.com>wrote:
>
>> Hi Domenic, that's a long thread. Could you summarize, or point at a very
>> small number of messages on that thread that get the point across? Thanks.
>>
>
> Mark,
>
> This is the specific post we discussed at the last meeting:
> http://esdiscuss.org/topic/yield-desugaring#content-29
>
> (It may not be the one Domenic is referring to, but it's relevant to this
> discussion)
>

Ok, the point of that post still seems well summarized by the example at
the end

for_each_n(x => console.log(x), iter, 10);  // first 10
> for_each_n(x => console.log(x), iter, 10);  // next 10
>

And the points


> In summary my problems with close() are these:
> 1. It attempts to provide a reliable finally for unlimited-extent
> activations, when we can't do that.
> 2. It complicates the mental model of what happens when you yield.
> 3. It makes common sugar like for-of inappropriate for some uses of
> generator objects.


IIRC, on wednesday at tc39, when Brendan presented this, I found it
compelling. On thurs (when Brendan was absent) when this came up again, I
flipped because of the following argument:

Given that for/of comes to be understood to use up its iterable's iterator,
when the iterable is the iterator and you desire not to use it up, don't
use for/of. Use for(;;) instead, which is easy enough and makes it more
explicit what you are and are not doing in the iteration.

Regarding the points:

#1 yes, we cannot provide one that's reliable, so let's not claim that it
is reliable.
#2 yes it does. I acknowledge that this is a genuine cost.
#3 for those rare cases where it is inappropriate, like this example,
better not to use a for/of anyway to make the unusualness of this code's
purpose more explicit.


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140426/9c12f27e/attachment.html>