Block Lambdas: break and continue

Brendan Eich brendan at mozilla.org
Sun Jan 15 11:56:31 PST 2012


> Grant Husbands <mailto:esdiscuss at grant.x43.net>
> 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 a desugaring in a strawman, given
> the similarity to typical break/continue handling, but I think that
> makes the meaning clear.

No, this is a special form and if it can be specified by desugaring, 
that is better in principle than extending the spec's kernel semantics. 
Whether it actually pays to gensym a label and translate in the spec is TBD.

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 continue 
given the desugaring you show.

Let's talk about syntax, though. This use of for makes something that 
looks like a paren-free for loop, but there's no body. Note that (as 
Francois pointed out earlier) block-lambdas cannot start statements, and 
the block-lambda above is an argument to arr.forEach.

(The "for" repeating after the keyword in the "forEach" name is 
unfortunate, but let's say we can migrate to a JQuery-like "each" name 
to resolve this glitch.)

Even with paren-free moving toward more significant newlines, the 
newline in the example does not terminate the loop "head", it is part of 
the block-lambda in the head. So this is future-hostile to paren-free.

I wonder whether we need this use of "for". It's not clear the continue 
case arises enough with forEach to be worth it. The break case is 
already satisfied by some/every. If we can defer this sugar until it's 
clear we know the need for it is strong enough to measure, we ought to 
-- esp. given the paren-free conflict.

We could try for other syntax, but it too would have the body-less 
problem. Unless we use a new keyword:

> loop arr.forEach {|o|
>    if (...) break;
> }

We could contextually reserve loop. But statements are part of JS, and 
so I suspect people would want this to do what Doug Crockford has 
suggested it to:indefinitelyiterate its body (here the arr.forEach call 
expression statement, which would have a semicolon inserted 
automatically after). This is a conflict, since forEach does its own 
looping.

Other ideas?

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120115/07e8bbad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120115/07e8bbad/attachment.jpg>


More information about the es-discuss mailing list