<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div 
style="display:table;width:100%;border-top:1px solid 
#EDEEF0;padding-top:5px">       <div 
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
 photoaddress="herby@mailbox.sk" photoname="Herby Vojčík" 
src="cid:part1.05030209.02020303@mozilla.org" name="postbox-contact.jpg"
 height="25px" width="25px"></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a moz-do-not-send="true" href="mailto:herby@mailbox.sk" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Herby Vojčík</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 14, 2012 
1:46 PM</span></font></div></div></div>
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">=== 
Brendan Eich wrote ===
<br>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.
<br>===
<br>
<br>No. it wasn't my primary wish to have a local return.</div>
</blockquote>
<br>
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.<span><br>
  <br>
Sorry for seeming to miss your larger point -- I am following it closely
 too ;-).<br>
  <br>
</span>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"> I wanted 
to make break 
and/or continue _semantics_ for lambda-block-loop-like-constructs.
<br></div>
</blockquote>
<br>
Understood.<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">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)</div>
</blockquote>
<br>
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.<br>
<br>
Anyway, as others have written, this seems an abuse of 'continue'.<br>
<br>
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".<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"> 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).<br></div>
</blockquote>
<br>
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.<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div>
<br>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. :-/
<br></div>
</blockquote>
<br>
Agreed. But let's debate the exception-less claim anyway, to each mutual
 understanding.<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div>
<br>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.
<br></div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Sorry to harp on this, I wonder if one of us is still misunderstanding 
something.<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div>
<br>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).</div>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div> 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).</div>
</blockquote>
<br>
This reminds me of dherman's escape continuation proposal:<br>
<br>
<a class="moz-txt-link-freetext" href="http://wiki.ecmascript.org/doku.php?id=strawman:return_to_label">http://wiki.ecmascript.org/doku.php?id=strawman:return_to_label</a><br>
<br>
We did not promote it from Strawman to Harmony status.<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div>
<br>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.
<br></div>
</blockquote>
<br>
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.<br>
<br>
/be<br>
<blockquote style="border: 0px none;" 
cite="mid:AC11DF7FD01B4374A6F0B00BFE2A265B@RAFAEL" type="cite">
  <div>
<br>Herby<br></div>
</blockquote>
<br>
[Finally trimming overcites!]<br>
<br>
/be<br>
</body></html>