Allen Wirfs-Brock
January 17, 2012
7:56 PM
On
Jan 17, 2012, at 10:14 AM, Grant Husbands wrote:Allen
Wirfs-Brock wrote:do: arr.alternate ({|o| if
(...) continue; if (...) break; ...}, {|o| if(...) continue; ...});I don't see how
this can support the most likely intended
Brendan Eich wrote:
Herby Vojčík mailto:he...@mailbox.sk
January 18, 2012 2:34 AM
Brendan Eich wrote:
Perhaps what I'm saying is that I think do: is a label for the
whole
callexpression, covering all lambda-block parameters. As far as the
specification goes, a continue that 'hits' the block
Grant Husbands
January 16, 2012
5:33 PM
Brendan Eich wrote:
2. Variation on empty label: support "do" as a reserved-identifier label
do: arr.forEach {|o|
if (...) break;
...
}
This seems like a sound way of doing it, indeed (I omitted your first
one because I prefer
To complete the Smalltalk homage we would want this [the label do:] in
expressions, and we'd also want do: to take a block-lambda directly, in
addition to a CallWithBlockArguments.
Minor possibility of future-hostility: Should real keyword arguments ever make
it to ECMAScript, labels such
Allen Wirfs-Brock wrote:
do: arr.alternate ({|o| if (...) continue; if (...) break; ...}, {|o| if
(...) continue; ...});
I don't see how this can support the most likely intended semantics
I think others might have better answers, but it seems that the
meaning of 'break' is to stop the whole
Axel Rauschmayer
January 17, 2012
1:04 AM
Minor
possibility of future-hostility: Should real keyword arguments ever
make it to ECMAScript, labels such as "do:" seem an obvious choice.
No, JS doesn't allow reserved identifiers to be used as parameter names
in any case.
Grant Husbands
January 17, 2012
10:14 AM
I think others
might have better answers, but it seems that themeaning of 'break'
is to stop the whole statement, and the meaning of'continue' is to
skip the inner block and hence return toarr.alternate
That's what I was
On Jan 17, 2012, at 10:14 AM, Grant Husbands wrote:
Allen Wirfs-Brock wrote:
do: arr.alternate ({|o| if (...) continue; if (...) break; ...}, {|o| if
(...) continue; ...});
I don't see how this can support the most likely intended semantics
I think others might have better answers, but
However, block lambdas are often evaluated for a value and none of the
current continue/break based solutions include a way to provide an explicit
continuation value. Here is an idea for that:
foo {||
exit: {
...
if (...) break exit with early;
With completion values as In ES1-5, not even depending on
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it
might be enough to say:
foo {||
exit: {
...
if (...) {
early;
break exit;
}
On Jan 16, 2012, at 11:09 AM, Brendan Eich wrote:
With completion values as In ES1-5, not even depending on
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it might be
enough to say:
You're right, according to ES 5 semantics this does provide early as the
value of the
Allen Wirfs-Brock
January 16, 2012
11:32 AM
On
Jan 16, 2012, at 11:09 AM, Brendan Eich wrote:
I have some angst about loss
of a hunk of code running "break L" up
against " with (E)\nS" where E is an _expression_ and S is a statement and
the two came from a
Allen Wirfs-Brock
January 16, 2012
9:53 AM
On Jan 15, 2012,
at 11:16 PM, Brendan Eich wrote:
I'm not slamming the door, but
I do not want to lumber block-lambdas
with more complexity if the hard case is as rare as I contend. Anyway
"neat" is not enough. We need an
On Jan 15, 2012, at 11:32 PM, Axel Rauschmayer wrote:
Could we call block lambdas just lambdas? The former seems a bit pleonastic.
Block lambdas is a proposal that combines block-based syntax with lambda-based
semantics. There have been other proposals in the past which provide lambda
On Jan 16, 2012, at 11:09 AM, Brendan Eich wrote:
With completion values as In ES1-5, not even depending on
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it might be
enough to say:
foo {||
exit: {
...
if (...) {
Brendan Eich wrote:
2. Variation on empty label: support do as a reserved-identifier label
do: arr.forEach {|o|
if (...) break;
...
}
This seems like a sound way of doing it, indeed (I omitted your first
one because I prefer this one). It avoids the more egregious syntax
, 2012 11:05 PM
To: Herby Vojčík
Cc: François REMY ; es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
Herby Vojčík
January 14, 2012 1:46 PM
=== Brendan Eich wrote ===
This doesn't address Herby's TCP-violating wish for a non-return that
completes the block-lambda's control flow
Brendan Eich wrote:
More when I reply to Axel in a bit.
I think there may have been a misunderstanding. My proposed solution
amounts to syntactic sugar over the existing strawman and makes
break/continue work intuitively with loopy block lambdas, and your
reply to Axel appears to be against an
@mozilla.org
Subject: Re: Block Lambdas: break and continue
Brendan Eich wrote:
More when I reply to Axel in a bit.
I think there may have been a misunderstanding. My proposed solution
amounts to syntactic sugar over the existing strawman and makes
break/continue work intuitively with loopy block
: Block Lambdas: break and continue
Hi,
your 'for call {|| ...}' is great and simple solution for (unlabeled) break,
but it is not so for continue. For either continue could have the redesigned
meaning I sketched out in my last post, but then you need expression to
specify; or you want the legacy
Herby Vojčík wrote:
your 'for call {|| ...}' is great and simple solution for (unlabeled) break,
but it is not so for continue.
To clarify, it matches what continue currently does for other loops,
which is what I was aiming for.
However, I do agree that early completion with a value is
Grant Husbands
January 15, 2012
3:51 AM
Brendan Eich wrote:
More when I reply to Axel in a bit.
I think there may have been a misunderstanding. My proposed solution
amounts to syntactic sugar over the existing strawman and makes
break/continue work intuitively with loopy
Brendan Eich wrote:
I don't see how your proposal can work without exceptions. You write that
it is syntactic sugar. Ok, what is the desugaring? How does
for arr.ForEach { |o|
if (...) break;
}
translate into JS without a throw that the implementation of arr.forEach,
which is not
Grant Husbands
January 15, 2012
8:00 AM
The
above would desugar to:label1:
arr.forEach { |o| if (...) break label1;}If it had continue instead of
break, it would desugar to:arr.forEach
{ |o| label2: {
if (...) break label2; }}It wouldn't need to be described as
-Pôvodná správa-
From: Brendan Eich
Sent: Sunday, January 15, 2012 8:56 PM
To: Grant Husbands
Cc: es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
...
block-Other ideas?
/be
===
I sent an expression-less continue and break elaboration today. at
11:something
On Jan 15, 2012, at 11:56 AM, Brendan Eich wrote:
Grant Husbands
January 15, 2012
8:00 AM
The
above would desugar to:label1:
arr.forEach { |o| if (...) break label1;}If it had continue instead of
break, it would desugar to:arr.forEach
{ |o| label2: {
if (...)
Allen Wirfs-Brock
January 15, 2012
2:31 PM
On
Jan 15, 2012, at 11:56 AM, Brendan Eich wrote:
Thanks for writing this down. You're right, I was wrong: a new
for arr.forEach { |o|
if (...) break;
}
special form would not require exception-reified break and
Herby Vojčík
January 15, 2012
12:15 PM
-Pôvodná správa-
From: Brendan Eich
Sent: Sunday, January 15, 2012 8:56 PM
To: Grant Husbands
Cc: es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
...
block-Other ideas?
/be
===
I sent
The main problem I would have with for as a prefix is semantic, not
grammatical: I would always expect to loop over something iterable and not a
loop implementation.
My impression: Let’s wait until we have a more powerful collection library
(which I assume would use block lambdas extensively).
Axel Rauschmayer
January 15, 2012
11:32 PM
The
main problem I would have with "for" as a prefix is semantic, not
grammatical: I would always expect to loop over something iterable and
not a loop implementation.
Yes, I agree with that and it's what I meant by head-less
to use
based on which is more intent revealing per each use.
Herby
-Pôvodná správa-
From: Axel Rauschmayer
Sent: Saturday, January 14, 2012 6:04 AM
To: Brendan Eich
Cc: es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
I think it’s a valid concern. The idea is: If I
I should have been clearer in my original message; I'll avoid
mentioning Ruby directly, again, as it misdirects conversation.
Though I have no strong opinion on block-lambdas in javascript, I will
try to restate my original position, for clarity:
Block lambdas, as currently described in the
I realized 'break' semantics is in no way enforceable in lambda-block
control structure, and each early return is in fact 'continue' (which may
stop the loop or whatever depending on the value).
Also, since in lambda-block, | character could be used to distinguish it
from keyword-loop-continue.
On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
I think it’s a valid concern. The idea is: If I can implement my own loops
(the nice-looking paren-free syntax feeds that illusion!) then I also want
those loops to have break and continue. You could statically determine what
construct,
.
Herby
-Pôvodná správa-
From: David Herman
Sent: Saturday, January 14, 2012 6:12 PM
To: Axel Rauschmayer
Cc: Brendan Eich ; es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
I think it’s a valid concern. The idea
On Jan 14, 2012, at 9:12 AM, David Herman wrote:
On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
I think it’s a valid concern. The idea is: If I can implement my own loops
(the nice-looking paren-free syntax feeds that illusion!) then I also want
those loops to have break and
If I understand your suggestion, you're proposing that non-local break and
continue should be exposed as standard exceptions, and then implementors of
loop-like abstractions could choose to catch them.
...
Did I understand your suggestion correctly?
Yes. I was thinking about the BGGA
-
From: Herby Vojčík
Sent: Saturday, January 14, 2012 7:42 PM
To: David Herman ; Axel Rauschmayer
Cc: Brendan Eich ; es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
=== David Herman wrote ===
This *may* not violate TCP (I'm not quite sure), but I'm not enthusiastic
about
dná správa-
From: David Herman
Sent: Saturday, January 14, 2012 6:12 PM
To: Axel Rauschmayer
Cc: Brendan Eich ; es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
If I understand your suggestion, you're proposing that non-lo
Two possibilities (but I’m not entirely sure how much sense they make):
- Use a keyword that enables custom break and continue (problem: for clashes
with iterators):
for mycollection.each({ | x | if (x === 0) break })
- Standardize a BreakException. Then breaking isn’t the loop’s
Brendan Eich
January 14, 2012
1:24 PM
Exception handling is seldom used in the large
except to void the
exception.
And then only near or at a top-level event loop.
Exception handling is the issue here, because of the proposal to add
reifed break and continue as
: Saturday, January 14, 2012 10:16 PM
To: François REMY
Cc: Herby Vojčík ; es-discuss@mozilla.org
Subject: Re: Block Lambdas: break and continue
François REMY
January 14, 2012 1:01 PM
If we want to avoid to break TCP, we can go with “throw break;” and “throw
continue;”.
This doesn't address
Herby Vojčík
January 14, 2012
1:46 PM
===
Brendan Eich wrote ===
This doesn't address Herby's TCP-violating wish for a non-return
that
completes the block-lambda's control flow normally with a value (the
message
to which I was replying). But you're right that it
François REMY
January 14, 2012
2:06 PM
Yes, I did not say I was going to struggle about that
functionnality. I
just read some of the many threads of this mailing list and, when I
encounter an
idea that resonnate in my brain, I do my best to play the Devils’
Brendan Eich wrote:
Exception handling is seldom used in the large except to void the
exception.
And then only near or at a top-level event loop.
Exception handling is the issue here, because of the proposal to add
reifed break and continue as thrown exceptions. How exception
handling is
Axel Rauschmayer
January 14, 2012
1:19 PM
Two
possibilities (but I’m not entirely sure how much sense they make):-
Use a keyword that enables custom break and continue (problem: "for"
clashes with iterators):for mycollection.each({ | x | if (x ===
0) break })
On Jan 14, 2012, at 6:46 PM, Brendan Eich wrote:
Adding escape continuations is another case of warty + shiny ~~~ shiny
promised land hope as the evolutionary game we have to play on the web.
Still, I'm in favor of escape continuations but I do not want to bundle them
with block-lambdas.
Allen Wirfs-Brock
January 14, 2012
9:50 PM
With block lambdas that support
the return statement we already have escape continuations:
Right you are, but simulating "early return" in a block-lambda requires
the caller to pass down a {|v| return v} block -- a bit
Block lambdas have been a hot topic, recently, but there's a point of
significant divergence between Ruby (which appears to be the inspiration)
and the proposed solution, in the handling of continue (called 'next', in
Ruby) and 'break'.
To whit: In Ruby, 'next' will end the current run
Grant Husbands
January 13, 2012
7:29 PM
Block
lambdas have been a hot topic, recently, but there's a point of
significant divergence between Ruby (which appears to be the
inspiration)
Not Ruby alone, and not in any chauvinist my-language-is-better sense.
Smalltalk is
I think it’s a valid concern. The idea is: If I can implement my own loops (the nice-looking paren-free syntax feeds that illusion!) then I also want those loops to have break and continue. You could statically determine what construct, say, a break applies to and either throw a BreakException (if
51 matches
Mail list logo
