<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 14, 2012, at 1:31 PM, François REMY wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div dir="ltr" bgcolor="#ffffff" text="#000000">
<div dir="ltr">
<div style="FONT-FAMILY: 'Segoe UI'; COLOR: #000000; FONT-SIZE: 12pt">
<div>Thanks for your reply. I think you misunderstood the whole concept. The 
idea would not to implement that for Arrays. Arrays already have their own 
semantics.</div>
<div> </div>
<div>I think the idea about Block Lamdba is to introduce functionnal programming 
concepts to ECMAScript. 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><div><br></div><div>Actually, I think having a standard patten is a hazard.  The reason is that there may be multiple additional and dynamically determined control abstraction layers (and activation records) between the "WebWorker" iteration abstraction the actual evaluation of the Block Lambda that does the "throw".  If you have a standard exception that is used for this purpose then you have to worry about the intermediate layer using that same standard.</div><div><br></div><div>As Dave and I both mentioned.  This sort of escape mechanism really needs to be uniquely defined as part of the contract of each iterator abstraction that supports.  Defining a specific (and unique) exception type is a fine way to do it.  For example, my forNum function could define a privateName valued property that does that:</div><div><div><br></div><div>forNum.breaker = Name.create();  //sometimes hoisting is nice</div><div>function forNum(start, end,increment=1,body={||}) {</div><div>   if (start > end) return;</div><div>   try {</div><div>      body(start);</div><div>   } catch (e if e is forNum.breaker) {return}; // probably better to factor this hander into a non-recursive wrapper</div><div>   return forNum(start+increment,end,increment,body);</div><div>}</div></div><div><br></div><div>which could be used like:</div><div><br></div><div>forNum(first,last,1) {|n|</div><div>   if (n==0) throw forNum.breaker;</div><div>   ...</div><div>}</div><div><br></div><div>The above style forces the iteration abstraction to explicitly define its "break" contract and forces the user of the iteration abstraction to use the contract specified mechanism.  No tripping over undocumented or unexpected usage of defaults.</div><div><br></div><div>Allen</div><div><br></div><div><br></div><div><br></div><br><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr" bgcolor="#ffffff" text="#000000"><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><font size="3" face="Segoe UI"></font> </div>
<div style="BACKGROUND: #f5f5f5">
<div style="font-color: black"><b>From:</b> <a title="brendan@mozilla.org" href="mailto:brendan@mozilla.org">Brendan Eich</a> </div>
<div><b>Sent:</b> Saturday, January 14, 2012 10:16 PM</div>
<div><b>To:</b> <a title="fremycompany_pub@yahoo.fr" href="mailto:fremycompany_pub@yahoo.fr">François REMY</a> </div>
<div><b>Cc:</b> <a title="herby@mailbox.sk" href="mailto:herby@mailbox.sk">Herby 
Vojčík</a> ; <a title="es-discuss@mozilla.org" href="mailto: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 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" 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"><span><postbox-contact.jpg></span></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: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 style="COLOR: rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" __pbrmquotes="true">
  <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 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" type="cite">
  <div style="COLOR: rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" __pbrmquotes="true">
  <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 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" type="cite">
  <div style="COLOR: rgb(136,136,136); MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" __pbrmquotes="true">
  <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 style="BORDER-BOTTOM: 0px; BORDER-LEFT: 0px; BORDER-TOP: 0px; BORDER-RIGHT: 0px" cite="mid:FD78A0EAB7B545F8982C9AAB559BBDAF@FREMY2" type="cite">
  <div style="COLOR: #888888; MARGIN-LEFT: 24px; MARGIN-RIGHT: 24px" class="__pbConvBody" __pbrmquotes="true">
  <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"><span><postbox-contact.jpg></span></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"><span><postbox-contact.jpg></span></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"><span><postbox-contact.jpg></span></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: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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"><span style="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal 12px/normal helvetica; white-space: normal; orphans: 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; " 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"><span><postbox-contact.jpg></span></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"><span><compose-unknown-contact.jpg></span></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"><span><compose-unknown-contact.jpg></span></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>
  <hr>
  _______________________________________________<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></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" 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"><span><postbox-contact.jpg></span></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 14, 2012 12:51 
  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: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"><span><postbox-contact.jpg></span></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"><span><postbox-contact.jpg></span></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"><span><postbox-contact.jpg></span></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: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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"><span style="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal 12px/normal helvetica; white-space: normal; orphans: 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; " 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"><span><postbox-contact.jpg></span></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"><span><compose-unknown-contact.jpg></span></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"><span><compose-unknown-contact.jpg></span></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></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"><span><postbox-contact.jpg></span></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: #888888; 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><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" 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"><span><postbox-contact.jpg></span></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"><span><postbox-contact.jpg></span></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: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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"><span style="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal medium/normal helvetica; white-space: normal; orphans: 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="widows: 2; text-transform: none; text-indent: 0px; letter-spacing: normal; border-collapse: separate; font: normal normal normal 12px/normal helvetica; white-space: normal; orphans: 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; " 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></blockquote></div></div></div></div>
_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>https://mail.mozilla.org/listinfo/es-discuss<br></blockquote></div><br></body></html>