<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:C35E38BCD4444B58B500276A124B097D@FREMY2" 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="fremycompany_pub@yahoo.fr" photoname="François REMY" 
src="cid:part1.05090508.05080005@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:fremycompany_pub@yahoo.fr" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">François REMY</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:31 PM</span></font></div></div></div>
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div style="font-family: 'Segoe UI'; color: rgb(0, 0, 0); font-size: 
12pt;">
<div>Thanks for your reply. I think you misunderstood the whole concept.</div></div></div></div>
</blockquote>
<br>
Could be, or perhaps you misunderstood my reply to Herby's message, 
which had nothing to do with the ax you are grinding :-|.<br>
<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:C35E38BCD4444B58B500276A124B097D@FREMY2" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
    <div dir="ltr">
      <div style="font-family: 'Segoe UI'; color: rgb(0, 0, 0); 
font-size: 12pt;">
        <div> The 
idea would not to implement that for Arrays. Arrays already have their 
own 
semantics.</div>
      </div>
    </div>
  </div>
</blockquote>
<br>
Look back up the thread (or down the cited messages below -- but I think
 I'll trim the overciting) and see Axel bringing up Array forEach as the
 use-case for dynamic break and continue semantics in block-lambdas.<br>
<br>
I appreciate your repair via "throw break" and "throw continue" to 
restore TCP. That's not at issue.<br>
<br>
What is at issue is the cost/benefit analysis, which does depend on 
developer ergonomics of exceptions, including as block-lambdas that 
throw break or throw continue might work (or not) with Array extras.<br>
<br>
You cannot _a priori_ exclude complex scenarios by wishing for better 
programmers, or programmers who use new functional styles and only new 
APIs, and buy into the complexity of the new exceptions. At least, Ecma 
TC39 cannot.<br>
<br>
We have to consider how poorly or well exceptions are used today, how 
developers might use them tomorrow, what reasonable (see Axel's post) 
expectations they might have for Array extras called with block-lambdas.<br>
<br>
The throw break and throw continue ideas are coherent and we could 
design them into a future spec. I have no doubt about this. But I do not
 think the complexity, for developers first but also for implementors 
(and last for the spec editors) is worth it.<br>
<blockquote style="border: 0px none;" 
cite="mid:C35E38BCD4444B58B500276A124B097D@FREMY2" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
    <div dir="ltr">
      <div style="font-family: 'Segoe UI'; color: rgb(0, 0, 0); 
font-size: 12pt;">
<div> </div>
<div>I think the idea about Block Lamdba is to introduce functionnal 
programming 
concepts to ECMAScript.</div></div>
    </div>
  </div>
</blockquote>
<br>
Not really. JS is used in function-programming styles (there's more than
 one) already.<br>
<br>
What block-lambdas aim to do is provide much sweeter downward-funarg 
syntax and semantics, which aids refactoring and reasoning about such 
"synchronous callback" code.<br>
<br>
Block-lambdas may be used with asynchronous callback code too, with the 
benefits of |this| invariance and completion-return.<br>
<br>
This is not a big new functional-programming concept push. It's a 
usability and safety (wrong-this bugs are bad) win for many (not all) 
uses of function-expressions-as-callbacks we see today.<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:C35E38BCD4444B58B500276A124B097D@FREMY2" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
    <div dir="ltr">
      <div style="font-family: 'Segoe UI'; color: rgb(0, 0, 0); 
font-size: 12pt;">
        <div> It’s it’s the case, developers will want to implement 
their own kind of Head|Queue stream. For exemple, a webworker computing 
values 
and calling the callback with the computed value each time he output a 
new one 
(using a postMessage channel). The problem is that you may need to have a
 way to 
say to the WebWorker “OK, I want to break the loop, I’ve what I need, 
please 
stop computing and free memory.” You could use your own “throw” pattern 
but 
using a standard one could be useful for code reuse.</div>
      </div>
    </div>
  </div>
</blockquote>
<br>
I'd say that differently: for such hard cases, throw already exists. The
 burden is on the proposer to show this is common enough to justify 
making break and continue, or in your proposal, new "throw break" and 
"throw continue" forms, throw new exceptions.<br>
<br>
The problem is not just the cost of adding new forms (let's say your 
proposal wins -- it is much better than redefining break and continue to
 throw).<br>
<br>
The issue I'm raising is the consequence on "looping" and "wrapper" 
functions in common use (whether Array forEach or JQuery each or 
something new next year or bespoke in a private codebase) of introducing
 such new exceptions as standards.<br>
<br>
Let the worker hard case use "throw" and its own sentinel object, and 
let's see how common and non-hard this case becomes. I doubt it will 
grow to become much seen.<br>
<br>
(Indeed I hope it is supplanted by better concurrency structures than 
workers, and we're laboring to develop such things. But whatever happens
 there, this use-case is not obviously common enough to be worth a 
change with global effects.)<br>
<br>
/be<br>
<blockquote style="border: 0px none;" 
cite="mid:C35E38BCD4444B58B500276A124B097D@FREMY2" type="cite">
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
    <div dir="ltr">
      <div style="FONT-FAMILY: 'Segoe UI'; COLOR: #000000; FONT-SIZE: 
12pt">
<div> </div>
<div>I hope I was clear,</div>
<div>François</div>
<div> </div>
<div style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri';
 COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION:
 none">
<div style="FONT: 10pt tahoma">
<div> </div>
<div style="BACKGROUND: #f5f5f5">
<div style="font-color: black"><b>From:</b> <a moz-do-not-send="true" 
href="mailto:brendan@mozilla.org" title="brendan@mozilla.org">Brendan 
Eich</a> </div>
<div><b>Sent:</b> Saturday, January 14, 2012 10:16 PM</div>
<div><b>To:</b> <a moz-do-not-send="true" 
href="mailto:fremycompany_pub@yahoo.fr" 
title="fremycompany_pub@yahoo.fr">François REMY</a> </div>
<div><b>Cc:</b> <a moz-do-not-send="true" href="mailto:herby@mailbox.sk"
 title="herby@mailbox.sk">Herby 
Vojčík</a> ; <a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" title="es-discuss@mozilla.org">es-discuss@mozilla.org</a>
 </div>
<div><b>Subject:</b> Re: Block Lambdas: break and continue</div></div></div>
<div> </div></div>
<div style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri';
 COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION:
 none">
<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px"><div 
class="__pbConvHr" style="MARGIN: 30px 25px 10px">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img photoaddress="fremycompany_pub@yahoo.fr" 
photoname="François REMY" src="cid:part1.05090508.05080005@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:fremycompany_pub@yahoo.fr" style="PADDING-RIGHT: 6px; 
COLOR: #737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none 
!important">François 
  REMY</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:01 
  PM</span></font></div></div></div>
  <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
  <div dir="ltr">
  <div style="FONT-FAMILY: 'Segoe UI'; COLOR: rgb(0,0,0); FONT-SIZE: 
12pt">
  <div>If we want to avoid to break TCP, we can go with “throw break;” 
and 
  “throw continue;”.</div></div></div></div></blockquote><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>
<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px"><div 
__pbrmquotes="true" class="__pbConvBody" style="COLOR: rgb(136,136,136);
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
  <div dir="ltr">
  <div style="FONT-FAMILY: 'Segoe UI'; COLOR: rgb(0,0,0); FONT-SIZE: 
12pt">
  <div>It would throw a new BreakException or a new ContinueException, 
from the 
  place where they are executed. If it’s outside a block lambda, it’s 
outside a 
  block lambda. It doesn’t matter.</div></div></div></div></blockquote><br>Yes,
 
this would avoid TCP violations but not carry a return value -- Herby's 
wish.<br>
<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px"><div 
__pbrmquotes="true" class="__pbConvBody" style="COLOR: rgb(136,136,136);
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
  <div dir="ltr">
  <div style="FONT-FAMILY: 'Segoe UI'; COLOR: rgb(0,0,0); FONT-SIZE: 
12pt">
  <div> </div>
  <div>But it would set a “standard” for breaking throug ‘function 
  loops’.</div></div></div></div></blockquote><br>I considered this in 
drafting 
the block-lambda revival strawman. Other languages have gone here. 
Nevertheless, 
I would like to leave it out (remember N. Wirth on language design). It 
adds 
more complexity for a use-case that I bet is rare (in any case it needs 
credible 
demonstration of being quite common).<br><br>The complexity in the 
semantics is 
one issue Dave raised. This corresponds to complexity for optimizing 
engines, 
compared to the purely static break/continue semantics in the 
strawman.<br><br>Finally, the Array extras ship sailed. People already 
have to 
use some or every in lieu of a break-from-forEach. Using a function 
callback 
with forEach, one needs only to return to simulate continue. Now if we 
do 
standardize block-lambdas and throw break or throw continue, we 
certainly can 
elaborate the extras to catch these exceptions.<br><br>Such a more 
complex 
design seems workable with the costs noted above. But will the benefits 
really 
outweigh those costs? I doubt it. First, Array forEach and other uses 
will 
continue to use functions for quite a while, or else a compiler from new
 
standard JS to old. In the compiler case, throw and try/catch will be 
required, 
and the compiler will have to monkey-patch the extras to deal with the 
new 
exceptions. This will be a performance killer, and no fun to debug.<br><br>So
 my 
thinking remains that we are better off, when in doubt, leaving reified 
break 
and continue exceptions "out".<br><br>/be<br><br>
<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px"><div 
__pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
  <div dir="ltr">
  <div style="FONT-FAMILY: 'Segoe UI'; COLOR: #000000; FONT-SIZE: 12pt">
  <div>François</div>
  <div style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 
'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; 
TEXT-DECORATION: none">
  <div style="FONT: 10pt tahoma">
  <div> </div>
  <div style="BACKGROUND: #f5f5f5">
  <div style="font-color: black"><b>From:</b> <a moz-do-not-send="true" 
href="mailto:brendan@mozilla.org" title="brendan@mozilla.org">Brendan 
Eich</a> 
  </div>
  <div><b>Sent:</b> Saturday, January 14, 2012 9:51 PM</div>
  <div><b>To:</b> <a moz-do-not-send="true" 
href="mailto:herby@mailbox.sk" title="herby@mailbox.sk">Herby Vojčík</a>
 </div>
  <div><b>Cc:</b> <a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" title="es-discuss@mozilla.org">es-discuss@mozilla.org</a>
 </div>
  <div><b>Subject:</b> Re: Block Lambdas: break and continue</div></div></div>
  <div> </div></div>
  <div style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 
'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; 
TEXT-DECORATION: none">
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img photoaddress="herby@mailbox.sk" photoname="Herby Vojčík" 
src="cid:part3.03020502.06030808@mozilla.org" name="postbox-contact.jpg"
 height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:herby@mailbox.sk" style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; 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 10:42 
    AM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">=== David 
Herman wrote === <br>This 
    *may* not violate TCP (I'm not quite sure), but I'm not enthusiastic
 about 
    the idea. The semantics is significantly more complicated, and it 
requires 
    you to understand whether a higher-order function like forEach is 
catching 
    these exceptions or not. So it becomes an additional part of the API
 of a 
    function. If someone doesn't document what they do with 
BreakException and 
    ContinueException, then writing callbacks you won't actually be able
 to 
    predict what `break` and `continue` will do. <br>=== <br><br>What 
about the 
    exception-less suggestion I put in? It should work in any loop 
construct 
    with lambda-block, even if you must know a little about the loop 
    implementation itself. That is, to be able to put: <br><br>   
    continue |expression|; <br></div></blockquote><br>Who says the 
block-lambda is 
  being called from a loop at all? Why should use-cases that want an 
early 
  result and completion have to use continue, which is for loops?<br><br>Worse,
 
  this violates TCP. Now you copy and paste this block-lambda code back 
into a 
  block statement to refactor the other direction, and no such "here is 
the 
  completion value, do not flow past this point in the block" semantics 
  obtain.<br>
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px"><br>as a 
statement in lambda block 
    which instructs the lambda-block itself (not the outer function) to 
return 
    the expression? This is the de-facto continue semantics 
(lambda-block, do 
    return a value and the enclosing loop will continue to the next 
iteration 
    (possibly stopping the loop if it chooses not to have more 
    iterations)).</div></blockquote><br>No it's not. There is no 
de-facto continue 
  semantics for block-lambdas because they haven't been prototyped. For 
block 
  statements, no such continue semantics exists.<br><br>
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">It is not 
possible to enforce break 
    in the same manner, but for continue, it is possible. 
  <br></div></blockquote><br>It's possible to abuse any existing 
keyword, but 
  first: why must there be a new TCP violation? Block-lambda bodies are 
often 
  expressions, or if statements, then short/functional-style statements,
 not 
  large bodies demonstrating early-normal-completion opportunities.<br><br>We
 
  should not eliminate TCP violations only to add new ones, especially 
without 
  any evidence they're needed and pay their way. Otherwise we'll get an 
infinite 
  regress of TCP-pure-then-add-new-exceptions-and-repeat 
  additions.<br><br>/be<br>
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px"><br>Herby <br><br>-----Pôvodná 
    správa----- From: David Herman <br>Sent: Saturday, January 14, 2012 
6:12 PM 
    <br>To: Axel Rauschmayer <br>Cc: Brendan Eich ; <a 
moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" 
class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a> <br>Subject:
 Re: Block 
    Lambdas: break and continue <br><br>On Jan 13, 2012, at 9:04 PM, 
Axel 
    Rauschmayer wrote: <br><br><br>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. E.g. you could implement forEach as: <br><br>   
    Array.prototype.forEach = function(f) { 
    <br>       for (let i = 0, n = this.length; i 
    < n; i++) { 
    <br>           try { 
    <br>               
    f.call(this, this[i], i); 
    <br>           } catch (e) 
    { 
    <br>               
    if (e instanceof BreakException) 
    <br>                   
    break; 
    <br>               
    else if (e instanceof ContinueException) 
    <br>                   
    continue; 
    <br>               
    else 
    <br>                   
    throw e; <br>           } 
    <br>       } <br>   }; 
    <br><br>Whereas a function that does *not* want to expose whether 
it's using 
    loops would simply do nothing with BreakException and 
ContinueException, and 
    they would propagate out and you'd get the lexical scoping 
semantics. 
    Meanwhile, break/continue with an explicit target would never be 
catch-able. 
    <br><br>Did I understand your suggestion correctly? <br><br>This 
*may* not 
    violate TCP (I'm not quite sure), but I'm not enthusiastic about the
 idea. 
    The semantics is significantly more complicated, and it requires you
 to 
    understand whether a higher-order function like forEach is catching 
these 
    exceptions or not. So it becomes an additional part of the API of a 
    function. If someone doesn't document what they do with 
BreakException and 
    ContinueException, then writing callbacks you won't actually be able
 to 
    predict what `break` and `continue` will do. <br><br>Dave 
    <br><br>_______________________________________________ <br>es-discuss
 
    mailing list <br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
 <br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
 
    <br>_______________________________________________ <br>es-discuss 
mailing 
    list <br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
 <br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
 
    <br></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img photoaddress="dherman@mozilla.com" photoname="David 
Herman" src="cid:part4.06030106.07030500@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:dherman@mozilla.com" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">David
 
    Herman</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 14, 2012 9:12 
    AM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
    <div><!----><br>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. E.g. 
    you could implement forEach as:<br><br>Array.prototype.forEach = 
function(f) 
    {<br>for (let i = 0, n = this.length; i < n; i++) {<br>try 
    {<br>f.call(this, this[i], i);<br>} catch (e) {<br>if (e instanceof 
    BreakException)<br>break;<br>else if (e instanceof 
    ContinueException)<br>continue;<br>else<br>throw 
    e;<br>}<br>}<br>};<br><br>Whereas a function that does *not* want to
 expose 
    whether it's using loops would simply do nothing with BreakException
 and 
    ContinueException, and they would propagate out and you'd get the 
lexical 
    scoping semantics. Meanwhile, break/continue with an explicit target
 would 
    never be catch-able.<br><br>Did I understand your suggestion 
    correctly?<br><br>This *may* not violate TCP (I'm not quite sure), 
but I'm 
    not enthusiastic about the idea. The semantics is significantly more
 
    complicated, and it requires you to understand whether a 
higher-order 
    function like forEach is catching these exceptions or not. So it 
becomes an 
    additional part of the API of a function. If someone doesn't 
document what 
    they do with BreakException and ContinueException, then writing 
callbacks 
    you won't actually be able to predict what `break` and `continue` 
will 
    do.<br><br>Dave<br><br><br></div></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img photoaddress="axel@rauschma.de" photoname="Axel 
Rauschmayer" src="cid:part5.03060001.03030500@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:axel@rauschma.de" style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Axel 
    Rauschmayer</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 9:04 
    PM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">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 it applies to a 
lambda) or 
    TCP-break (if it applies to an enclosing non-lambda loop). In the 
examples 
    below, when I see a continue, I look for the innermost enclosing 
loop braces 
    and the ones belong to list[i].forEach are definitely candidates. 
    <div>
    <div> </div>
    <div> </div>
    <div> </div>
    <div apple-content-edited="true"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: 12px helvetica;
 WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); WORD-SPACING: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space">
    <div style="MARGIN: 0px"><span class="Apple-style-span" 
style="FONT-SIZE: medium">
    <div style="MARGIN: 0px">-- </div>
    <div style="MARGIN: 0px">Dr. Axel Rauschmayer</div>
    <div style="MARGIN: 0px"><a moz-do-not-send="true" 
href="mailto:axel@rauschma.de">axel@rauschma.de</a></div>
    <div style="MARGIN: 0px"> </div>
    <div style="MARGIN: 0px">
    <div style="MARGIN: 0px">home: <a moz-do-not-send="true" 
href="http://rauschma.de">rauschma.de</a></div>twitter: <a 
moz-do-not-send="true" href="http://twitter.com/rauschma">twitter.com/rauschma</a></div>
    <div style="MARGIN: 0px">blog: <a moz-do-not-send="true" 
href="http://2ality.com">2ality.com</a></div></span></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></span></div>
    <div> </div></div></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img photoaddress="brendan@mozilla.org" photoname="Brendan 
Eich" src="cid:part6.03040206.09050504@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:brendan@mozilla.org" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Brendan
 
    Eich</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 8:54 
    PM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
      <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
      <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; 
VERTICAL-ALIGN: middle"><img moz-do-not-send="true" 
photoaddress="esdiscuss@grant.x43.net" photoname="Grant Husbands" 
src="cid:part7.00010809.01050404@mozilla.org" 
name="compose-unknown-contact.jpg" height="25" width="25"></div>
      <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap;
 VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:esdiscuss@grant.x43.net" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Grant
 
      Husbands</a></div>
      <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 7:29 
      PM</span></font></div></div></div>
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">Block lambdas 
have been a hot 
      topic, recently, but there's a point of significant divergence 
between 
      Ruby (which appears to be the inspiration)</div></blockquote><br>Not
 Ruby 
    alone, and not in any chauvinist my-language-is-better sense. 
Smalltalk is 
    the original inspiration for Ruby blocks, and the correspondence 
principle 
    has deep roots.<br><br>
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">and the 
proposed solution, in the 
      handling of continue (called 'next', in Ruby) and 'break'. 
      <div> </div>
      <div>To whit: In Ruby, 'next' will end the current run (iteration)
 of the 
      block, and 'break' will (somehow) terminate the method lexically 
connected 
      with the block. It can be claimed that this is more intuitive than
 the 
      current proposal, which aims to make 'break' and 'continue' 
propagate 
      through block lambdas in the same way 'return' 
    would.</div></div></blockquote><br>"Intuitive" depends on intuition,
 which 
    is not well-defined. Do you mean a Rubyist might expect different 
behavior 
    for break? That is possible but JS ain't Ruby and break should not 
change to 
    do something like what it does in Ruby (and we aren't defining a 
next 
    equivalent for JS).<br><br>
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
      <div>Ruby does also support syntactic loops and the same keywords 
therein 
      and so directly violates Tennent's Correspondence Principle, even 
though 
      such has been touted as a core reason for the construct. Instead, I
 
      believe it reasonable to invoke intuition in this matter. It is 
intuitive 
      for 'return' to return a value from the lexically enclosing method
 and it 
      is intuitive for 'continue' to commence the next iteration of the 
current 
      loop,</div></div></blockquote><br>Wait, why do you think break and
 continue 
    without label operands do anything other than break from the nearest
 
    enclosing loop (or switch or labeled statement if break), or 
continue the 
    nearest enclosing loop? The proposal specifies this.<br><br><span 
style="FONT-FAMILY: monospace">function 
    find_odds_in_arrays(list,        // array 
    of arrays</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">                             
    skip)        // if found, skip 
    rest</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">{</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">  
    let a = [];</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">  for (let i = 0; i < list.length; 
    i++) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">    list[i].forEach 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">      |e|</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      if (e === 
    skip) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">        
    continue;                         
    // continue the for loop</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      if (e & 1) 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">        
    a.push(e);</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">    }</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
    }</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">  return a;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br><span><span style="FONT-FAMILY: monospace">function 
find_more_odds(list, stop) 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">  let a = [];</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">  
    for (let i = 0; i < list.length; i++) {</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">    
list[i].forEach 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">      |e|</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      if (e === 
    stop) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">        
    break;                      
    // break from the for loop</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      if (e & 1) 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">        
    a.push(e);</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">    }</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
    }</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">  return a;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br>
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
#888888; MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
      <div>however that loop is 
    constructed.</div></div></blockquote></span><br>What do you mean by 
