On May 13, 2013, at 9:44 PM, Brendan Eich wrote:
David Herman wrote:
On May 13, 2013, at 6:11 PM, Brendan Eichbren...@mozilla.com 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
On 14 May 2013 17:07, Allen Wirfs-Brock al...@wirfs-brock.com 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
On May 14, 2013, at 8:12 AM, Andreas Rossberg wrote:
On 14 May 2013 17:07, Allen Wirfs-Brock al...@wirfs-brock.com 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
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 rossb...@google.comwrote:
On 14 May 2013 17:07, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
What about providing a convenience
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
Hi,
On Sun 12 May 2013 21:29, Allen Wirfs-Brock al...@wirfs-brock.com 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
On 12 May 2013 21:29, Allen Wirfs-Brock al...@wirfs-brock.com 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
On May 13, 2013, at 1:22 AM, Andy Wingo wrote:
Hi,
On Sun 12 May 2013 21:29, Allen Wirfs-Brock al...@wirfs-brock.com 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
On May 13, 2013, at 2:07 AM, Andreas Rossberg wrote:
On 12 May 2013 21:29, Allen Wirfs-Brock al...@wirfs-brock.com 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
On 13 May 2013 17:58, Allen Wirfs-Brock al...@wirfs-brock.com 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
On Mon 13 May 2013 19:24, Allen Wirfs-Brock al...@wirfs-brock.com 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
On May 13, 2013, at 10:42 AM, Andreas Rossberg wrote:
On 13 May 2013 17:58, Allen Wirfs-Brock al...@wirfs-brock.com 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
On 13 May 2013 19:24, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 13, 2013, at 2:07 AM, Andreas Rossberg wrote:
On 12 May 2013 21:29, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
As now specified:
1) I specified yield* such that it will work with any iterator, not just
On May 13, 2013, at 10:51 AM, Andy Wingo wrote:
On Mon 13 May 2013 19:24, Allen Wirfs-Brock al...@wirfs-brock.com 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
On Mon, May 13, 2013 at 11:08 AM, Andreas Rossberg rossb...@google.com 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
On May 13, 2013, at 11:08 AM, Andreas Rossberg wrote:
On 13 May 2013 19:24, Allen Wirfs-Brock al...@wirfs-brock.com 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)
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 10:51 AM, Andy Wingo wi...@igalia.com 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
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock al...@wirfs-brock.com 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
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
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
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 ago,
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
On May 13, 2013, at 6:11 PM, Brendan Eich bren...@mozilla.com 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
David Herman wrote:
On May 13, 2013, at 6:11 PM, Brendan Eichbren...@mozilla.com 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
On May 13, 2013, at 4:15 PM, David Herman dher...@mozilla.com wrote:
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock al...@wirfs-brock.com 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
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,
On Wed 01 May 2013 01:55, David Herman dher...@mozilla.com writes:
On Apr 30, 2013, at 7:25 AM, Brendan Eich bren...@mozilla.com 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
On 1 May 2013 02:06, David Herman dher...@mozilla.com 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
On May 2, 2013, at 6:25 AM, Andreas Rossberg rossb...@google.com wrote:
On 1 May 2013 02:06, David Herman dher...@mozilla.com 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
On May 2, 2013, at 9:51 AM, David Herman dher...@mozilla.com wrote:
On May 2, 2013, at 6:25 AM, Andreas Rossberg rossb...@google.com wrote:
On 1 May 2013 02:06, David Herman dher...@mozilla.com wrote:
It also has a smell to it: the idea that an expression can cause a return,
without the
Brendan reminded me I never replied to the earlier part of this thread.
On Apr 29, 2013, at 8:37 AM, Andy Wingo wi...@igalia.com 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
Andy Wingo wrote:
On Wed 01 May 2013 01:55, David Hermandher...@mozilla.com writes:
On Apr 30, 2013, at 7:25 AM, Brendan Eichbren...@mozilla.com wrote:
Andreas Rossberg wrote:
And as Andy points out correctly, that raises the question whether
having 'close' makes much sense at all.
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 dher...@mozilla.com writes:
IMHO yield* should be specified to return the result object
Hi Brendan,
On Mon 29 Apr 2013 21:33, Brendan Eich bren...@mozilla.com 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
Andy Wingo wrote:
Hi Brendan,
On Mon 29 Apr 2013 21:33, Brendan Eichbren...@mozilla.com 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
Hi Brendan,
On Tue 30 Apr 2013 09:47, Brendan Eich bren...@mozilla.com 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
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
On Tue 30 Apr 2013 10:23, Kevin Gadd kevin.g...@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
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
Hi Kevin,
On Tue 30 Apr 2013 11:05, Kevin Gadd kevin.g...@gmail.com 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 {
On 30 April 2013 14:19, Andreas Rossberg rossb...@google.com wrote:
On 30 April 2013 13:30, Andy Wingo wi...@igalia.com wrote:
Hi Kevin,
On Tue 30 Apr 2013 11:05, Kevin Gadd kevin.g...@gmail.com writes:
I would definitely expect a given finally block to run if i use for-of
or similar on the
Hi!
I agree with you except with one nit :)
On Tue 30 Apr 2013 14:19, Andreas Rossberg rossb...@google.com 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
Andy Wingo wrote:
Hi Brendan,
On Tue 30 Apr 2013 09:47, Brendan Eichbren...@mozilla.com 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 }
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
On Apr 30, 2013, at 4:55 PM, David Herman dher...@mozilla.com wrote:
On Apr 30, 2013, at 7:25 AM, Brendan Eich bren...@mozilla.com 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
Hi again,
On Mon 29 Apr 2013 17:37, Andy Wingo wi...@igalia.com 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
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 Wingowi...@igalia.com writes:
let (g = EXPR) {
let received = void 0, send = true;
while (true) {
let next = send ? g.send(received) : g.throw(received);
) { }
}
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
On Mon 29 Apr 2013 19:25, Ron Buckton rbuck...@chronicles.org 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
-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 rbuck...@chronicles.org writes:
The desugaring for yield
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
52 matches
Mail list logo
