<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 6:18 AM, Andreas Rossberg <span dir="ltr"><<a href="mailto:rossberg@google.com" target="_blank">rossberg@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 8 January 2014 17:32, Mark S. Miller <<a href="mailto:erights@google.com">erights@google.com</a>> wrote:<br>

> On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg <<a href="mailto:rossberg@google.com">rossberg@google.com</a>><br>
> wrote:<br>
>> On 7 January 2014 20:44, Allen Wirfs-Brock <<a href="mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a>> wrote:<br>
>> > Unless we can identify real implementation issues, the semantics of<br>
>> >    do { }<br>
>> ><br>
>> > should simply be those of a blocks.<br>
>><br>
>> I don't think this flies anyway. It has to be more like a function<br>
>> body, otherwise var and function declarations would hoist out of it,<br>
>> which would be insane IMO.<br>
><br>
> strict function declarations don't hoist out of blocks, so the hoisting<br>
> issue is var only.<br>
<br>
</div>Good point.<br>
<div class="im"><br>
> I would find it surprising if var declarations did not<br>
> hoist out of do expressions.<br>
<br>
</div>Interesting. I have the exact opposite expectation. And I don't see<br>
what good it would do usability-wise.</blockquote><div><br></div><div>Now that we have const and let, vars serve no usability purpose whatsoever. However, given their existence in the language, the best we can do with them usability-wise is to follow the principle of least surprise. Since we have opposite surprise reactions, this doesn't tell us what to do, but at least we should be able to agree on this criterion.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
>> What I'm arguing for, then, simply is to make it as much like a<br>
>> function body as possible. (That also matches the current IIFE<br>
>> practice best.)<br>
>><br>
>> Also, I really would want to avoid examples like<br>
>><br>
>>   return do { break; }<br>
>><br>
>> and similar craze.<br>
>><br>
>> Is there a convincing example where cross-expression jumps would<br>
>> actually be useful?<br>
><br>
><br>
> If all we want is sugar for IIFEs, I wouldn't bother. With arrow functions,<br>
> IIFEs are already a lot shorter. The extra brevity of do expressions is not<br>
> worth it.<br>
<br>
</div>It's not only the brevity as such, but having a natural, targeted<br>
language feature. IIFEs are merely an encoding, and as such a<br>
distraction. Like A + -B is brief enough, but I'm sure you prefer<br>
saying A - B.</blockquote><div><br></div><div>In a language with infix + and unary -, *and the absence of prior expectations of an infix -*, the pressure to add an infix minus is small for exactly this reason. A repeated pattern often comes to be perceived as a phrase. In the absence of infix minus or prior expectations, A + -B would rapidly become seen to do what it does.</div>
<div><br></div><div>I do have one usability concern with arrow IIFEs. I hate when I see them written as ()=>{...whatever...}() because you don't know that it's an IIFE until the end. Function expressions have the same issue. We should adapt Crock's recommended paren style to arrow IIFEs, to whit (()=>{...whatever...}()), even though this looses a bit more brevity.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
> What would make do expressions worthy of consideration is if they repaired<br>
> the TCP violations of strict arrow IIFEs, including var, arguments, break,<br>
> continue, return, and especially yield.<br>
<br>
</div>Can you clarify what you mean by "repair"? I hope you don't suggest<br>
that "while (true) { (() => do { break })() }" should magically work.<br></blockquote><div><br></div><div>No, I am not suggesting that code within the do block is TCP wrt the context outside the function containing the do expression. This would be a TCP violation wrt the context of the do expression. Rather, I suggest that the following must work:</div>
<div><br></div><div>    while (true) { do { break; } }</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I may warm up to the extra complexity more easily if somebody could<br>
present at least some compelling use cases. :)<br>
<span class="HOEnZb"><font color="#888888"><br>
/Andreas<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div></div>