Block Lambdas: break and continue

Brendan Eich brendan at
Sat Jan 14 14:05:36 PST 2012

> Herby Vojčík <mailto:herby at>
> 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 wouldn't 
> violate TCP either if we support it the same in a block statement as 
> in a block-lambda downward funarg.
> ===
> No. it wasn't my primary wish to have a local return.

I understand, but (as you seem to concede below) if the TCP violation 
this introduces is enough to kill it, I thought I'd argue against it on 
that basis.

Sorry for seeming to miss your larger point -- I am following it closely 
too ;-).

> I wanted to make break and/or continue _semantics_ for 
> lambda-block-loop-like-constructs.


> So since local return is already used for 'continue' in forEach, I 
> just generalized the syntax continue |expr|; (note the | bars, they 
> are part of the syntax)

Oh! I didn't know that. Often we (certainly I do this, others too) use 
bars in such sketches as meta not concrete syntax. Thanks for clarifying.

Anyway, as others have written, this seems an abuse of 'continue'.

Also, you cannot avoid the exception-like effect if this is to propagate 
to the forEach's internal loop. There's no loop visible to the spec or 
an implementation's compiler. So this really is a throwing form. Again I 
do not see how it can be "exception-less".

> to do the local return, thereby functioning as a continue statement. 
> (It would be convenient to have local return, but not the local return 
> itself was the goal).

Local return violates TCP, so we should debate that vs. convenience if 
you like. Sorry if that is not something you want to debate, but I think 
you raised the issue directly and should respond.
> You are true it breaks TCP. (It could be done so that it does not by 
> generalizing the syntax so it works in syntax-loop construct as well 
> with "end loop body with expr as the completion value" semantics; it's 
> only btw, it's too crazy to be considered, probably) So it cannot be 
> used. :-/

Agreed. But let's debate the exception-less claim anyway, to each mutual 
> By "this is de-facto continue" I was thinking more in higher semantic 
> level - continue as in "continue past this block", which in loops 
> means "to the next iteration" but beyond loops it may mean anything 
> that is going to happen after block completes.

The problem is the loop in Array forEach, or any such dynamically 
dispatched caller of a block-lambda that is acting as a mapfun or 
iterator, is hidden from static analysis.

So such a de-facto continue (I see what you mean now; I mentioned early 
return from forEach callback as continue myself) must throw. It cannot 
be exception-free.

Sorry to harp on this, I wonder if one of us is still misunderstanding 
> Also, break is hard to do similar way, because I count out 
> (automatically set up) exceptions (I still live in the impression they 
> are, performance-wise, expensive).


> It seems to be possible to have "break |expr| label;" syntax working: 
> if the function calling the lambda-block is labeled, it should be 
> possible to just make it return the expr, but it is clumsy (and there 
> is no label-less version).

This reminds me of dherman's escape continuation proposal:

We did not promote it from Strawman to Harmony status.
> Overall, I am a bit optimistic, since (if I am not mistaken) 
> lambda-blocks only work inside its scope (as Self blocks, not as 
> Smalltalk blocks), which saves a lot of complications.

Block-lambdas can escape via the heap and be called later (so-called 
async. callbacks). That is not a problem if they do not use return, 
break, or continue. The TCP conformance for |this| is still a win. The 
completion implicit return can be a win too.

> Herby

[Finally trimming overcites!]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1080 bytes
Desc: not available
URL: <>

More information about the es-discuss mailing list