this? 
    The spec talks about nearest enclosing loop or relevant control 
structure in 
    the source code. Are you talking about internal loops in 
implementations 
    (dynamically dispatched at that) of methods that take block-lambdas 
as 
    arguments? I.e.<br><br><br><span style="FONT-FAMILY: monospace">function
 
    find_first_odd(a) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">  a.forEach { |e, i|</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">             
 
    if (e & 1) return i; }  // returns from function</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
    return -1;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br><br>The Array.prototype.forEach method's 
    internal implementation is its business, and a break instead of the 
return 
    would be a static error in this example. It would not be a dynamic 
    throw-like construct that is caught by forEach's 
    implementation.<br><br>/be<br></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img photoaddress="esdiscuss@grant.x43.net" photoname="Grant 
Husbands" src="cid:part7.00010809.01050404@mozilla.org" 
name="compose-unknown-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:esdiscuss@grant.x43.net" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Grant
 
    Husbands</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 7:29 
    PM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">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'. 
    <div> </div>
    <div>To whit: In Ruby, 'next' will end the current run (iteration) 
of the 
    block, and 'break' will (somehow) terminate the method lexically 
connected 
    with the block. It can be claimed that this is more intuitive than 
the 
    current proposal, which aims to make 'break' and 'continue' 
propagate 
    through block lambdas in the same way 'return' would.</div>
    <div> </div>
    <div>Ruby does also support syntactic loops and the same keywords 
therein 
    and so directly violates Tennent's Correspondence Principle, even 
though 
    such has been touted as a core reason for the construct. Instead, I 
believe 
    it reasonable to invoke intuition in this matter. It is intuitive 
for 
    'return' to return a value from the lexically enclosing method and 
it is 
    intuitive for 'continue' to commence the next iteration of the 
current loop, 
    however that loop is constructed.</div>
    <div> </div>
    <div>Note that the label-based break/continue could still have the 
desired 
    effect, if the proposal was updated to be more like Ruby's blocks.</div>
    <div> </div>
    <div>I don't have a strong opinion on the subject, but I hadn't 
noticed the 
    above being discussed, elsewhere, and thought it worth raising. If 
there is 
    a better place for me to raise this, please let me know where and 
accept my 
    apologies.</div>
    <div> </div>
    <div>Regards,</div>
    <div>Grant Husbands.</div>
    <div>_______________________________________________<br>es-discuss 
mailing 
    list<br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a><br><a
 moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div></blockquote>
  <hr>
  _______________________________________________<br>es-discuss mailing 
  list<br><a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org"
 class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a><br><a 
moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div></div><pre wrap="">_______________________________________________
es-discuss mailing list
<a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
<a moz-do-not-send="true" href="https://mail.mozilla.org/listinfo/es-discuss" class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre></div>
  <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img photoaddress="brendan@mozilla.org" photoname="Brendan Eich"
 src="cid:part6.03040206.09050504@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:brendan@mozilla.org" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Brendan
 
Eich</a></div>
  <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; VERTICAL-ALIGN: 
middle"><font color="#9fa2a5"><span style="PADDING-LEFT: 6px">January 
14, 2012 12:51 
  PM</span></font></div></div></div>
  <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img moz-do-not-send="true" photoaddress="herby@mailbox.sk" 
photoname="Herby Vojčík" src="cid:part3.03020502.06030808@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:herby@mailbox.sk" style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; 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 10:42 
    AM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">=== David 
