I'm not pointing out an issue in particular, just explaining why Andy
is right with his specific statement about implementations not using
generators (which Dave seemed surprised about, or have misread, I'm
not sure).
(You are right to assume that built-in iterators would not need .return.)
/Andr
I'm not concerned about manually added .return methods, nor manual calls to
.return methods, though perhaps I should be. If this is a concern, we could
solve it by using an @return symbol in ES7 rather than a string name.
Neither am I concerned about system iterators, assuming that none of the
syst
On Tue, Apr 29, 2014 at 7:47 PM, David Herman wrote:
> Promised you a reply to this one, sorry -- I'm not comfortable with this
> restriction. It violates my Schemer's intuition [1]. In particular it
> creates a number of refactoring hazards: (1) add some try/finally
>
[...]
> [1] "Programming l
Domenic: the argument against is that changing the semantics of `for of` --
and all of the standard library methods, in the case of exceptional exit --
would result in a user-visible change to the state of the iterator. That
is, the iterator would not be closed, whereas ES6 as it stands now would
Can someone summarize the argument as to why this can't be added later? Is the
fear that people will create iterators with `return` methods and depend on
those methods *not* being called, but then ES7 would start calling them?
___
es-discuss mailing li
On Tue, Apr 29, 2014 at 4:32 AM, Kevin Smith wrote:
> I agree with pretty much everything Andy had to say, and would like to add
> a meta-perspective:
>
> We should be viewing this as a last-minute feature request. The churn
> that this request has introduced is (in my opinion) exactly the kind
I don't think I understand the issue. AFAICT, all the system implemented
iterators don't need to clean up anything that's not already cleaned up by
GC, so they wouldn't need a .return method anyway. Is there a
counter-example?
On Wed, Apr 30, 2014 at 3:48 AM, Andreas Rossberg wrote:
> On 29 Apri
On 29 April 2014 20:35, David Herman wrote:
> On Apr 29, 2014, at 12:40 AM, Andy Wingo wrote:
>> Indeed I expect that in
>> practice most iterators in an ES6 program will be map, set, and array
>> iterators, which in practice will not be implemented with generators.
>
> I strongly disagree with t
Minor correction to Domenic's comments in this (interesting)
discussion; IEnumerable and IDisposable are separate concepts in C#.
Neither IEnumerable or IEnumerator are disposable objects in C#;
*however*, if you use 'for each' on an object that yields an
enumerator that is *also* disposable, the c
On Apr 25, 2014, at 9:10 AM, Allen Wirfs-Brock wrote:
> People will write code like this if we allow it. But we don't have to allow.
> We can preserve the semantics of try-finally by simply making the occurrence
> of the 'yield' operator syntactically illegal within the try block of a
> try-
On Tue, Apr 29, 2014 at 4:07 PM, Jason Orendorff
wrote:
> On Tue, Apr 29, 2014 at 2:40 AM, Andy Wingo wrote:
> > == Calling return() on early exit from for-of is expensive
> >
> > Wrapping a try/finally around each for-of is going to be really
> > expensive in all engines right now. I'm skeptica
On Apr 29, 2014, at 12:17 PM, Domenic Denicola
wrote:
> Anyway, regardless of the specifics of my `using` proposal, I hope that
> highlighting the iterability vs. disposability aspects of this conversation
> was helpful to people.
I do think it's helpful for understanding the space, thanks.
On Tue, Apr 29, 2014 at 2:40 AM, Andy Wingo wrote:
> == Calling return() on early exit from for-of is expensive
>
> Wrapping a try/finally around each for-of is going to be really
> expensive in all engines right now. I'm skeptical about our ability to
> optimize this one away. Avoiding try/catc
Brendan Eich wrote:
Indeed with rapid release, penalizing convenience and waiting for
ecosystem effects can make overcomplicated, convenient
"inconvenient"
, and just bad total designs out of piecewise steps that you might
like because they avoid committing to convenience :-P.
/be
Domenic Denicola wrote:
Dave and Andy's responses have me pinging back and forth as to which "side" I'm
on.
Are you off the fence yet? I can't tell :-P.
But inconvenience is easily solved via MOAR SUGAR:
```js
for (var line using files) {
if (line == '-- mark --') {
break;
}
}
``
Dave and Andy's responses have me pinging back and forth as to which "side" I'm
on. Both seem convincing. Dave's response especially brought the issue into
focus for me in a way that I think is clear, so let me explain what I learned
from it:
What we are essentially talking about here are two t
I'm sympathetic to the "simplicity" argument that says that `.throw` is the
proper way in JS to clean up an iterator. The `.return` proposal seems
like a kludge to work around the fact that ES6 still doesn't have a
discriminatory `catch` clause that can avoid catching the thrown cleanup
exception.
On Apr 29, 2014, at 12:40 AM, Andy Wingo wrote:
> I'm a bit grumpy that this is being brought up again, and
> this late, and in multiple forums, but as it seems that people want to
> talk about it again, that talking about it again is the thing to do...
Sorry about that. :( But the fact is Jafar
I agree with pretty much everything Andy had to say, and would like to add
a meta-perspective:
We should be viewing this as a last-minute feature request. The churn that
this request has introduced is (in my opinion) exactly the kind of problem
that the ES7 process is meant to address. In fact,
On Fri 25 Apr 2014 16:22, Domenic Denicola writes:
>> (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 w
On Fri 25 Apr 2014 17:14, Filip Pizlo writes:
> It's just a matter of common sense that JS implementations move to
> totally-free entry/exit into try-catch and a sensible cost model for
> when you throw, regardless of how this proposal goes. The fact that
> either of these things is a performance
Certainly we could make `.return` always return `undefined` with no loss of
functionality, since the intended use case is simply to trigger `finally`
clauses and close the generator.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://m
Mark S. Miller wrote:
BTW, return() should be idempotent. Is it?
Since .return takes an argument whose value is observable, I think not.
Hmmm. This is interestingly similar to multiple calls to resolve.
Yes, and note that Python's generator.close (no return value parameter,
recall it
On Sat, Apr 26, 2014 at 2:52 PM, Brendan Eich wrote:
> Mark S. Miller wrote:
>
>> Regarding the points:
>>
>> #1 yes, we cannot provide one that's reliable, so let's not claim that it
>> is reliable.
>>
>
> Indeed it is not safe, even excluding yield, to assume finallys run in
> browser contexts,
Mark S. Miller wrote:
Regarding the points:
#1 yes, we cannot provide one that's reliable, so let's not claim that
it is reliable.
Indeed it is not safe, even excluding yield, to assume finallys run in
browser contexts, unless you can prove termination of trys (which is
hard, right? Halting
On Fri, Apr 25, 2014 at 8:48 AM, Rick Waldron wrote:
> On Fri, Apr 25, 2014 at 11:16 AM, Mark S. Miller 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 s
+1 from me as well. None of the proposed quick workarounds are truly safe,
we might as well fix it properly.
--scott
ps. it seems like modules are still the long pole in the tent, so there's a
little bit of time to spend on this?
___
es-discuss mailin
+1, especially on the last point. As something added to iterators rather
than iterables in ES6, there's no reason for "return" to be a symbol rather
than a string.
On Sat, Apr 26, 2014 at 9:59 AM, Brendan Eich wrote:
> Kevin Smith wrote:
>
>>
>>
>> In this case we have try-finally statement
Kevin Smith wrote:
In this case we have try-finally statements as an existing
feature. The semantics of this feature is a bounded execution
scope with a cleanup action on completion. This feature is widely
used and has always been internally consistent and reliable,
expect
>
> In this case we have try-finally statements as an existing feature. The
> semantics of this feature is a bounded execution scope with a cleanup
> action on completion. This feature is widely used and has always been
> internally consistent and reliable, expect for catastrophic external
> failu
On Fri, Apr 25, 2014 at 4:15 PM, C. Scott Ananian wrote:
> Ah. I'm still looking for a "minimal safe cut" for ES6 -- would it be
> possible to remove `@@iterator` from iterators created from generators?
>
Nevermind, I realize this doesn't prevent you from storing away the
iterator and creating y
Ah. I'm still looking for a "minimal safe cut" for ES6 -- would it be
possible to remove `@@iterator` from iterators created from generators?
(Now I see that this conversation has turned on itself, since it began
with a discussion about whether iterators should be iterable, etc.)
Again, I would
y. Iterators are themselves iterable, so you can for/of an interator (which
happens to be a generator), exit the for/of loop early, and currently
resume the iterator. Were we to adopt the proposal, when the iterator is a
generator, it would not be resumable.
On Fri, Apr 25, 2014 at 12:46 PM, C. S
On Fri, Apr 25, 2014 at 3:12 PM, Mark S. Miller wrote:
> I would really like to believe that this is adequate to postpone the rest
> of this issue to ES7. But even without finally, this proposal would put the
> generator in a non-resumable state in ES7 after ES6 would ship them in a
> resumable s
I would really like to believe that this is adequate to postpone the rest
of this issue to ES7. But even without finally, this proposal would put the
generator in a non-resumable state in ES7 after ES6 would ship them in a
resumable state. I don't think that's realistic.
On Fri, Apr 25, 2014 at 1
I like the `@@return` proposal, and I would like to eventually use `yield`
inside try/finally (with something like `Promise.async` to implement the
poor man's pre-ES7 `await`/`async`), and *yet*:
I support banning `yield` inside try/finally for ES6. That seems the
smallest possible fix for the im
On Apr 25, 2014, at 9:44 AM, Rick Waldron wrote:
>
>
>
> On Fri, Apr 25, 2014 at 12:10 PM, Allen Wirfs-Brock
> wrote:
>
> The solution "Outlawing 'yield' in a try-finally", is that _only_ for
> try-finally? What about:
>
> function * g() {
> try {
> yield iWillCauseAReference
On Fri, Apr 25, 2014 at 12:10 PM, Allen Wirfs-Brock
wrote:
>
> On Apr 25, 2014, at 4:53 AM, Kevin Smith wrote:
>
> > It seems to me that generators are not the best mechanism to express
> resource management ("abstract over expensive resources") because the
> programmer of the generator can never
On Apr 25, 2014, at 4:53 AM, Kevin Smith wrote:
> It seems to me that generators are not the best mechanism to express resource
> management ("abstract over expensive resources") because the programmer of
> the generator can never guarantee that the consumer will exhaust it. If we
> want dire
On Fri, Apr 25, 2014 at 11:16 AM, Mark S. Miller 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.o
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.
On Fri, Apr 25, 2014 at 7:22 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> > (2) not well-motivated according to some participants o
>> On Apr 25, 2014, at 7:07 AM, Andreas Rossberg wrote:
>>
>>> On 25 April 2014 00:16, Allen Wirfs-Brock 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 ov
> (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).
This to me is the most worrying point. I feel
On 25 April 2014 00:16, Allen Wirfs-Brock 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 thro
> If we want direct language support for resource management, then a proposal
> should be crafted to add that as a distinct feature.
+1, sort of. But…
Note that in C#, which has had `IDisposable`/`using` since 1.0 IIRC, all
enumerables (i.e. `for`-`each`ables) are `IDisposable`, and their `for
It seems to me that generators are not the best mechanism to express
resource management ("abstract over expensive resources") because the
programmer of the generator can never guarantee that the consumer will
exhaust it. If we want direct language support for resource management,
then a proposal
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 presumab
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 presumab
Excellent. Given that, how realistic is the performance concern for the
non-exceptional situation? Where is the overhead?
On Thu, Apr 24, 2014 at 2:06 PM, Allen Wirfs-Brock wrote:
>
> On Apr 24, 2014, at 12:38 PM, Mark S. Miller wrote:
>
> > I agree that this issue should treat for/of and [...x]
On Apr 24, 2014, at 1:29 PM, Brendan Eich wrote:
> Sorry for the confusion -- my "such a change" was about changing @@iterator
> itself, e.g. not defining it on a generator, or trying somehow to guarantee
> freshness.
>
> I agree, return automation makes sense for any delimited form that impli
On Apr 24, 2014, at 12:38 PM, Mark S. Miller wrote:
> I agree that this issue should treat for/of and [...x], etc, similarly.
> Either do both or neither.
>
> Does it alleviate the performance concerns if the .return is only invoked on
> early exit, i.e., before the iterator reports that it is
On Thu, Apr 24, 2014 at 12:57 PM, Allen Wirfs-Brock
wrote:
[...]
> Really, the only reason we even considered this at the TC39 meeting was
> because we believed it was a fix it now, or never situation. I'm now less
> convinced that this is the situation. If we shipped ES6 as is and later
> added
Sorry for the confusion -- my "such a change" was about changing
@@iterator itself, e.g. not defining it on a generator, or trying
somehow to guarantee freshness.
I agree, return automation makes sense for any delimited form that
implicitly calls @@iterator.
There still may be an open issue,
On Thu, Apr 24, 2014 at 2:16 PM, Brendan Eich wrote:
> The only proposal (let's table whether the name is 'return' or @@return) is
> whether for-of constructs should have a finally maybe-call of the iterator's
> return method, if present. Like SpiderMonkey's JS1.7-1.8 close method, based
> in part
On Apr 24, 2014, at 12:16 PM, Brendan Eich wrote:
> Jason Orendorff wrote:
>> OnThu, Apr 24, 2014 at 1:38 PM, Allen Wirfs-Brock
>> wrote:
>>> > [...]What we did take seriously was the concern about not running
>>> > generator finally blocks when a for-of initiated generator has an early
>>
I agree that this issue should treat for/of and [...x], etc, similarly.
Either do both or neither.
Does it alleviate the performance concerns if the .return is only invoked
on early exit, i.e., before the iterator reports that it is done? For
builtins like [...x], and for javascript code that has
From: es-discuss on behalf of Brendan Eich
> No one is talking seriously about such a change.
Why not? It seems like you'd want to perform any return-related "cleanup" just
as clearly when you were doing `[...iterable]` or `Promise.all(iterable)`.
What makes `for`-`of` special?
Making the
Jason Orendorff wrote:
OnThu, Apr 24, 2014 at 1:38 PM, Allen Wirfs-Brock
wrote:
> [...]What we did take seriously was the concern about not running generator
finally blocks when a for-of initiated generator has an early exit. We don't need
to redefine @@iterator conventions to address tha
On Thu, Apr 24, 2014 at 1:38 PM, Allen Wirfs-Brock
wrote:
> [...]What we did take seriously was the concern about not running generator
> finally blocks when a for-of initiated generator has an early exit. We don't
> need to redefine @@iterator conventions to address that issue.
This reminds me
On Tue, Apr 15, 2014 at 10:24 AM, Andreas Rossberg 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 t
On Apr 24, 2014, at 11:08 AM, Jason Orendorff wrote:
> On Tue, Apr 15, 2014 at 10:24 AM, Andreas Rossberg
> wrote:
>>> JH: Iterators are claiming to Iterables, which is a lie.
>>
>> I argued this very point in the past (after a discussion with Dmitry),
>> but wasn't very successful:
>>
>> htt
On Tue, Apr 15, 2014 at 10:24 AM, Andreas Rossberg wrote:
>> JH: Iterators are claiming to Iterables, which is a lie.
>
> I argued this very point in the past (after a discussion with Dmitry),
> but wasn't very successful:
>
> https://mail.mozilla.org/pipermail/es-discuss/2013-March/029004.html
>
+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 wrote:
>
>
>> On Apr 24, 2014, at 7:49 AM, Erik Arvidsson wrote:
>>
>> I co
On Apr 24, 2014, at 10:24 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> 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.
>
> That's not the proposal, though, is it?
>
> Isn
Allen Wirfs-Brock wrote:
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.
That's not the proposal, though, is it?
Isn't the maybe-call of return for any iterator, whether a generator
it
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 s
I completely agree. Adding return() will make adoption suffer.
On Thursday, April 24, 2014 4:05:14 AM, Andreas Rossberg <
rossb...@google.com> wrote:
> On 15 April 2014 18:06, Allen Wirfs-Brock
> wrote:
> >>> AWB: We _could_ add a `return()` method.
> >>> ... It's a bigger change, but we could m
On 15 April 2014 18:06, Allen Wirfs-Brock 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
> -Original Message-
> From: Erik Arvidsson [mailto:erik.arvids...@gmail.com]
> Sent: Tuesday, April 15, 2014 8:38 AM
> To: waldron.r...@gmail.com; es-discuss@mozilla.org; Yehuda Katz
> Cc: Ron Buckton
> Subject: Decorators vs Annotations (was April 10 2014 Meeting Note
On Apr 15, 2014, at 8:24 AM, Andreas Rossberg wrote:
>
>> Proposal:
>>
>>- for...of always assume generator creation
>>- for...of alwayss terminates generator function
>>
>> Lost in cross talk...
>>
>> NM: If you know that iterable creates a fresh iterator, it's very reasonable
>> to c
On Tue Apr 15 2014 at 10:27:23 AM, Rick Waldron
wrote:
>
> ## Decorators for ES7
> (Yehuda Katz)
>
> Slides: (need slides)
>
> YK: Presenting aspects of common use cases not yet covered by ES6 `class`.
>
> Knockout.js example (compute the value of a property)
>
> WH: Do you want to use functors t
> ## Revisiting: Generator Issues
> (Jafar Husain)
>
> [...]
>
> JH: The crucial problem: the iterator claims to be an iterable and it's not.
> ...If async generators return Iterables, not Iterators.
>
> WH: How
>
> JH: If I accept an iterable and invoke `@@iterator`, I would expect to get a
> fres
72 matches
Mail list logo
