Erik Arvidsson wrote:
Two names seems like a bad compromise. We should either do
`next(...args)` or `resume(...args)`. Not both.
Right, and 'resume' makes no sense for iterators.
C'mon you two whose names start with A: this bikeshedding is wasteful
and disharmonious. We have much bigger fish
Two names seems like a bad compromise. We should either do `next(...args)`
or `resume(...args)`. Not both.
On Tue, May 14, 2013 at 11:12 AM, Andreas Rossberg wrote:
> On 14 May 2013 17:07, Allen Wirfs-Brock wrote:
> >
> > What about providing a convenience "resume" method on generators to help
On May 14, 2013, at 8:12 AM, Andreas Rossberg wrote:
> On 14 May 2013 17:07, Allen Wirfs-Brock wrote:
>>
>> What about providing a convenience "resume" method on generators to help
>> clarify co-routine style usage? Dave suggested that "resume" was
>> pedagogically useful.
>>
>> I would def
On 14 May 2013 17:07, Allen Wirfs-Brock wrote:
>
> What about providing a convenience "resume" method on generators to help
> clarify co-routine style usage? Dave suggested that "resume" was
> pedagogically useful.
>
> I would define it equivalently two:
>
>resume(...args) {return this.next
On May 13, 2013, at 9:44 PM, Brendan Eich wrote:
> David Herman wrote:
>> On May 13, 2013, at 6:11 PM, Brendan Eich wrote:
>>
>>> Merge next and send by letting next take an optional parameter? Ok by me.
>>
>> +1
>
> I pointed out to Dave that Python has arity checking and did next before
>
On May 13, 2013, at 4:15 PM, David Herman wrote:
> On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock wrote:
>
>> It closes down this whole edge-case focused discussion and that's valuable
>> in itself. Also, since it turns try {yield expr} finally{} into a syntax
>> error we could revisit the
David Herman wrote:
On May 13, 2013, at 6:11 PM, Brendan Eich wrote:
Merge next and send by letting next take an optional parameter? Ok by me.
+1
I pointed out to Dave that Python has arity checking and did next before
adding send in 2.5 for "coroutines", whereas JS has optional params
w
On May 13, 2013, at 6:11 PM, Brendan Eich wrote:
> We've been over this at least twice. Let's get it right. No close, yield in
> try-with-finally ok.
+1
> Merge next and send by letting next take an optional parameter? Ok by me.
+1
> Make yield* work on any {next, throw}, not necessary but o
Allen Wirfs-Brock wrote:
On May 13, 2013, at 4:22 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
In my response to Andy I concluded that syntactically restricting yield to not
be finally protected is the better solution.
It's a shame we have to around the block again. This was discussed ov
On May 13, 2013, at 4:22 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> In my response to Andy I concluded that syntactically restricting yield to
>> not be finally protected is the better solution.
>
> It's a shame we have to around the block again. This was discussed over six
> years
I'm also reluctant to ban yield + finally.
yield* should work with any iterable. It is conceptually the same as using
a for-of. If we can afford the call to get the iterator in for-of we can
surely afford it in yeild*.
+1 to merge next and send. I don't care about the name.
+1 to getting rid of
Allen Wirfs-Brock wrote:
In my response to Andy I concluded that syntactically restricting yield to not
be finally protected is the better solution.
It's a shame we have to around the block again. This was discussed over
six years ago, when we were prototyping for ES4 and studying Python 2.5.
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock wrote:
> It closes down this whole edge-case focused discussion and that's valuable in
> itself. Also, since it turns try {yield expr} finally{} into a syntax error
> we could revisit the decision in a future edition if somebody actually comes
On May 13, 2013, at 10:51 AM, Andy Wingo wrote:
>> If I'm implementing an iterator via a generator and I have to perform
>> a inner-iteration over an contained iterable (for example, some sort
>> of flattening operation) the way I code that inner iteration shouldn't
>> depend upon whether or not
Andy Wingo wrote:
But that's precisely what we can't guarantee: unlike function
activations, the dynamic extent of a generator activation is unlimited.
We don't have finalizers, so we can't ensure that a finally block runs.
Otherwise browsers would be even more trivially DoS-attacked.
We went
On May 13, 2013, at 11:08 AM, Andreas Rossberg wrote:
> On 13 May 2013 19:24, Allen Wirfs-Brock wrote:
>> On May 13, 2013, at 2:07 AM, Andreas Rossberg wrote:
>> [...]
>> Yes, it's a very good idea. The easy way for an imperative programmer
>> (there are a few of us in the world) to understand
On Mon, May 13, 2013 at 11:08 AM, Andreas Rossberg wrote:
> The case I was talking about is simply this:
>
> function* g() {
> yield* [1, 2]
> }
>
> var o = g()
> o.send(undefined)
> o.send(5) // what does this mean?
>
> But I suppose the answer is that the sent value is just droppe
On May 13, 2013, at 10:51 AM, Andy Wingo wrote:
> On Mon 13 May 2013 19:24, Allen Wirfs-Brock writes:
>
>> [yield* is] just a yielding loop over an iterator that for some reason
>> was arbitrarily being restricted to being a generator.
>
> I don't think the restriction you mention was present
On 13 May 2013 19:24, Allen Wirfs-Brock wrote:
> On May 13, 2013, at 2:07 AM, Andreas Rossberg wrote:
>> On 12 May 2013 21:29, Allen Wirfs-Brock wrote:
>>> As now specified:
>>>
>>> 1) I specified yield* such that it will work with any iterator, not just
>>> generators. To me, this seems essenti
On May 13, 2013, at 10:42 AM, Andreas Rossberg wrote:
> On 13 May 2013 17:58, Allen Wirfs-Brock wrote:
>> Every other place in the language (syntax and built-in functions) where we
>> expect Iterables we transparently accept either iterator or generator
>> objects. Why should yield* be any di
On Mon 13 May 2013 19:24, Allen Wirfs-Brock writes:
> [yield* is] just a yielding loop over an iterator that for some reason
> was arbitrarily being restricted to being a generator.
I don't think the restriction you mention was present in the harmony
document, was it?
For what it's worth:
> If
On 13 May 2013 17:58, Allen Wirfs-Brock wrote:
> Every other place in the language (syntax and built-in functions) where we
> expect Iterables we transparently accept either iterator or generator
> objects. Why should yield* be any different.
Generators are subtypes of iterators, but not the o
On May 13, 2013, at 2:07 AM, Andreas Rossberg wrote:
> On 12 May 2013 21:29, Allen Wirfs-Brock wrote:
>> First, as a general comment, I don't use direct desugaring within the spec.
>> but instead use the spec. pseudo code formalisms. This gives me direct
>> access to mechanisms such as intern
On May 13, 2013, at 1:22 AM, Andy Wingo wrote:
> Hi,
>
> On Sun 12 May 2013 21:29, Allen Wirfs-Brock writes:
>
>> 1) I specified yield* such that it will work with any iterator, not
>> just generators. To me, this seems essential. Otherwise client code
>> is sensitive to other peoples implem
On 12 May 2013 21:29, Allen Wirfs-Brock wrote:
> First, as a general comment, I don't use direct desugaring within the spec.
> but instead use the spec. pseudo code formalisms. This gives me direct
> access to mechanisms such as internal Completion values and allows me to
> express behaviors t
Hi,
On Sun 12 May 2013 21:29, Allen Wirfs-Brock writes:
> 1) I specified yield* such that it will work with any iterator, not
> just generators. To me, this seems essential. Otherwise client code
> is sensitive to other peoples implementation decision (that are
> subject to change) regarding w
I literally just finished making the changes to the ES6 specification draft to
fully incorporate generator semantics. I'll will be making that draft available
within the next day or two after worked down the bug backlog a bit.
Because this thread started while I was in the middle of that work, I
Greets,
Thanks for the kind words! And thanks also for the new iteration
proposal; it looks great to my ignorant eyes. I'll probably take a look
at for-of next.
On Thu 02 May 2013 20:07, David Herman writes:
>> IMHO yield* should be specified to return the result object as-is,
>> without re-b
Andy Wingo wrote:
On Wed 01 May 2013 01:55, David Herman writes:
On Apr 30, 2013, at 7:25 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
And as Andy points out correctly, that raises the question whether
having 'close' makes much sense at all.
I think we have evolved away from it. Cc'ing
Brendan reminded me I never replied to the earlier part of this thread.
On Apr 29, 2013, at 8:37 AM, Andy Wingo wrote:
> For what it's worth (which is very little) this seems like a decent
> plan to me.
Actually it's worth a lot to me! Your blog post on StopIteration was part of
what got me th
On May 2, 2013, at 9:51 AM, David Herman wrote:
> On May 2, 2013, at 6:25 AM, Andreas Rossberg wrote:
>
>> On 1 May 2013 02:06, David Herman wrote:
>>> It also has a smell to it: the idea that an expression can cause a return,
>>> without the syntactic appearance of `return`. (I'm not opposed
On May 2, 2013, at 6:25 AM, Andreas Rossberg wrote:
> On 1 May 2013 02:06, David Herman wrote:
>> It also has a smell to it: the idea that an expression can cause a return,
>> without the syntactic appearance of `return`. (I'm not opposed to the idea
>> of being able to return from expressions
On 1 May 2013 02:06, David Herman wrote:
> It also has a smell to it: the idea that an expression can cause a return,
> without the syntactic appearance of `return`. (I'm not opposed to the idea of
> being able to return from expressions -- I still love do-expressions. But I
> prefer `return` t
On Wed 01 May 2013 01:55, David Herman writes:
> On Apr 30, 2013, at 7:25 AM, Brendan Eich wrote:
>
>> Andreas Rossberg wrote:
>>> And as Andy points out correctly, that raises the question whether
>>> having 'close' makes much sense at all.
>>
>> I think we have evolved away from it. Cc'ing Da
On Apr 30, 2013, at 4:55 PM, David Herman wrote:
> On Apr 30, 2013, at 7:25 AM, Brendan Eich wrote:
>
>> Andreas Rossberg wrote:
>>> And as Andy points out correctly, that raises the question whether
>>> having 'close' makes much sense at all.
>>
>> I think we have evolved away from it. Cc'ing
On Apr 30, 2013, at 7:25 AM, Brendan Eich wrote:
> Andreas Rossberg wrote:
>> And as Andy points out correctly, that raises the question whether
>> having 'close' makes much sense at all.
>
> I think we have evolved away from it. Cc'ing Dave to confirm.
I'm cool with it, and I agree on type gro
Andreas Rossberg wrote:
And as Andy points out correctly, that raises the question whether
having 'close' makes much sense at all.
I think we have evolved away from it. Cc'ing Dave to confirm.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
ht
Andy Wingo wrote:
Hi Brendan,
On Tue 30 Apr 2013 09:47, Brendan Eich writes:
js> o.close()
typein:5:0 TypeError: yield from closing generator function foo() {
typein:5:0 try {
typein:5:0 yield 1;
typein:5:0 } finally {
typein:5:0 yield 2;
typein:5:0 }
typein:5:0 }
For the rec
Hi!
I agree with you except with one nit :)
On Tue 30 Apr 2013 14:19, Andreas Rossberg writes:
> The moral is that one should simply avoid putting a yield inside a
> try-finally. There is no guarantee that control ever returns.
It seems that yield in a try/finally can be useful in a more contr
On 30 April 2013 14:19, Andreas Rossberg wrote:
> On 30 April 2013 13:30, Andy Wingo wrote:
>> Hi Kevin,
>>
>> On Tue 30 Apr 2013 11:05, Kevin Gadd writes:
>>
>>> 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 30 April 2013 13:30, Andy Wingo wrote:
> Hi Kevin,
>
> On Tue 30 Apr 2013 11:05, Kevin Gadd writes:
>
>> 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?
>
> Certainly they run in this situation:
>
> function *
Hi Kevin,
On Tue 30 Apr 2013 11:05, Kevin Gadd writes:
> 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?
Certainly they run in this situation:
function *g1() { try { yield 1; } finally { qux(); } }
for (x of
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
On Tue 30 Apr 2013 10:23, Kevin Gadd 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
Is the reason why you wouldn't want to run finally blocks in generators
described elsewhere on the list? Choosing not to run a generator's finally
block is, to me at least, a very significant behavioral compromise,
especially for use cases where generators are used to approximate
coroutines (think
Hi Brendan,
On Tue 30 Apr 2013 09:47, Brendan Eich writes:
> js> o.close()
> typein:5:0 TypeError: yield from closing generator function foo() {
> typein:5:0 try {
> typein:5:0 yield 1;
> typein:5:0 } finally {
> typein:5:0 yield 2;
> typein:5:0 }
> typein:5:0 }
For the record, th
Andy Wingo wrote:
Hi Brendan,
On Mon 29 Apr 2013 21:33, Brendan Eich writes:
Andy Wingo wrote:
close() does not seem to have much value given that it isn't part of the
iterators specification, and one can do any needed action by doing a
throw() on the iterator and relying on the generator to
Hi Brendan,
On Mon 29 Apr 2013 21:33, Brendan Eich writes:
> Andy Wingo wrote:
>> close() does not seem to have much value given that it isn't part of the
>> iterators specification, and one can do any needed action by doing a
>> throw() on the iterator and relying on the generator to have a fin
Andy Wingo wrote:
close() does not seem to have much value given that it isn't part of the
iterators specification, and one can do any needed action by doing a
throw() on the iterator and relying on the generator to have a finally
block if needed.
But throwing has other unwanted effects, in gen
> -Original Message-
> From: Andy Wingo [mailto:wi...@igalia.com]
> Sent: Monday, April 29, 2013 11:56 AM
> To: Ron Buckton
> Cc: Brendan Eich; es-discuss
> Subject: Re: yield* desugaring
>
> On Mon 29 Apr 2013 19:25, Ron Buckton writes:
>
> > The des
On Mon 29 Apr 2013 19:25, Ron Buckton writes:
> The desugaring for yield* in the face of using { value?, done? } is more
> likely (without refutable matching or let expressions for the moment):
>
> ```js
> let a;
> {
> [...]
> a = result;
> }
> ```
Correct me if I am wrong, but I don't
) { }
}
a = result;
}
```
Ron
> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
> boun...@mozilla.org] On Behalf Of Brendan Eich
> Sent: Monday, April 29, 2013 9:48 AM
> To: Andy Wingo
> Cc: es-discuss
> Subject: Re: yield* desugaring
&
Just a straw-spec device, not proposed for ES6 or 7.
/be
Andy Wingo wrote:
Hi again,
On Mon 29 Apr 2013 17:37, Andy Wingo writes:
let (g = EXPR) {
let received = void 0, send = true;
while (true) {
let next = send ? g.send(received) : g.throw(received);
if (next.d
Hi again,
On Mon 29 Apr 2013 17:37, Andy Wingo writes:
> let (g = EXPR) {
> let received = void 0, send = true;
> while (true) {
> let next = send ? g.send(received) : g.throw(received);
> if (next.done)
> break;
> try {
> received = yield next.value;
Hello,
I understand that the consensus among those present at the last TC39
meeting was that iterators should box their return values in objects of
the form
{ value: VALUE, done: DONE }
where DONE is true or false. Notes here:
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/m
55 matches
Mail list logo