Herman wrote === <br>This 
    *may* not violate TCP (I'm not quite sure), but I'm not enthusiastic
 about 
    the idea. The semantics is significantly more complicated, and it 
requires 
    you to understand whether a higher-order function like forEach is 
catching 
    these exceptions or not. So it becomes an additional part of the API
 of a 
    function. If someone doesn't document what they do with 
BreakException and 
    ContinueException, then writing callbacks you won't actually be able
 to 
    predict what `break` and `continue` will do. <br>=== <br><br>What 
about the 
    exception-less suggestion I put in? It should work in any loop 
construct 
    with lambda-block, even if you must know a little about the loop 
    implementation itself. That is, to be able to put: <br><br>   
    continue |expression|; <br></div></blockquote><br>Who says the 
block-lambda is 
  being called from a loop at all? Why should use-cases that want an 
early 
  result and completion have to use continue, which is for loops?<br><br>Worse,
 
  this violates TCP. Now you copy and paste this block-lambda code back 
into a 
  block statement to refactor the other direction, and no such "here is 
the 
  completion value, do not flow past this point in the block" semantics 
  obtain.<br>
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px"><br>as a 
statement in lambda block 
    which instructs the lambda-block itself (not the outer function) to 
return 
    the expression? This is the de-facto continue semantics 
(lambda-block, do 
    return a value and the enclosing loop will continue to the next 
iteration 
    (possibly stopping the loop if it chooses not to have more 
    iterations)).</div></blockquote><br>No it's not. There is no 
de-facto continue 
  semantics for block-lambdas because they haven't been prototyped. For 
block 
  statements, no such continue semantics exists.<br><br>
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">It is not 
possible to enforce break 
    in the same manner, but for continue, it is possible. 
  <br></div></blockquote><br>It's possible to abuse any existing 
keyword, but 
  first: why must there be a new TCP violation? Block-lambda bodies are 
often 
  expressions, or if statements, then short/functional-style statements,
 not 
  large bodies demonstrating early-normal-completion opportunities.<br><br>We
 
  should not eliminate TCP violations only to add new ones, especially 
without 
  any evidence they're needed and pay their way. Otherwise we'll get an 
infinite 
  regress of TCP-pure-then-add-new-exceptions-and-repeat 
  additions.<br><br>/be<br>
  <blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px">
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px"><br>Herby <br><br>-----Pôvodná 
    správa----- From: David Herman <br>Sent: Saturday, January 14, 2012 
6:12 PM 
    <br>To: Axel Rauschmayer <br>Cc: Brendan Eich ; <a 
moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" 
class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a> <br>Subject:
 Re: Block 
    Lambdas: break and continue <br><br>On Jan 13, 2012, at 9:04 PM, 
Axel 
    Rauschmayer wrote: <br><br><br>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. E.g. you could implement forEach as: <br><br>   
    Array.prototype.forEach = function(f) { 
    <br>       for (let i = 0, n = this.length; i 
    < n; i++) { 
    <br>           try { 
    <br>               
    f.call(this, this[i], i); 
    <br>           } catch (e) 
    { 
    <br>               
    if (e instanceof BreakException) 
    <br>                   
    break; 
    <br>               
    else if (e instanceof ContinueException) 
    <br>                   
    continue; 
    <br>               
    else 
    <br>                   
    throw e; <br>           } 
    <br>       } <br>   }; 
    <br><br>Whereas a function that does *not* want to expose whether 
it's using 
    loops would simply do nothing with BreakException and 
ContinueException, and 
    they would propagate out and you'd get the lexical scoping 
semantics. 
    Meanwhile, break/continue with an explicit target would never be 
catch-able. 
    <br><br>Did I understand your suggestion correctly? <br><br>This 
*may* not 
    violate TCP (I'm not quite sure), but I'm not enthusiastic about the
 idea. 
    The semantics is significantly more complicated, and it requires you
 to 
    understand whether a higher-order function like forEach is catching 
these 
    exceptions or not. So it becomes an additional part of the API of a 
    function. If someone doesn't document what they do with 
BreakException and 
    ContinueException, then writing callbacks you won't actually be able
 to 
    predict what `break` and `continue` will do. <br><br>Dave 
    <br><br>_______________________________________________ <br>es-discuss
 
    mailing list <br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
 <br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
 
    <br>_______________________________________________ <br>es-discuss 
mailing 
    list <br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
 <br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
 
    <br></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img moz-do-not-send="true" photoaddress="dherman@mozilla.com" 
photoname="David Herman" src="cid:part4.06030106.07030500@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:dherman@mozilla.com" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">David
 
    Herman</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 14, 2012 9:12 
    AM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
    <div><!----><br>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. E.g. 
    you could implement forEach as:<br><br>Array.prototype.forEach = 
function(f) 
    {<br>for (let i = 0, n = this.length; i < n; i++) {<br>try 
    {<br>f.call(this, this[i], i);<br>} catch (e) {<br>if (e instanceof 
    BreakException)<br>break;<br>else if (e instanceof 
    ContinueException)<br>continue;<br>else<br>throw 
    e;<br>}<br>}<br>};<br><br>Whereas a function that does *not* want to
 expose 
    whether it's using loops would simply do nothing with BreakException
 and 
    ContinueException, and they would propagate out and you'd get the 
lexical 
    scoping semantics. Meanwhile, break/continue with an explicit target
 would 
    never be catch-able.<br><br>Did I understand your suggestion 
    correctly?<br><br>This *may* not violate TCP (I'm not quite sure), 
but I'm 
    not enthusiastic about the idea. The semantics is significantly more
 
    complicated, and it requires you to understand whether a 
higher-order 
    function like forEach is catching these exceptions or not. So it 
becomes an 
    additional part of the API of a function. If someone doesn't 
document what 
    they do with BreakException and ContinueException, then writing 
callbacks 
    you won't actually be able to predict what `break` and `continue` 
will 
    do.<br><br>Dave<br><br><br></div></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img moz-do-not-send="true" photoaddress="axel@rauschma.de" 
photoname="Axel 
Rauschmayer" src="cid:part5.03060001.03030500@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:axel@rauschma.de" style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Axel 
    Rauschmayer</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 9:04 
    PM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">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 it applies to a 
lambda) or 
    TCP-break (if it applies to an enclosing non-lambda loop). In the 
examples 
    below, when I see a continue, I look for the innermost enclosing 
loop braces 
    and the ones belong to list[i].forEach are definitely candidates. 
    <div>
    <div> </div>
    <div> </div>
    <div> </div>
    <div apple-content-edited="true"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: 12px helvetica;
 WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); WORD-SPACING: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto">
    <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space">
    <div style="MARGIN: 0px"><span class="Apple-style-span" 
style="FONT-SIZE: medium">
    <div style="MARGIN: 0px">-- </div>
    <div style="MARGIN: 0px">Dr. Axel Rauschmayer</div>
    <div style="MARGIN: 0px"><a moz-do-not-send="true" 
href="mailto:axel@rauschma.de">axel@rauschma.de</a></div>
    <div style="MARGIN: 0px"> </div>
    <div style="MARGIN: 0px">
    <div style="MARGIN: 0px">home: <a moz-do-not-send="true" 
href="http://rauschma.de">rauschma.de</a></div>twitter: <a 
moz-do-not-send="true" href="http://twitter.com/rauschma">twitter.com/rauschma</a></div>
    <div style="MARGIN: 0px">blog: <a moz-do-not-send="true" 
href="http://2ality.com">2ality.com</a></div></span></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></span></div>
    <div> </div></div></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img moz-do-not-send="true" photoaddress="brendan@mozilla.org" 
photoname="Brendan Eich" src="cid:part6.03040206.09050504@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:brendan@mozilla.org" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Brendan
 
    Eich</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 8:54 
    PM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
      <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
      <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; 
VERTICAL-ALIGN: middle"><img moz-do-not-send="true" 
photoaddress="esdiscuss@grant.x43.net" photoname="Grant Husbands" 
src="cid:part7.00010809.01050404@mozilla.org" 
name="compose-unknown-contact.jpg" height="25" width="25"></div>
      <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap;
 VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:esdiscuss@grant.x43.net" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Grant
 
      Husbands</a></div>
      <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 7:29 
      PM</span></font></div></div></div>
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">Block lambdas 
have been a hot 
      topic, recently, but there's a point of significant divergence 
between 
      Ruby (which appears to be the inspiration)</div></blockquote><br>Not
 Ruby 
    alone, and not in any chauvinist my-language-is-better sense. 
Smalltalk is 
    the original inspiration for Ruby blocks, and the correspondence 
principle 
    has deep roots.<br><br>
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">and the 
proposed solution, in the 
      handling of continue (called 'next', in Ruby) and 'break'. 
      <div> </div>
      <div>To whit: In Ruby, 'next' will end the current run (iteration)
 of the 
      block, and 'break' will (somehow) terminate the method lexically 
connected 
      with the block. It can be claimed that this is more intuitive than
 the 
      current proposal, which aims to make 'break' and 'continue' 
propagate 
      through block lambdas in the same way 'return' 
    would.</div></div></blockquote><br>"Intuitive" depends on intuition,
 which 
    is not well-defined. Do you mean a Rubyist might expect different 
behavior 
    for break? That is possible but JS ain't Ruby and break should not 
change to 
    do something like what it does in Ruby (and we aren't defining a 
next 
    equivalent for JS).<br><br>
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
      <div>Ruby does also support syntactic loops and the same keywords 
therein 
      and so directly violates Tennent's Correspondence Principle, even 
though 
      such has been touted as a core reason for the construct. Instead, I
 
      believe it reasonable to invoke intuition in this matter. It is 
intuitive 
      for 'return' to return a value from the lexically enclosing method
 and it 
      is intuitive for 'continue' to commence the next iteration of the 
current 
      loop,</div></div></blockquote><br>Wait, why do you think break and
 continue 
    without label operands do anything other than break from the nearest
 
    enclosing loop (or switch or labeled statement if break), or 
continue the 
    nearest enclosing loop? The proposal specifies this.<br><br><span 
style="FONT-FAMILY: monospace">function 
    find_odds_in_arrays(list,        // array 
    of arrays</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">                             
    skip)        // if found, skip 
    rest</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">{</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">  
    let a = [];</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">  for (let i = 0; i < list.length; 
    i++) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">    list[i].forEach 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">      |e|</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      if (e === 
    skip) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">        
    continue;                         
    // continue the for loop</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      if (e & 1) 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">        
    a.push(e);</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">    }</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
    }</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">  return a;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br><span><span style="FONT-FAMILY: monospace">function 
find_more_odds(list, stop) 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">  let a = [];</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">  
    for (let i = 0; i < list.length; i++) {</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">    
list[i].forEach 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">      |e|</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      if (e === 
    stop) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">        
    break;                      
    // break from the for loop</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      if (e & 1) 
    {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">        
    a.push(e);</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">    }</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
    }</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY:
 monospace">  return a;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br>
    <blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; 
BORDER-RIGHT: 0px">
      <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: 
#888888; MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
      <div>however that loop is 
    constructed.</div></div></blockquote></span><br>What do you mean by 
this? 
    The spec talks about nearest enclosing loop or relevant control 
structure in 
    the source code. Are you talking about internal loops in 
implementations 
    (dynamically dispatched at that) of methods that take block-lambdas 
as 
    arguments? I.e.<br><br><br><span style="FONT-FAMILY: monospace">function
 
    find_first_odd(a) {</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">  a.forEach { |e, i|</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">             
 
    if (e & 1) return i; }  // returns from function</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
    return -1;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br><br>The Array.prototype.forEach method's 
    internal implementation is its business, and a break instead of the 
return 
    would be a static error in this example. It would not be a dynamic 
    throw-like construct that is caught by forEach's 
    implementation.<br><br>/be<br></div>
    <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img moz-do-not-send="true" 
photoaddress="esdiscuss@grant.x43.net" photoname="Grant Husbands" 
src="cid:part7.00010809.01050404@mozilla.org" 
name="compose-unknown-contact.jpg" height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:esdiscuss@grant.x43.net" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Grant
 
    Husbands</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 7:29 
    PM</span></font></div></div></div>
    <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">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'. 
    <div> </div>
    <div>To whit: In Ruby, 'next' will end the current run (iteration) 
of the 
    block, and 'break' will (somehow) terminate the method lexically 
connected 
    with the block. It can be claimed that this is more intuitive than 
the 
    current proposal, which aims to make 'break' and 'continue' 
propagate 
    through block lambdas in the same way 'return' would.</div>
    <div> </div>
    <div>Ruby does also support syntactic loops and the same keywords 
therein 
    and so directly violates Tennent's Correspondence Principle, even 
though 
    such has been touted as a core reason for the construct. Instead, I 
believe 
    it reasonable to invoke intuition in this matter. It is intuitive 
for 
    'return' to return a value from the lexically enclosing method and 
it is 
    intuitive for 'continue' to commence the next iteration of the 
current loop, 
    however that loop is constructed.</div>
    <div> </div>
    <div>Note that the label-based break/continue could still have the 
desired 
    effect, if the proposal was updated to be more like Ruby's blocks.</div>
    <div> </div>
    <div>I don't have a strong opinion on the subject, but I hadn't 
noticed the 
    above being discussed, elsewhere, and thought it worth raising. If 
there is 
    a better place for me to raise this, please let me know where and 
accept my 
    apologies.</div>
    <div> </div>
    <div>Regards,</div>
    <div>Grant Husbands.</div>
    <div>_______________________________________________<br>es-discuss 
mailing 
    list<br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a><br><a
 moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div></blockquote></div>
  <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img photoaddress="herby@mailbox.sk" photoname="Herby Vojčík" 
src="cid:part3.03020502.06030808@mozilla.org" name="postbox-contact.jpg"
 height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:herby@mailbox.sk" style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; 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 10:42 
  AM</span></font></div></div></div>
  <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">=== David Herman wrote === <br>This
 
  *may* not violate TCP (I'm not quite sure), but I'm not enthusiastic 
about the 
  idea. The semantics is significantly more complicated, and it requires
 you to 
  understand whether a higher-order function like forEach is catching 
these 
  exceptions or not. So it becomes an additional part of the API of a 
function. 
  If someone doesn't document what they do with BreakException and 
  ContinueException, then writing callbacks you won't actually be able 
to 
  predict what `break` and `continue` will do. <br>=== <br><br>What 
about the 
  exception-less suggestion I put in? It should work in any loop 
construct with 
  lambda-block, even if you must know a little about the loop 
implementation 
  itself. That is, to be able to put: <br><br>   continue 
  |expression|; <br><br>as a statement in lambda block which instructs 
the 
  lambda-block itself (not the outer function) to return the expression?
 This is 
  the de-facto continue semantics (lambda-block, do return a value and 
the 
  enclosing loop will continue to the next iteration (possibly stopping 
the loop 
  if it chooses not to have more iterations)). It is not possible to 
enforce 
  break in the same manner, but for continue, it is possible. <br><br>Herby
 
  <br><br>-----Pôvodná správa----- From: David Herman <br>Sent: 
Saturday, 
  January 14, 2012 6:12 PM <br>To: Axel Rauschmayer <br>Cc: Brendan Eich
 ; <a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" 
class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a> <br>Subject:
 
  Re: Block Lambdas: break and continue <br><br>On Jan 13, 2012, at 9:04
 PM, 
  Axel Rauschmayer wrote: <br><br><br>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. E.g. you could implement forEach as: <br><br>   
  Array.prototype.forEach = function(f) { 
  <br>       for (let i = 0, n = this.length; i 
  < n; i++) { 
  <br>           try { 
  <br>               
  f.call(this, this[i], i); 
  <br>           } catch (e) { 
  <br>               
  if (e instanceof BreakException) 
  <br>                   
  break; 
  <br>               
  else if (e instanceof ContinueException) 
  <br>                   
  continue; 
  <br>               
  else 
  <br>                   
  throw e; <br>           } 
  <br>       } <br>   }; <br><br>Whereas 
  a function that does *not* want to expose whether it's using loops 
would 
  simply do nothing with BreakException and ContinueException, and they 
would 
  propagate out and you'd get the lexical scoping semantics. Meanwhile, 
  break/continue with an explicit target would never be catch-able. <br><br>Did
 
  I understand your suggestion correctly? <br><br>This *may* not violate
 TCP 
  (I'm not quite sure), but I'm not enthusiastic about the idea. The 
semantics 
  is significantly more complicated, and it requires you to understand 
whether a 
  higher-order function like forEach is catching these exceptions or 
not. So it 
  becomes an additional part of the API of a function. If someone 
doesn't 
  document what they do with BreakException and ContinueException, then 
writing 
  callbacks you won't actually be able to predict what `break` and 
`continue` 
  will do. <br><br>Dave <br><br>_______________________________________________
 
  <br>es-discuss mailing list <br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
 <br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
 
  <br><br></div>
  <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img photoaddress="dherman@mozilla.com" photoname="David Herman"
 src="cid:part4.06030106.07030500@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:dherman@mozilla.com" style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">David
 
Herman</a></div>
  <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; VERTICAL-ALIGN: 
middle"><font color="#9fa2a5"><span style="PADDING-LEFT: 6px">January 
14, 2012 9:12 
  AM</span></font></div></div></div>
  <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">
  <div><!----><br>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. E.g. 
  you could implement forEach as:<br><br>Array.prototype.forEach = 
function(f) 
  {<br>for (let i = 0, n = this.length; i < n; i++) {<br>try 
  {<br>f.call(this, this[i], i);<br>} catch (e) {<br>if (e instanceof 
  BreakException)<br>break;<br>else if (e instanceof 
  ContinueException)<br>continue;<br>else<br>throw 
  e;<br>}<br>}<br>};<br><br>Whereas a function that does *not* want to 
expose 
  whether it's using loops would simply do nothing with BreakException 
and 
  ContinueException, and they would propagate out and you'd get the 
lexical 
  scoping semantics. Meanwhile, break/continue with an explicit target 
would 
  never be catch-able.<br><br>Did I understand your suggestion 
  correctly?<br><br>This *may* not violate TCP (I'm not quite sure), but
 I'm not 
  enthusiastic about the idea. The semantics is significantly more 
complicated, 
  and it requires you to understand whether a higher-order function like
 forEach 
  is catching these exceptions or not. So it becomes an additional part 
of the 
  API of a function. If someone doesn't document what they do with 
  BreakException and ContinueException, then writing callbacks you won't
 
  actually be able to predict what `break` and `continue` will 
  do.<br><br>Dave<br><br><br></div></div>
  <div class="__pbConvHr" style="MARGIN: 30px 25px 10px">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img photoaddress="axel@rauschma.de" photoname="Axel 
Rauschmayer" src="cid:part5.03060001.03030500@mozilla.org" 
name="postbox-contact.jpg" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a moz-do-not-send="true" 
href="mailto:axel@rauschma.de" style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important">Axel 
  Rauschmayer</a></div>
  <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; VERTICAL-ALIGN: 
middle"><font color="#9fa2a5"><span style="PADDING-LEFT: 6px">January 
13, 2012 9:04 
  PM</span></font></div></div></div>
  <div __pbrmquotes="true" class="__pbConvBody" style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px">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 it applies to a lambda) or TCP-break (if it
 applies 
  to an enclosing non-lambda loop). In the examples below, when I see a 
  continue, I look for the innermost enclosing loop braces and the ones 
belong 
  to list[i].forEach are definitely candidates. 
  <div>
  <div> </div>
  <div> </div>
  <div> </div>
  <div apple-content-edited="true"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span class="Apple-style-span" 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: 12px helvetica;
 WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); WORD-SPACING: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space">
  <div style="MARGIN: 0px"><span class="Apple-style-span" 
style="FONT-SIZE: medium">
  <div style="MARGIN: 0px">-- </div>
  <div style="MARGIN: 0px">Dr. Axel Rauschmayer</div>
  <div style="MARGIN: 0px"><a moz-do-not-send="true" 
href="mailto:axel@rauschma.de">axel@rauschma.de</a></div>
  <div style="MARGIN: 0px"> </div>
  <div style="MARGIN: 0px">
  <div style="MARGIN: 0px">home: <a moz-do-not-send="true" 
href="http://rauschma.de">rauschma.de</a></div>twitter: <a 
moz-do-not-send="true" href="http://twitter.com/rauschma">twitter.com/rauschma</a></div>
  <div style="MARGIN: 0px">blog: <a moz-do-not-send="true" 
href="http://2ality.com">2ality.com</a></div></span></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></span></div>
  <div> </div></div></div></blockquote></div></div>
    </div>
<pre wrap="">_______________________________________________
es-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre></div>
  <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="brendan@mozilla.org" photoname="Brendan Eich" 
src="cid:part6.03040206.09050504@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:brendan@mozilla.org" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Brendan Eich</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:16 PM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="border: 0px 
none;">
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part1.05090508.05080005@mozilla.org" photoname="François REMY" 
photoaddress="fremycompany_pub@yahoo.fr" height="25px" width="25px"></div>
   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:fremycompany_pub@yahoo.fr" 
moz-do-not-send="true">François REMY</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:01 PM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div dir="ltr">
<div style="font-family: 'Segoe UI'; color: rgb(0, 0, 0); font-size: 
12pt;">
<div>If we want to avoid to break TCP, we can go with “throw break;” and
 “throw 
continue;”.</div></div></div></div>
</blockquote>
<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>
<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="border: 0px 
none;">
  <div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;">
    <div dir="ltr">
      <div style="font-family: 'Segoe UI'; color: rgb(0, 0, 0); 
font-size: 12pt;">
        <div> It would throw a new BreakException or a new 
ContinueException, from 
the place where they are executed. If it’s outside a block lambda, it’s 
outside 
a block lambda. It doesn’t matter.</div>
      </div>
    </div>
  </div>
</blockquote>
<br>
Yes, this would avoid TCP violations but not carry a return value -- 
Herby's wish.<br>
<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="border: 0px 
none;">
  <div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;">
    <div dir="ltr">
      <div style="font-family: 'Segoe UI'; color: rgb(0, 0, 0); 
font-size: 12pt;">
<div> </div>
<div>But it would set a “standard” for breaking throug ‘function loops’.</div></div>
    </div>
  </div>
</blockquote>
<br>
I considered this in drafting the block-lambda revival strawman. Other 
languages have gone here. Nevertheless, I would like to leave it out 
(remember N. Wirth on language design). It adds more complexity for a 
use-case that I bet is rare (in any case it needs credible demonstration
 of being quite common).<br>
<br>
The complexity in the semantics is one issue Dave raised. This 
corresponds to complexity for optimizing engines, compared to the purely
 static break/continue semantics in the strawman.<br>
<br>
Finally, the Array extras ship sailed. People already have to use some 
or every in lieu of a break-from-forEach. Using a function callback with
 forEach, one needs only to return to simulate continue. Now if we do 
standardize block-lambdas and throw break or throw continue, we 
certainly can elaborate the extras to catch these exceptions.<br>
<br>
Such a more complex design seems workable with the costs noted above. 
But will the benefits really outweigh those costs? I doubt it. First, 
Array forEach and other uses will continue to use functions for quite a 
while, or else a compiler from new standard JS to old. In the compiler 
case, throw and try/catch will be required, and the compiler will have 
to monkey-patch the extras to deal with the new exceptions. This will be
 a performance killer, and no fun to debug.<br>
<br>
So my thinking remains that we are better off, when in doubt, leaving 
reified break and continue exceptions "out".<br>
<br>
/be<br>
<br>
<blockquote type="cite" 
cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" style="border: 0px 
none;">
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">
    <div dir="ltr">
      <div style="FONT-FAMILY: 'Segoe UI'; COLOR: #000000; FONT-SIZE: 
12pt">
<div>François</div>
<div style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri';
 COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION:
 none">
<div style="FONT: 10pt tahoma">
<div> </div>
<div style="BACKGROUND: #f5f5f5">
<div style="font-color: black"><b>From:</b> <a 
title="brendan@mozilla.org" href="mailto:brendan@mozilla.org" 
moz-do-not-send="true">Brendan 
Eich</a> </div>
<div><b>Sent:</b> Saturday, January 14, 2012 9:51 PM</div>
<div><b>To:</b> <a title="herby@mailbox.sk" 
href="mailto:herby@mailbox.sk" moz-do-not-send="true">Herby 
Vojčík</a> </div>
<div><b>Cc:</b> <a title="es-discuss@mozilla.org" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a>
 </div>
<div><b>Subject:</b> Re: Block Lambdas: break and continue</div></div></div>
<div> </div></div>
<div style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri';
 COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION:
 none">
<blockquote style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" type="cite"><div 
style="MARGIN: 30px 25px 10px" class="__pbConvHr">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part3.03020502.06030808@mozilla.org" photoname="Herby Vojčík" 
photoaddress="herby@mailbox.sk" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important" 
href="mailto:herby@mailbox.sk" moz-do-not-send="true">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 10:42 
  AM</span></font></div></div></div>
  <div style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" 
class="__pbConvBody" __pbrmquotes="true">=== David 
Herman wrote === <br>This 
  *may* not violate TCP (I'm not quite sure), but I'm not enthusiastic 
about the 
  idea. The semantics is significantly more complicated, and it requires
 you to 
  understand whether a higher-order function like forEach is catching 
these 
  exceptions or not. So it becomes an additional part of the API of a 
function. 
  If someone doesn't document what they do with BreakException and 
  ContinueException, then writing callbacks you won't actually be able 
to 
  predict what `break` and `continue` will do. <br>=== <br><br>What 
about the 
  exception-less suggestion I put in? It should work in any loop 
construct with 
  lambda-block, even if you must know a little about the loop 
implementation 
  itself. That is, to be able to put: <br><br>   continue 
  |expression|; <br></div></blockquote><br>Who says the block-lambda is 
being 
called from a loop at all? Why should use-cases that want an early 
result and 
completion have to use continue, which is for loops?<br><br>Worse, this 
violates 
TCP. Now you copy and paste this block-lambda code back into a block 
statement 
to refactor the other direction, and no such "here is the completion 
value, do 
not flow past this point in the block" semantics obtain.<br>
<blockquote style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" type="cite"><div 
style="COLOR: rgb(136,136,136);
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true"><br>as a statement in lambda 
block 
  which instructs the lambda-block itself (not the outer function) to 
return the 
  expression? This is the de-facto continue semantics (lambda-block, do 
return a 
  value and the enclosing loop will continue to the next iteration 
(possibly 
  stopping the loop if it chooses not to have more 
iterations)).</div></blockquote><br>No it's not. There is no de-facto 
continue 
semantics for block-lambdas because they haven't been prototyped. For 
block 
statements, no such continue semantics exists.<br><br>
<blockquote style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" type="cite"><div 
style="COLOR: rgb(136,136,136);
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true">It is not possible to enforce 
break in 
  the same manner, but for continue, it is possible. 
<br></div></blockquote><br>It's possible to abuse any existing keyword, 
but 
first: why must there be a new TCP violation? Block-lambda bodies are 
often 
expressions, or if statements, then short/functional-style statements, 
not large 
bodies demonstrating early-normal-completion opportunities.<br><br>We 
should not 
eliminate TCP violations only to add new ones, especially without any 
evidence 
they're needed and pay their way. Otherwise we'll get an infinite 
regress of 
TCP-pure-then-add-new-exceptions-and-repeat additions.<br><br>/be<br>
<blockquote style="BORDER-BOTTOM:
 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" type="cite"><div 
style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true"><br>Herby <br><br>-----Pôvodná 
  správa----- From: David Herman <br>Sent: Saturday, January 14, 2012 
6:12 PM 
  <br>To: Axel Rauschmayer <br>Cc: Brendan Eich ; <a 
class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org" 
moz-do-not-send="true">es-discuss@mozilla.org</a> <br>Subject:
 
  Re: Block Lambdas: break and continue <br><br>On Jan 13, 2012, at 9:04
 PM, 
  Axel Rauschmayer wrote: <br><br><br>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. E.g. you could implement forEach as: <br><br>   
  Array.prototype.forEach = function(f) { 
  <br>       for (let i = 0, n = this.length; i 
  < n; i++) { 
  <br>           try { 
  <br>               
  f.call(this, this[i], i); 
  <br>           } catch (e) { 
  <br>               
  if (e instanceof BreakException) 
  <br>                   
  break; 
  <br>               
  else if (e instanceof ContinueException) 
  <br>                   
  continue; 
  <br>               
  else 
  <br>                   
  throw e; <br>           } 
  <br>       } <br>   }; <br><br>Whereas 
  a function that does *not* want to expose whether it's using loops 
would 
  simply do nothing with BreakException and ContinueException, and they 
would 
  propagate out and you'd get the lexical scoping semantics. Meanwhile, 
  break/continue with an explicit target would never be catch-able. <br><br>Did

 
  I understand your suggestion correctly? <br><br>This *may* not violate
 TCP 
  (I'm not quite sure), but I'm not enthusiastic about the idea. The 
semantics 
  is significantly more complicated, and it requires you to understand 
whether a 
  higher-order function like forEach is catching these exceptions or 
not. So it 
  becomes an additional part of the API of a function. If someone 
doesn't 
  document what they do with BreakException and ContinueException, then 
writing 
  callbacks you won't actually be able to predict what `break` and 
`continue` 
  will do. <br><br>Dave <br><br>_______________________________________________

 
  <br>es-discuss mailing list <br><a class="moz-txt-link-abbreviated" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a>
 <br><a class="moz-txt-link-freetext" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
moz-do-not-send="true">https://mail.mozilla.org/listinfo/es-discuss</a>
 
  <br>_______________________________________________ <br>es-discuss 
mailing 
  list <br><a class="moz-txt-link-abbreviated" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a>
 <br><a class="moz-txt-link-freetext" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
moz-do-not-send="true">https://mail.mozilla.org/listinfo/es-discuss</a>
 
  <br></div>
  <div style="MARGIN: 30px 25px 10px" class="__pbConvHr">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part4.06030106.07030500@mozilla.org" photoname="David Herman" 
photoaddress="dherman@mozilla.com" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important"
 href="mailto:dherman@mozilla.com" moz-do-not-send="true">David
 
Herman</a></div>
  <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; VERTICAL-ALIGN: 
middle"><font color="#9fa2a5"><span style="PADDING-LEFT: 6px">January 
14, 2012 9:12 
  AM</span></font></div></div></div>
  <div style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true">
  <div><!----><br>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. E.g. 
  you could implement forEach as:<br><br>Array.prototype.forEach = 
function(f) 
  {<br>for (let i = 0, n = this.length; i < n; i++) {<br>try 
  {<br>f.call(this, this[i], i);<br>} catch (e) {<br>if (e instanceof 
  BreakException)<br>break;<br>else if (e instanceof 
  ContinueException)<br>continue;<br>else<br>throw 
  e;<br>}<br>}<br>};<br><br>Whereas a function that does *not* want to 
expose 
  whether it's using loops would simply do nothing with BreakException 
and 
  ContinueException, and they would propagate out and you'd get the 
lexical 
  scoping semantics. Meanwhile, break/continue with an explicit target 
would 
  never be catch-able.<br><br>Did I understand your suggestion 
  correctly?<br><br>This *may* not violate TCP (I'm not quite sure), but
 I'm not 
  enthusiastic about the idea. The semantics is significantly more 
complicated, 
  and it requires you to understand whether a higher-order function like
 forEach 
  is catching these exceptions or not. So it becomes an additional part 
of the 
  API of a function. If someone doesn't document what they do with 
  BreakException and ContinueException, then writing callbacks you won't
 
  actually be able to predict what `break` and `continue` will 
  do.<br><br>Dave<br><br><br></div></div>
  <div style="MARGIN: 30px 25px 10px" class="__pbConvHr">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part5.03060001.03030500@mozilla.org" photoname="Axel 
Rauschmayer" photoaddress="axel@rauschma.de" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a style="PADDING-RIGHT: 6px; COLOR: #737f92
 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important" 
href="mailto:axel@rauschma.de" moz-do-not-send="true">Axel 
  Rauschmayer</a></div>
  <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; VERTICAL-ALIGN: 
middle"><font color="#9fa2a5"><span style="PADDING-LEFT: 6px">January 
13, 2012 9:04 
  PM</span></font></div></div></div>
  <div style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true">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 it applies to a lambda) or TCP-break (if it
 applies 
  to an enclosing non-lambda loop). In the examples below, when I see a 
  continue, I look for the innermost enclosing loop braces and the ones 
belong 
  to list[i].forEach are definitely candidates. 
  <div>
  <div> </div>
  <div> </div>
  <div> </div>
  <div apple-content-edited="true"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span"><span 
style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: medium 
helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); 
WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space"><span style="WIDOWS: 2; 
TEXT-TRANSFORM: none; TEXT-INDENT: 0px; 
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT: 12px helvetica;
 WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); WORD-SPACING: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto" class="Apple-style-span">
  <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space">
  <div style="MARGIN: 0px"><span style="FONT-SIZE: medium" 
class="Apple-style-span">
  <div style="MARGIN: 0px">-- </div>
  <div style="MARGIN: 0px">Dr. Axel Rauschmayer</div>
  <div style="MARGIN: 0px"><a href="mailto:axel@rauschma.de" 
moz-do-not-send="true">axel@rauschma.de</a></div>
  <div style="MARGIN: 0px"> </div>
  <div style="MARGIN: 0px">
  <div style="MARGIN: 0px">home: <a href="http://rauschma.de" 
moz-do-not-send="true">rauschma.de</a></div>twitter: <a 
href="http://twitter.com/rauschma" moz-do-not-send="true">twitter.com/rauschma</a></div>
  <div style="MARGIN: 0px">blog: <a href="http://2ality.com" 
moz-do-not-send="true">2ality.com</a></div></span></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></span></div>
  <div> </div></div></div>
  <div style="MARGIN: 30px 25px 10px" class="__pbConvHr">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part6.03040206.09050504@mozilla.org" photoname="Brendan Eich" 
photoaddress="brendan@mozilla.org" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important"
 href="mailto:brendan@mozilla.org" moz-do-not-send="true">Brendan
 
Eich</a></div>
  <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; VERTICAL-ALIGN: 
middle"><font color="#9fa2a5"><span style="PADDING-LEFT: 6px">January 
13, 2012 8:54 
  PM</span></font></div></div></div>
  <div style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true">
  <blockquote style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 
0px; 
BORDER-RIGHT: 0px" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 type="cite">
    <div style="MARGIN: 30px 25px 10px" class="__pbConvHr">
    <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
    <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN:
 middle"><img name="compose-unknown-contact.jpg" 
src="cid:part7.00010809.01050404@mozilla.org" photoname="Grant Husbands"
 photoaddress="esdiscuss@grant.x43.net" moz-do-not-send="true" 
height="25" width="25"></div>
    <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important"
 href="mailto:esdiscuss@grant.x43.net" moz-do-not-send="true">Grant
 
    Husbands</a></div>
    <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><font color="#9fa2a5"><span style="PADDING-LEFT:
 6px">January 13, 2012 7:29 
    PM</span></font></div></div></div>
    <div style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" 
class="__pbConvBody" __pbrmquotes="true">Block lambdas 
have been a hot topic, 
    recently, but there's a point of significant divergence between Ruby
 (which 
    appears to be the inspiration)</div></blockquote><br>Not Ruby alone,
 and not 
  in any chauvinist my-language-is-better sense. Smalltalk is the 
original 
  inspiration for Ruby blocks, and the correspondence principle has deep
 
  roots.<br><br>
  <blockquote style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 
0px; 
BORDER-RIGHT: 0px" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 type="cite">
    <div style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" 
class="__pbConvBody" __pbrmquotes="true">and the 
proposed solution, in the 
    handling of continue (called 'next', in Ruby) and 'break'. 
    <div> </div>
    <div>To whit: In Ruby, 'next' will end the current run (iteration) 
of the 
    block, and 'break' will (somehow) terminate the method lexically 
connected 
    with the block. It can be claimed that this is more intuitive than 
the 
    current proposal, which aims to make 'break' and 'continue' 
propagate 
    through block lambdas in the same way 'return' 
  would.</div></div></blockquote><br>"Intuitive" depends on intuition, 
which is 
  not well-defined. Do you mean a Rubyist might expect different 
behavior for 
  break? That is possible but JS ain't Ruby and break should not change 
to do 
  something like what it does in Ruby (and we aren't defining a next 
equivalent 
  for JS).<br><br>
  <blockquote style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 
0px; 
BORDER-RIGHT: 0px" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 type="cite">
    <div style="COLOR: 
rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" 
class="__pbConvBody" __pbrmquotes="true">
    <div>Ruby does also support syntactic loops and the same keywords 
therein 
    and so directly violates Tennent's Correspondence Principle, even 
though 
    such has been touted as a core reason for the construct. Instead, I 
believe 
    it reasonable to invoke intuition in this matter. It is intuitive 
for 
    'return' to return a value from the lexically enclosing method and 
it is 
    intuitive for 'continue' to commence the next iteration of the 
current 
    loop,</div></div></blockquote><br>Wait, why do you think break and 
continue 
  without label operands do anything other than break from the nearest 
enclosing 
  loop (or switch or labeled statement if break), or continue the 
nearest 
  enclosing loop? The proposal specifies this.<br><br><span 
style="FONT-FAMILY: monospace">function 
  find_odds_in_arrays(list,        // array 
  of arrays</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">                             
  skip)        // if found, skip 
  rest</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">{</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">  let 
  a = [];</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">  for (let i = 0; i < list.length; 
i++) 
  {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">    list[i].forEach {</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      |e|</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">     

 if (e === skip) 
  {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">        
  continue;                         
  // continue the for loop</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      if (e & 1) 
  {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">        
  a.push(e);</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">    }</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
  }</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">  return a;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br><span><span style="FONT-FAMILY: monospace">function 
find_more_odds(list, stop) {</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">  let 
  a = [];</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">  for (let i = 0; i < list.length; 
i++) 
  {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">    list[i].forEach {</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      |e|</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">     

 if (e === stop) 
  {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">        
  break;                      
  // break from the for loop</span><br style="FONT-FAMILY: monospace"><span
 style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">      if (e & 1) 
  {</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">        
  a.push(e);</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">      }</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">    }</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
  }</span><br style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: 
monospace">  return a;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br>
  <blockquote style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 
0px; 
BORDER-RIGHT: 0px" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 type="cite">
    <div style="COLOR: #888888;
 MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true">
    <div>however that loop is constructed.</div></div></blockquote></span><br>What

 
  do you mean by this? The spec talks about nearest enclosing loop or 
relevant 
  control structure in the source code. Are you talking about internal 
loops in 
  implementations (dynamically dispatched at that) of methods that take 
  block-lambdas as arguments? I.e.<br><br><br><span style="FONT-FAMILY: 
monospace">function find_first_odd(a) {</span><br style="FONT-FAMILY: 
monospace"><span style="FONT-FAMILY: monospace">  
  a.forEach { |e, i|</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">              
  if (e & 1) return i; }  // returns from function</span><br 
style="FONT-FAMILY: monospace"><span style="FONT-FAMILY: monospace">  
  return -1;</span><br style="FONT-FAMILY: monospace"><span 
style="FONT-FAMILY: monospace">}</span><br style="FONT-FAMILY: 
monospace"><br><br>The Array.prototype.forEach method's 
  internal implementation is its business, and a break instead of the 
return 
  would be a static error in this example. It would not be a dynamic 
throw-like 
  construct that is caught by forEach's implementation.<br><br>/be<br></div>
  <div style="MARGIN: 30px 25px 10px" class="__pbConvHr">
  <div style="WIDTH: 100%; DISPLAY: table; BORDER-TOP: #edeef0 1px 
solid; PADDING-TOP: 5px">
  <div style="PADDING-RIGHT: 6px; DISPLAY: table-cell; VERTICAL-ALIGN: 
middle"><img moz-do-not-send="true" name="compose-unknown-contact.jpg" 
src="cid:part7.00010809.01050404@mozilla.org" photoname="Grant 
Husbands" photoaddress="esdiscuss@grant.x43.net" height="25" width="25"></div>
  <div style="WIDTH: 100%; DISPLAY: table-cell; WHITE-SPACE: nowrap; 
VERTICAL-ALIGN: middle"><a style="PADDING-RIGHT: 6px; COLOR: 
#737f92 !important; FONT-WEIGHT: bold; TEXT-DECORATION: none !important"
 href="mailto:esdiscuss@grant.x43.net" moz-do-not-send="true">Grant
 
  Husbands</a></div>
  <div style="DISPLAY: table-cell; WHITE-SPACE: nowrap; VERTICAL-ALIGN: 
middle"><font color="#9fa2a5"><span style="PADDING-LEFT: 6px">January 
13, 2012 7:29 
  PM</span></font></div></div></div>
  <div style="COLOR: #888888; 
MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" 
__pbrmquotes="true">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'. 
  <div> </div>
  <div>To whit: In Ruby, 'next' will end the current run (iteration) of 
the 
  block, and 'break' will (somehow) terminate the method lexically 
connected 
  with the block. It can be claimed that this is more intuitive than the
 current 
  proposal, which aims to make 'break' and 'continue' propagate through 
block 
  lambdas in the same way 'return' would.</div>
  <div> </div>
  <div>Ruby does also support syntactic loops and the same keywords 
therein and 
  so directly violates Tennent's Correspondence Principle, even though 
such has 
  been touted as a core reason for the construct. Instead, I believe it 
  reasonable to invoke intuition in this matter. It is intuitive for 
'return' to 
  return a value from the lexically enclosing method and it is intuitive
 for 
  'continue' to commence the next iteration of the current loop, however
 that 
  loop is constructed.</div>
  <div> </div>
  <div>Note that the label-based break/continue could still have the 
desired 
  effect, if the proposal was updated to be more like Ruby's blocks.</div>
  <div> </div>
  <div>I don't have a strong opinion on the subject, but I hadn't 
noticed the 
  above being discussed, elsewhere, and thought it worth raising. If 
there is a 
  better place for me to raise this, please let me know where and accept
 my 
  apologies.</div>
  <div> </div>
  <div>Regards,</div>
  <div>Grant Husbands.</div>
  <div>_______________________________________________<br>es-discuss 
mailing 
  list<br><a class="moz-txt-link-abbreviated" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a><br><a
 class="moz-txt-link-freetext" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
moz-do-not-send="true">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div></blockquote>
<p>
</p><hr>
_______________________________________________<br>es-discuss mailing 
list<br><a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" 
class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a><br><a 
moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div>
    </div>
<pre wrap="">_______________________________________________
es-discuss mailing list
<a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
<a moz-do-not-send="true" href="https://mail.mozilla.org/listinfo/es-discuss" class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre></div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part6.03040206.09050504@mozilla.org" photoname="Brendan Eich" 
photoaddress="brendan@mozilla.org" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:brendan@mozilla.org" moz-do-not-send="true">Brendan
 Eich</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 14, 2012 
12:51 PM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

<blockquote style="border: 0px 
none;" cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@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:part3.03020502.06030808@mozilla.org" name="postbox-contact.jpg"
 moz-do-not-send="true" 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 
10:42 AM</span></font></div></div></div>
  <div style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">=== David 
Herman wrote ===
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>===
<br>
<br>What about the exception-less suggestion I put in? It should work in
 any 
loop construct with lambda-block, even if you must know a little about 
the 
loop implementation itself. That is, to be able to put:
<br>
<br>   continue |expression|;
<br></div>
</blockquote>
<br>
Who says the block-lambda is being called from a loop at all? Why should
 use-cases that want an early result and completion have to use 
continue, which is for loops?<br>
<br>
Worse, this violates TCP. Now you copy and paste this block-lambda code 
back into a block statement to refactor the other direction, and no such
 "here is the completion value, do not flow past this point in the 
block" semantics obtain.<br>
<blockquote style="border: 0px 
none;" cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" type="cite">
  <div style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<br>as a statement in lambda block which instructs the lambda-block 
itself (not 
the outer function) to return the expression? This is the de-facto 
continue 
semantics (lambda-block, do return a value and the enclosing loop will 
continue to the next iteration (possibly stopping the loop if it chooses
 not 
to have more iterations)).</div>
</blockquote>
<br>
No it's not. There is no de-facto continue semantics for block-lambdas 
because they haven't been prototyped. For block statements, no such 
continue semantics exists.<br>
<br>
<blockquote style="border: 0px 
none;" cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" type="cite">
  <div style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">It is not 
possible to enforce break in the same 
manner, but for continue, it is possible.
<br></div></blockquote>
<br>
It's possible to abuse any existing keyword, but first: why must there 
be a new TCP violation? Block-lambda bodies are often expressions, or if
 statements, then short/functional-style statements, not large bodies 
demonstrating early-normal-completion opportunities.<br>
<br>
We should not eliminate TCP violations only to add new ones, especially 
without any evidence they're needed and pay their way. Otherwise we'll 
get an infinite regress of TCP-pure-then-add-new-exceptions-and-repeat 
additions.<br>
<br>
/be<br>
<blockquote style="border: 0px 
none;" cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" type="cite">
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
<br>Herby
<br>
<br>-----Pôvodná správa----- 
From: David Herman
<br>Sent: Saturday, January 14, 2012 6:12 PM
<br>To: Axel Rauschmayer
<br>Cc: Brendan Eich ; <a class="moz-txt-link-abbreviated" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a>
<br>Subject: Re: Block Lambdas: break and continue
<br>
<br>On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
<br>
<br>
<br>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. E.g. you could 
implement 
forEach as:
<br>
<br>   Array.prototype.forEach = function(f) {
<br>       for (let i = 0, n = this.length; i < n; i++) {
<br>           try {
<br>               f.call(this, this[i], i);
<br>           } catch (e) {
<br>               if (e instanceof BreakException)
<br>                   break;
<br>               else if (e instanceof ContinueException)
<br>                   continue;
<br>               else
<br>                   throw e;
<br>           }
<br>       }
<br>   };
<br>
<br>Whereas a function that does *not* want to expose whether it's using
 loops 
would simply do nothing with BreakException and ContinueException, and 
they 
would propagate out and you'd get the lexical scoping semantics. 
Meanwhile, 
break/continue with an explicit target would never be catch-able.
<br>
<br>Did I understand your suggestion correctly?
<br>
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>
<br>Dave
<br>
<br>_______________________________________________
<br>es-discuss mailing list
<br><a class="moz-txt-link-abbreviated" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a>
<br><a class="moz-txt-link-freetext" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
moz-do-not-send="true">https://mail.mozilla.org/listinfo/es-discuss</a>
 

<br>_______________________________________________
<br>es-discuss mailing list
<br><a class="moz-txt-link-abbreviated" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a>
<br><a class="moz-txt-link-freetext" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
moz-do-not-send="true">https://mail.mozilla.org/listinfo/es-discuss</a>
<br></div>
  <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="dherman@mozilla.com" photoname="David Herman" 
src="cid:part4.06030106.07030500@mozilla.org" name="postbox-contact.jpg"
 moz-do-not-send="true" 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:dherman@mozilla.com" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">David
 Herman</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 14, 2012 
9:12 AM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody"><div><!----><br>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. E.g. you could 
implement forEach as:<br><br>    Array.prototype.forEach = function(f) {<br>
        for (let i = 0, n = this.length; i < n; i++) {<br>           
 try {<br>                f.call(this, this[i], i);<br>            } 
catch (e) {<br>                if (e instanceof BreakException)<br>     
               break;<br>                else if (e instanceof 
ContinueException)<br>                    continue;<br>                
else<br>                    throw e;<br>            }<br>        }<br>  
  };<br><br>Whereas a function that does *not* want to expose whether 
it's using loops would simply do nothing with BreakException and 
ContinueException, and they would propagate out and you'd get the 
lexical scoping semantics. Meanwhile, break/continue with an explicit 
target would never be catch-able.<br><br>Did I understand your 
suggestion correctly?<br><br>This *may* not violate TCP (I'm not quite 
sure), but I'm not enthusiastic about the idea. The semantics is 
significantly more complicated, and it requires you to understand 
whether a higher-order function like forEach is catching these 
exceptions or not. So it becomes an additional part of the API of a 
function. If someone doesn't document what they do with BreakException 
and ContinueException, then writing callbacks you won't actually be able
 to predict what `break` and `continue` will do.<br><br>Dave<br><br><br></div></div>
  <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="axel@rauschma.de" photoname="Axel 
Rauschmayer" src="cid:part5.03060001.03030500@mozilla.org" 
name="postbox-contact.jpg" moz-do-not-send="true" 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:axel@rauschma.de" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Axel 
Rauschmayer</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
9:04 PM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">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 it applies
 to a lambda) or TCP-break (if it applies to an enclosing non-lambda 
loop). In the examples below, when I see a continue, I look for the 
innermost enclosing loop braces and the ones belong to list[i].forEach 
are definitely candidates.<div><br><div><br 
class="Apple-interchange-newline"></div><br><div 
apple-content-edited="true">
<span style="border-collapse: separate; color: 
rgb(0, 0, 0); 
font-family: Helvetica; font-style: normal; font-variant: normal; 
font-weight: normal; letter-spacing: normal; line-height: normal; 
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: 
none; white-space: normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><span 
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 
Helvetica; font-style: normal; font-variant: normal; font-weight: 
normal; letter-spacing: normal; line-height: normal; orphans: 2; 
text-align: -webkit-auto; text-indent: 0px; text-transform: none; 
white-space: normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; " class="Apple-style-span"><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: 
normal; font-variant: normal; font-weight: normal; letter-spacing: 
normal; line-height: normal; orphans: 2; text-indent: 0px; 
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;
 -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px; " class="Apple-style-span"><div 
style="word-wrap: 
break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space; "><span style="border-collapse: 
separate; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: 
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; 
font-weight: normal; letter-spacing: normal; line-height: normal; 
-webkit-text-decorations-in-effect: none; text-indent: 0px; 
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; 
white-space: normal; widows: 2; word-spacing: 0px; " 
class="Apple-style-span"><div style="word-wrap: break-word; 
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div 
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; "><span style="font-size: 
medium; " class="Apple-style-span"><div style="margin-top: 0px; 
margin-right: 0px;
 margin-bottom: 0px; margin-left: 0px; ">-- </div><div 
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; ">Dr. Axel Rauschmayer</div><div style="margin-top: 
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a 
moz-do-not-send="true" href="mailto:axel@rauschma.de">axel@rauschma.de</a></div><div
 style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; "><br></div><div style="margin-top: 0px; margin-right:
 0px; margin-bottom: 0px; margin-left: 0px; "><div style="margin-top: 
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">home: <a
 moz-do-not-send="true" href="http://rauschma.de">rauschma.de</a></div>twitter:


 <a moz-do-not-send="true" href="http://twitter.com/rauschma">twitter.com/rauschma</a></div><div
 style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; ">blog: <a moz-do-not-send="true" 
href="http://2ality.com">2ality.com</a></div></span></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></span>
</div>
<br></div></div>
  <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="brendan@mozilla.org" photoname="Brendan Eich" 
src="cid:part6.03040206.09050504@mozilla.org" name="postbox-contact.jpg"
 moz-do-not-send="true" 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:brendan@mozilla.org" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Brendan
 Eich</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
8:54 PM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="border: 0px none;"><div class="__pbConvHr" style="margin:30px 
25px 10px 25px;"><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
 moz-do-not-send="true" name="compose-unknown-contact.jpg" 
src="cid:part7.00010809.01050404@mozilla.org" photoname="Grant Husbands"
 photoaddress="esdiscuss@grant.x43.net" height="25px" width="25px"></div>
   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:esdiscuss@grant.x43.net" 
moz-do-not-send="true">Grant Husbands</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
7:29 PM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;">Block 
lambdas have been a hot topic, recently, but there's a point of 
significant divergence between Ruby (which appears to be the 
inspiration)</div></blockquote>
<br>
Not Ruby alone, and not in any chauvinist my-language-is-better sense. 
Smalltalk is the original inspiration for Ruby blocks, and the 
correspondence principle has deep roots.<br>
<br>
<blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="border: 0px none;"><div class="__pbConvBody" __pbrmquotes="true"
 style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;"> and the 
proposed solution, in the handling of continue (called 'next', in Ruby) 
and 'break'.<div>
<br></div><div>To whit: In Ruby, 'next' will end the current run 
(iteration) of the block, and 'break' will (somehow) terminate the 
method lexically connected with the block. It can be claimed that this 
is more intuitive than the current proposal, which aims to make 'break' 
and 'continue' propagate through block lambdas in the same way 'return' 
would.</div></div></blockquote>
<br>
"Intuitive" depends on intuition, which is not well-defined. Do you mean
 a Rubyist might expect different behavior for break? That is possible 
but JS ain't Ruby and break should not change to do something like what 
it does in Ruby (and we aren't defining a next equivalent for JS).<br>
<br>
<blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="border: 0px none;"><div class="__pbConvBody" __pbrmquotes="true"
 style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;">
<div>Ruby does also support syntactic loops and the same keywords 
therein and so directly violates Tennent's Correspondence Principle, 
even though such has been touted as a core reason for the construct. 
Instead, I believe it reasonable to invoke intuition in this matter. It 
is intuitive for 'return' to return a value from the lexically enclosing
 method and it is intuitive for 'continue' to commence the next 
iteration of the current loop,</div></div></blockquote>
<br>
Wait, why do you think break and continue without label operands do 
anything other than break from the nearest enclosing loop (or switch or 
labeled statement if break), or continue the nearest enclosing loop? The
 proposal specifies this.<br>
<br>
<span style="font-family: monospace;">function 
find_odds_in_arrays(list,        // array of arrays</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">                             
skip)        // if found, skip rest</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">{</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">  let a = [];</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">  for (let i = 0; i < 
list.length; i++) {</span><br style="font-family: monospace;">
<span style="font-family: monospace;">    list[i].forEach {</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      |e|</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      if (e === skip) {</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">        
continue;                         // continue the for loop</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      if (e & 1) {</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">        a.push(e);</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">    }</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">  }</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">  return a;</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">}</span><br style="font-family: 
monospace;">
<br>
<span><span style="font-family: monospace;">function 
find_more_odds(list, stop) {</span><br style="font-family: monospace;">
  <span style="font-family: monospace;">  let a = [];</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">  for (let i = 0; i < 
list.length; i++) {</span><br style="font-family: monospace;">
  <span style="font-family: monospace;">    list[i].forEach {</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      |e|</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      if (e === stop) {</span><br
 style="font-family: monospace;">
  <span style="font-family: monospace;">        
break;                      // break from the for loop</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      if (e & 1) {</span><br
 style="font-family: monospace;">
  <span style="font-family: monospace;">        a.push(e);</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">    }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">  }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">  return a;</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">}</span><br style="font-family: 
monospace;">
<br>
<blockquote type="cite" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 style="border: 0px none;"><div class="__pbConvBody" __pbrmquotes="true"
 style="color:#888888;margin-left:24px;margin-right:24px;">
    <div>however that loop is constructed.</div>
  </div></blockquote></span><br>
What do you mean by this? The spec talks about nearest enclosing loop or
 relevant control structure in the source code. Are you talking about 
internal loops in implementations (dynamically dispatched at that) of 
methods that take block-lambdas as arguments? I.e.<br>
<br>
<br>
<span style="font-family: monospace;">function find_first_odd(a) {</span><br
 style="font-family: monospace;">
<span style="font-family: monospace;">  a.forEach { |e, i|</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">              if (e & 1) 
return i; }  // returns from function</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">  return -1;</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">}</span><br style="font-family: 
monospace;">
<br>
<br>
The Array.prototype.forEach method's internal implementation is its 
business, and a break instead of the return would be a static error in 
this example. It would not be a dynamic throw-like construct that is 
caught by forEach's implementation.<br>
<br>
/be<br>
  </div>
  <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="esdiscuss@grant.x43.net" photoname="Grant Husbands" 
src="cid:part7.00010809.01050404@mozilla.org" 
name="compose-unknown-contact.jpg" moz-do-not-send="true" 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:esdiscuss@grant.x43.net" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Grant Husbands</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
7:29 PM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">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'.<div>
<br></div><div>To whit: In Ruby, 'next' will end the current run 
(iteration) of the block, and 'break' will (somehow) terminate the 
method lexically connected with the block. It can be claimed that this 
is more intuitive than the current proposal, which aims to make 'break' 
and 'continue' propagate through block lambdas in the same way 'return' 
would.</div>
<div><br></div><div>Ruby does also support syntactic loops and the same 
keywords therein and so directly violates Tennent's Correspondence 
Principle, even though such has been touted as a core reason for the 
construct. Instead, I believe it reasonable to invoke intuition in this 
matter. It is intuitive for 'return' to return a value from the 
lexically enclosing method and it is intuitive for 'continue' to 
commence the next iteration of the current loop, however that loop is 
constructed.</div>
<div><br></div><div>Note that the label-based break/continue could still
 have the desired effect, if the proposal was updated to be more like 
Ruby's blocks.</div><div><br></div><div>I don't have a strong opinion on
 the subject, but I hadn't noticed the above being discussed, elsewhere,
 and thought it worth raising. If there is a better place for me to 
raise this, please let me know where and accept my apologies.</div>
<div><br></div><div>Regards,</div><div>Grant Husbands.</div>

<div>_______________________________________________<br>es-discuss 
mailing list<br><a class="moz-txt-link-abbreviated" 
href="mailto:es-discuss@mozilla.org" moz-do-not-send="true">es-discuss@mozilla.org</a><br><a
 class="moz-txt-link-freetext" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
moz-do-not-send="true">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div></blockquote>
  </div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part3.03020502.06030808@mozilla.org" photoname="Herby Vojčík" 
photoaddress="herby@mailbox.sk" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:herby@mailbox.sk" moz-do-not-send="true">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 
10:42 AM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">=== David 
Herman wrote ===
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>===
<br>
<br>What about the exception-less suggestion I put in? It should work in
 any 
loop construct with lambda-block, even if you must know a little about 
the 
loop implementation itself. That is, to be able to put:
<br>
<br>   continue |expression|;
<br>
<br>as a statement in lambda block which instructs the lambda-block 
itself (not 
the outer function) to return the expression? This is the de-facto 
continue 
semantics (lambda-block, do return a value and the enclosing loop will 
continue to the next iteration (possibly stopping the loop if it chooses
 not 
to have more iterations)). It is not possible to enforce break in the 
same 
manner, but for continue, it is possible.
<br>
<br>Herby
<br>
<br>-----Pôvodná správa----- 
From: David Herman
<br>Sent: Saturday, January 14, 2012 6:12 PM
<br>To: Axel Rauschmayer
<br>Cc: Brendan Eich ; <a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
<br>Subject: Re: Block Lambdas: break and continue
<br>
<br>On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
<br>
<br>
<br>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. E.g. you could 
implement 
forEach as:
<br>
<br>   Array.prototype.forEach = function(f) {
<br>       for (let i = 0, n = this.length; i < n; i++) {
<br>           try {
<br>               f.call(this, this[i], i);
<br>           } catch (e) {
<br>               if (e instanceof BreakException)
<br>                   break;
<br>               else if (e instanceof ContinueException)
<br>                   continue;
<br>               else
<br>                   throw e;
<br>           }
<br>       }
<br>   };
<br>
<br>Whereas a function that does *not* want to expose whether it's using
 loops 
would simply do nothing with BreakException and ContinueException, and 
they 
would propagate out and you'd get the lexical scoping semantics. 
Meanwhile, 
break/continue with an explicit target would never be catch-able.
<br>
<br>Did I understand your suggestion correctly?
<br>
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>
<br>Dave
<br>
<br>_______________________________________________
<br>es-discuss mailing list
<br><a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" 
class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
<br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
 

<br>
<br></div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part4.06030106.07030500@mozilla.org" photoname="David Herman" 
photoaddress="dherman@mozilla.com" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:dherman@mozilla.com" moz-do-not-send="true">David
 Herman</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 14, 2012 
9:12 AM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;"><div><!----><br>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. E.g. you could 
implement forEach as:<br><br>    Array.prototype.forEach = function(f) {<br>
        for (let i = 0, n = this.length; i < n; i++) {<br>           
 try {<br>                f.call(this, this[i], i);<br>            } 
catch (e) {<br>                if (e instanceof BreakException)<br>     
               break;<br>                else if (e instanceof 
ContinueException)<br>                    continue;<br>                
else<br>                    throw e;<br>            }<br>        }<br>  
  };<br><br>Whereas a function that does *not* want to expose whether 
it's using loops would simply do nothing with BreakException and 
ContinueException, and they would propagate out and you'd get the 
lexical scoping semantics. Meanwhile, break/continue with an explicit 
target would never be catch-able.<br><br>Did I understand your 
suggestion correctly?<br><br>This *may* not violate TCP (I'm not quite 
sure), but I'm not enthusiastic about the idea. The semantics is 
significantly more complicated, and it requires you to understand 
whether a higher-order function like forEach is catching these 
exceptions or not. So it becomes an additional part of the API of a 
function. If someone doesn't document what they do with BreakException 
and ContinueException, then writing callbacks you won't actually be able
 to predict what `break` and `continue` will do.<br><br>Dave<br><br><br></div></div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part5.03060001.03030500@mozilla.org" photoname="Axel 
Rauschmayer" photoaddress="axel@rauschma.de" height="25px" width="25px"></div>
   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:axel@rauschma.de" moz-do-not-send="true">Axel 
Rauschmayer</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
9:04 PM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">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 it applies
 to a lambda) or TCP-break (if it applies to an enclosing non-lambda 
loop). In the examples below, when I see a continue, I look for the 
innermost enclosing loop braces and the ones belong to list[i].forEach 
are definitely candidates.<div><br><div><br 
class="Apple-interchange-newline"></div><br><div 
apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: 
rgb(0, 0, 0); 
font-family: Helvetica; font-style: normal; font-variant: normal; 
font-weight: normal; letter-spacing: normal; line-height: normal; 
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: 
none; white-space: normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><span class="Apple-style-span" 
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 
Helvetica; font-style: normal; font-variant: normal; font-weight: 
normal; letter-spacing: normal; line-height: normal; orphans: 2; 
text-align: -webkit-auto; text-indent: 0px; text-transform: none; 
white-space: normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: 
normal; font-variant: normal; font-weight: normal; letter-spacing: 
normal; line-height: normal; orphans: 2; text-indent: 0px; 
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;
 -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space; "><span class="Apple-style-span" 
style="border-collapse: 
separate; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: 
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; 
font-weight: normal; letter-spacing: normal; line-height: normal; 
-webkit-text-decorations-in-effect: none; text-indent: 0px; 
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; 
white-space: normal; widows: 2; word-spacing: 0px; "><div 
style="word-wrap: break-word; 
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div 
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; "><span class="Apple-style-span" style="font-size: 
medium; "><div style="margin-top: 0px; margin-right: 0px;
 margin-bottom: 0px; margin-left: 0px; ">-- </div><div 
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; ">Dr. Axel Rauschmayer</div><div style="margin-top: 
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a 
href="mailto:axel@rauschma.de" moz-do-not-send="true">axel@rauschma.de</a></div><div
 style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; "><br></div><div style="margin-top: 0px; margin-right:
 0px; margin-bottom: 0px; margin-left: 0px; "><div style="margin-top: 
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">home: <a
 href="http://rauschma.de" moz-do-not-send="true">rauschma.de</a></div>twitter:

 <a href="http://twitter.com/rauschma" moz-do-not-send="true">twitter.com/rauschma</a></div><div
 style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; ">blog: <a href="http://2ality.com" 
moz-do-not-send="true">2ality.com</a></div></span></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></span>
</div>
<br></div></div>
</blockquote>
  </div>
  <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="brendan@mozilla.org" photoname="Brendan Eich" 
src="cid:part6.03040206.09050504@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:brendan@mozilla.org" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Brendan Eich</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 14, 2012 
12:51 PM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="border: 0px 
none;">
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part3.03020502.06030808@mozilla.org" photoname="Herby Vojčík" 
photoaddress="herby@mailbox.sk" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:herby@mailbox.sk" moz-do-not-send="true">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 
10:42 AM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;">=== David 
Herman wrote ===
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>===
<br>
<br>What about the exception-less suggestion I put in? It should work in
 any 
loop construct with lambda-block, even if you must know a little about 
the 
loop implementation itself. That is, to be able to put:
<br>
<br>   continue |expression|;
<br></div>
</blockquote>
<br>
Who says the block-lambda is being called from a loop at all? Why should
 use-cases that want an early result and completion have to use 
continue, which is for loops?<br>
<br>
Worse, this violates TCP. Now you copy and paste this block-lambda code 
back into a block statement to refactor the other direction, and no such
 "here is the completion value, do not flow past this point in the 
block" semantics obtain.<br>
<blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="border: 0px 
none;">
  <div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;">
<br>as a statement in lambda block which instructs the lambda-block 
itself (not 
the outer function) to return the expression? This is the de-facto 
continue 
semantics (lambda-block, do return a value and the enclosing loop will 
continue to the next iteration (possibly stopping the loop if it chooses
 not 
to have more iterations)).</div>
</blockquote>
<br>
No it's not. There is no de-facto continue semantics for block-lambdas 
because they haven't been prototyped. For block statements, no such 
continue semantics exists.<br>
<br>
<blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="border: 0px 
none;">
  <div class="__pbConvBody" __pbrmquotes="true" style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;">It is not 
possible to enforce break in the same 
manner, but for continue, it is possible.
<br></div></blockquote>
<br>
It's possible to abuse any existing keyword, but first: why must there 
be a new TCP violation? Block-lambda bodies are often expressions, or if
 statements, then short/functional-style statements, not large bodies 
demonstrating early-normal-completion opportunities.<br>
<br>
We should not eliminate TCP violations only to add new ones, especially 
without any evidence they're needed and pay their way. Otherwise we'll 
get an infinite regress of TCP-pure-then-add-new-exceptions-and-repeat 
additions.<br>
<br>
/be<br>
<blockquote type="cite" 
cite="mid:FBF70199D69F488FB9CC4E4E3FFB5AFE@RAFAEL" style="border: 0px 
none;">
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">
<br>Herby
<br>
<br>-----Pôvodná správa----- 
From: David Herman
<br>Sent: Saturday, January 14, 2012 6:12 PM
<br>To: Axel Rauschmayer
<br>Cc: Brendan Eich ; <a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
<br>Subject: Re: Block Lambdas: break and continue
<br>
<br>On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
<br>
<br>
<br>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. E.g. you could 
implement 
forEach as:
<br>
<br>   Array.prototype.forEach = function(f) {
<br>       for (let i = 0, n = this.length; i < n; i++) {
<br>           try {
<br>               f.call(this, this[i], i);
<br>           } catch (e) {
<br>               if (e instanceof BreakException)
<br>                   break;
<br>               else if (e instanceof ContinueException)
<br>                   continue;
<br>               else
<br>                   throw e;
<br>           }
<br>       }
<br>   };
<br>
<br>Whereas a function that does *not* want to expose whether it's using
 loops 
would simply do nothing with BreakException and ContinueException, and 
they 
would propagate out and you'd get the lexical scoping semantics. 
Meanwhile, 
break/continue with an explicit target would never be catch-able.
<br>
<br>Did I understand your suggestion correctly?
<br>
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>
<br>Dave
<br>
<br>_______________________________________________
<br>es-discuss mailing list
<br><a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" 
class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
<br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
 

<br>_______________________________________________
<br>es-discuss mailing list
<br><a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org" 
class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a>
<br><a moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a>
<br></div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part4.06030106.07030500@mozilla.org" photoname="David Herman" 
photoaddress="dherman@mozilla.com" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:dherman@mozilla.com" moz-do-not-send="true">David
 Herman</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 14, 2012 
9:12 AM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;"><div><!----><br>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. E.g. you could 
implement forEach as:<br><br>    Array.prototype.forEach = function(f) {<br>
        for (let i = 0, n = this.length; i < n; i++) {<br>           
 try {<br>                f.call(this, this[i], i);<br>            } 
catch (e) {<br>                if (e instanceof BreakException)<br>     
               break;<br>                else if (e instanceof 
ContinueException)<br>                    continue;<br>                
else<br>                    throw e;<br>            }<br>        }<br>  
  };<br><br>Whereas a function that does *not* want to expose whether 
it's using loops would simply do nothing with BreakException and 
ContinueException, and they would propagate out and you'd get the 
lexical scoping semantics. Meanwhile, break/continue with an explicit 
target would never be catch-able.<br><br>Did I understand your 
suggestion correctly?<br><br>This *may* not violate TCP (I'm not quite 
sure), but I'm not enthusiastic about the idea. The semantics is 
significantly more complicated, and it requires you to understand 
whether a higher-order function like forEach is catching these 
exceptions or not. So it becomes an additional part of the API of a 
function. If someone doesn't document what they do with BreakException 
and ContinueException, then writing callbacks you won't actually be able
 to predict what `break` and `continue` will do.<br><br>Dave<br><br><br></div></div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part5.03060001.03030500@mozilla.org" photoname="Axel 
Rauschmayer" photoaddress="axel@rauschma.de" height="25px" width="25px"></div>
   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:axel@rauschma.de" moz-do-not-send="true">Axel 
Rauschmayer</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
9:04 PM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">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 it applies
 to a lambda) or TCP-break (if it applies to an enclosing non-lambda 
loop). In the examples below, when I see a continue, I look for the 
innermost enclosing loop braces and the ones belong to list[i].forEach 
are definitely candidates.<div><br><div><br 
class="Apple-interchange-newline"></div><br><div 
apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: 
rgb(0, 0, 0); 
font-family: Helvetica; font-style: normal; font-variant: normal; 
font-weight: normal; letter-spacing: normal; line-height: normal; 
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: 
none; white-space: normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><span class="Apple-style-span" 
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 
Helvetica; font-style: normal; font-variant: normal; font-weight: 
normal; letter-spacing: normal; line-height: normal; orphans: 2; 
text-align: -webkit-auto; text-indent: 0px; text-transform: none; 
white-space: normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: 
normal; font-weight: normal; letter-spacing: normal; line-height: 
normal; orphans: 2; text-indent: 0px; text-transform: none; white-space:
 normal; widows: 2; word-spacing: 0px; 
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing:
 0px; -webkit-text-decorations-in-effect: none; 
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; 
font-size: medium; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; -webkit-line-break: 
after-white-space; "><span class="Apple-style-span" 
style="border-collapse: separate; color: 
rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: 
normal; font-variant: normal; font-weight: normal; letter-spacing: 
normal; line-height: normal; orphans: 2; text-indent: 0px; 
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;
 -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; 
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: 
auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: 
break-word; -webkit-nbsp-mode: space; 
-webkit-line-break: after-white-space; "><span class="Apple-style-span" 
style="border-collapse: 
separate; -webkit-border-horizontal-spacing: 0px; 
-webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: 
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; 
font-weight: normal; letter-spacing: normal; line-height: normal; 
-webkit-text-decorations-in-effect: none; text-indent: 0px; 
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; 
white-space: normal; widows: 2; word-spacing: 0px; "><div 
style="word-wrap: break-word; 
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div 
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; "><span class="Apple-style-span" style="font-size: 
medium; "><div style="margin-top: 0px; margin-right: 0px;
 margin-bottom: 0px; margin-left: 0px; ">-- </div><div 
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; ">Dr. Axel Rauschmayer</div><div style="margin-top: 
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a 
href="mailto:axel@rauschma.de" moz-do-not-send="true">axel@rauschma.de</a></div><div
 style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; "><br></div><div style="margin-top: 0px; margin-right:
 0px; margin-bottom: 0px; margin-left: 0px; "><div style="margin-top: 
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">home: <a
 href="http://rauschma.de" moz-do-not-send="true">rauschma.de</a></div>twitter:

 <a href="http://twitter.com/rauschma" moz-do-not-send="true">twitter.com/rauschma</a></div><div
 style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; 
margin-left: 0px; ">blog: <a href="http://2ality.com" 
moz-do-not-send="true">2ality.com</a></div></span></div></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></div></span></span>
</div>
<br></div></div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="postbox-contact.jpg" 
src="cid:part6.03040206.09050504@mozilla.org" photoname="Brendan Eich" 
photoaddress="brendan@mozilla.org" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:brendan@mozilla.org" moz-do-not-send="true">Brendan
 Eich</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
8:54 PM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

<blockquote style="border: 0px none;" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 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="esdiscuss@grant.x43.net" photoname="Grant Husbands" 
src="cid:part7.00010809.01050404@mozilla.org" 
name="compose-unknown-contact.jpg" moz-do-not-send="true" 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:esdiscuss@grant.x43.net" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Grant Husbands</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
7:29 PM</span></font></div></div></div>
  <div style="color: rgb(136, 
136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">Block 
lambdas have been a hot topic, recently, but there's a point of 
significant divergence between Ruby (which appears to be the 
inspiration)</div></blockquote>
<br>
Not Ruby alone, and not in any chauvinist my-language-is-better sense. 
Smalltalk is the original inspiration for Ruby blocks, and the 
correspondence principle has deep roots.<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 type="cite"><div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"> and the 
proposed solution, in the handling of continue (called 'next', in Ruby) 
and 'break'.<div>
<br></div><div>To whit: In Ruby, 'next' will end the current run 
(iteration) of the block, and 'break' will (somehow) terminate the 
method lexically connected with the block. It can be claimed that this 
is more intuitive than the current proposal, which aims to make 'break' 
and 'continue' propagate through block lambdas in the same way 'return' 
would.</div></div></blockquote>
<br>
"Intuitive" depends on intuition, which is not well-defined. Do you mean
 a Rubyist might expect different behavior for break? That is possible 
but JS ain't Ruby and break should not change to do something like what 
it does in Ruby (and we aren't defining a next equivalent for JS).<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 type="cite"><div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<div>Ruby does also support syntactic loops and the same keywords 
therein and so directly violates Tennent's Correspondence Principle, 
even though such has been touted as a core reason for the construct. 
Instead, I believe it reasonable to invoke intuition in this matter. It 
is intuitive for 'return' to return a value from the lexically enclosing
 method and it is intuitive for 'continue' to commence the next 
iteration of the current loop,</div></div></blockquote>
<br>
Wait, why do you think break and continue without label operands do 
anything other than break from the nearest enclosing loop (or switch or 
labeled statement if break), or continue the nearest enclosing loop? The
 proposal specifies this.<br>
<br>
<span style="font-family: monospace;">function 
find_odds_in_arrays(list,        // array of arrays</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">                             
skip)        // if found, skip rest</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">{</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">  let a = [];</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">  for (let i = 0; i < 
list.length; i++) {</span><br style="font-family: monospace;">
<span style="font-family: monospace;">    list[i].forEach {</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      |e|</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      if (e === skip) {</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">        
continue;                         // continue the for loop</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      if (e & 1) {</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">        a.push(e);</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">    }</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">  }</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">  return a;</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">}</span><br style="font-family: 
monospace;">
<br>
<span><span style="font-family: monospace;">function 
find_more_odds(list, stop) {</span><br style="font-family: monospace;">
  <span style="font-family: monospace;">  let a = [];</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">  for (let i = 0; i < 
list.length; i++) {</span><br style="font-family: monospace;">
  <span style="font-family: monospace;">    list[i].forEach {</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      |e|</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      if (e === stop) {</span><br
 style="font-family: monospace;">
  <span style="font-family: monospace;">        
break;                      // break from the for loop</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      if (e & 1) {</span><br
 style="font-family: monospace;">
  <span style="font-family: monospace;">        a.push(e);</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">      }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">    }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">  }</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">  return a;</span><br 
style="font-family: monospace;">
  <span style="font-family: monospace;">}</span><br style="font-family: 
monospace;">
<br>
<blockquote style="border: 0px none;" 
cite="mid:CAOjLovh3-OP-iq5pgt3DChR60MWsVdz9eGcwBpj386+P-vS8WQ@mail.gmail.com"
 type="cite"><div 
style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
    <div>however that loop is constructed.</div>
  </div></blockquote></span><br>
What do you mean by this? The spec talks about nearest enclosing loop or
 relevant control structure in the source code. Are you talking about 
internal loops in implementations (dynamically dispatched at that) of 
methods that take block-lambdas as arguments? I.e.<br>
<br>
<br>
<span style="font-family: monospace;">function find_first_odd(a) {</span><br
 style="font-family: monospace;">
<span style="font-family: monospace;">  a.forEach { |e, i|</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">              if (e & 1) 
return i; }  // returns from function</span><br style="font-family: 
monospace;">
<span style="font-family: monospace;">  return -1;</span><br 
style="font-family: monospace;">
<span style="font-family: monospace;">}</span><br style="font-family: 
monospace;">
<br>
<br>
The Array.prototype.forEach method's internal implementation is its 
business, and a break instead of the return would be a static error in 
this example. It would not be a dynamic throw-like construct that is 
caught by forEach's implementation.<br>
<br>
/be<br>
  </div>
  <div class="__pbConvHr" style="margin:30px 25px 10px 25px;"><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
 moz-do-not-send="true" name="compose-unknown-contact.jpg" 
src="cid:part7.00010809.01050404@mozilla.org" photoname="Grant Husbands"
 photoaddress="esdiscuss@grant.x43.net" height="25px" width="25px"></div>
   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;" href="mailto:esdiscuss@grant.x43.net" 
moz-do-not-send="true">Grant Husbands</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 13, 2012 
7:29 PM</span></font></div></div></div>
  <div class="__pbConvBody" __pbrmquotes="true" 
style="color:#888888;margin-left:24px;margin-right:24px;">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'.<div>
<br></div><div>To whit: In Ruby, 'next' will end the current run 
(iteration) of the block, and 'break' will (somehow) terminate the 
method lexically connected with the block. It can be claimed that this 
is more intuitive than the current proposal, which aims to make 'break' 
and 'continue' propagate through block lambdas in the same way 'return' 
would.</div>
<div><br></div><div>Ruby does also support syntactic loops and the same 
keywords therein and so directly violates Tennent's Correspondence 
Principle, even though such has been touted as a core reason for the 
construct. Instead, I believe it reasonable to invoke intuition in this 
matter. It is intuitive for 'return' to return a value from the 
lexically enclosing method and it is intuitive for 'continue' to 
commence the next iteration of the current loop, however that loop is 
constructed.</div>
<div><br></div><div>Note that the label-based break/continue could still
 have the desired effect, if the proposal was updated to be more like 
Ruby's blocks.</div><div><br></div><div>I don't have a strong opinion on
 the subject, but I hadn't noticed the above being discussed, elsewhere,
 and thought it worth raising. If there is a better place for me to 
raise this, please let me know where and accept my apologies.</div>
<div><br></div><div>Regards,</div><div>Grant Husbands.</div>

<div>_______________________________________________<br>es-discuss 
mailing list<br><a moz-do-not-send="true" 
href="mailto:es-discuss@mozilla.org" class="moz-txt-link-abbreviated">es-discuss@mozilla.org</a><br><a
 moz-do-not-send="true" 
href="https://mail.mozilla.org/listinfo/es-discuss" 
class="moz-txt-link-freetext">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div></blockquote>
  </div>
  <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:part3.03020502.06030808@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 
10:42 AM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">=== David Herman wrote ===
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>===
<br>
<br>What about the exception-less suggestion I put in? It should work in
 any 
loop construct with lambda-block, even if you must know a little about 
the 
loop implementation itself. That is, to be able to put:
<br>
<br>   continue |expression|;
<br>
<br>as a statement in lambda block which instructs the lambda-block 
itself (not 
the outer function) to return the expression? This is the de-facto 
continue 
semantics (lambda-block, do return a value and the enclosing loop will 
continue to the next iteration (possibly stopping the loop if it chooses
 not 
to have more iterations)). It is not possible to enforce break in the 
same 
manner, but for continue, it is possible.
<br>
<br>Herby
<br>
<br>-----Pôvodná správa----- 
From: David Herman
<br>Sent: Saturday, January 14, 2012 6:12 PM
<br>To: Axel Rauschmayer
<br>Cc: Brendan Eich ; <a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<br>Subject: Re: Block Lambdas: break and continue
<br>
<br>On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
<br>
<br>
<br>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. E.g. you could 
implement 
forEach as:
<br>
<br>   Array.prototype.forEach = function(f) {
<br>       for (let i = 0, n = this.length; i < n; i++) {
<br>           try {
<br>               f.call(this, this[i], i);
<br>           } catch (e) {
<br>               if (e instanceof BreakException)
<br>                   break;
<br>               else if (e instanceof ContinueException)
<br>                   continue;
<br>               else
<br>                   throw e;
<br>           }
<br>       }
<br>   };
<br>
<br>Whereas a function that does *not* want to expose whether it's using
 loops 
would simply do nothing with BreakException and ContinueException, and 
they 
would propagate out and you'd get the lexical scoping semantics. 
Meanwhile, 
break/continue with an explicit target would never be catch-able.
<br>
<br>Did I understand your suggestion correctly?
<br>
<br>This *may* not violate TCP (I'm not quite sure), but I'm not 
enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach 
is 
catching these exceptions or not. So it becomes an additional part of 
the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
<br>
<br>Dave
<br>
<br>_______________________________________________
<br>es-discuss mailing list
<br><a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<br><a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a> 

<br>
<br></div>
  <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="dherman@mozilla.com" photoname="David Herman" 
src="cid:part4.06030106.07030500@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:dherman@mozilla.com" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">David Herman</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">January 14, 2012 
9:12 AM</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody"><div><!----><br>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. E.g. you could 
implement forEach as:<br><br>    Array.prototype.forEach = function(f) {<br>
        for (let i = 0, n = this.length; i < n; i++) {<br>           
 try {<br>                f.call(this, this[i], i);<br>            } 
catch (e) {<br>                if (e instanceof BreakException)<br>     
               break;<br>                else if (e instanceof 
ContinueException)<br>                    continue;<br>                
else<br>                    throw e;<br>            }<br>        }<br>  
  };<br><br>Whereas a function that does *not* want to expose whether 
it's using loops would simply do nothing with BreakException and 
ContinueException, and they would propagate out and you'd get the 
lexical scoping semantics. Meanwhile, break/continue with an explicit 
target would never be catch-able.<br><br>Did I understand your 
suggestion correctly?<br><br>This *may* not violate TCP (I'm not quite 
sure), but I'm not enthusiastic about the idea. The semantics is 
significantly more complicated, and it requires you to understand 
whether a higher-order function like forEach is catching these 
exceptions or not. So it becomes an additional part of the API of a 
function. If someone doesn't document what they do with BreakException 
and ContinueException, then writing callbacks you won't actually be able
 to predict what `break` and `continue` will do.<br><br>Dave<br><br><br></div></div>
</blockquote>
</body></html>