<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 1, 2011, at 10:07 AM, Jorge wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><blockquote type="cite">A block:<br></blockquote><blockquote type="cite">{ noLabelHere ... }<br></blockquote><blockquote type="cite"><font class="Apple-style-span"><font class="Apple-style-span" color="#006312"><br></font></font></blockquote></div></blockquote><blockquote type="cite"><div>We didn't talk about this change. It is yet another migration early-error to consider.</div></blockquote><div><br></div><div>But it's not very usual to begin a block with a label.</div></div></div></blockquote><div><br></div>You're right, and it can be an ArrowBodyBlock, not a backward-compatible Block, so this is only a refactoring-from-function-to-arrow-syntax tax. Good idea.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>It's certainly simpler than a more powerful parsing algorithm than LR(1), </div></blockquote><div><br></div><div>If you </div><div><br></div><div>1.- keep the familiar { block } syntax for first class blocks, and </div><div>2.- use {|| ... } for shorter functions syntax and</div><div>3.- keep the (obligatory) parens as the call() operator</div><div><br></div><div>wouldn't we gain everything in the arrow syntax and block lambdas strawmen, except for paren-freeness ?</div></div></div></blockquote><div><br></div>No, some people object to the cleverness of block-lambdas, the TCP preservation for break, continue, return, and |this|, and the completion-return too.</div><div><br></div><div>Paren-free syntax for block-lambdas as control abstractions is controverisal, but less so, and IMHO trumped up (since when was C# in its multi-version glory designed holistically at 1.0? LINQ and other innovations have come relatively quickly).</div><div><br></div><div>Block-lambdas are more divisive because they introduce novel runtime semantics, akin to throwing uncatchable-except-by-the-VM exceptions.</div><div><br></div><div>Arrow function syntax is just syntax, so it is an easier sell, provided the grammar and semantics can be added to the ECMA-262 framework without too much trouble.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>And, wouldn't that be easier for the current (proven) parsers, and pose almost zero risks in this respect ?</div></div></div></blockquote><div><br></div>The parsing problems of arrows are really only in the ECMA-262 spec-space, not in real implementations.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>And, wouldn't that be in line the already known, much appreciated by many of us, current JS (and C) style ?</div><div><br></div><div>{ block }( call ) or {|| ... }( call )</div></div></div></blockquote><div><br></div>Since when can you call a block in JS or C?</div><div><br></div><div>A function expression is not a block, it starts with 'function(' at the least.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>foo bar baz ... wtf ?  foo(bar(baz)) ? foo(bar)(baz) ? foo(bar)(baz)() ? meh! This syntax introduces ambiguities !</div></div></div></blockquote><div><br></div>Not the way the strawman grammar works. Did you read it?</div><div><br></div><div>Here you seem to be inveighing against the paren-free <i>CallWithBlockArguments</i> production, not against arrow function syntax. Yet you switch targets immediately:</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Do David and Jeremy like it ? Good for them. Do JavaScripters like it ? The least we can say is that it's quite polemical : <<a href="https://github.com/rails/rails/commit/9f09aeb8273177fc2d09ebdafcc76ee8eb56fe33">https://github.com/rails/rails/commit/9f09aeb8273177fc2d09ebdafcc76ee8eb56fe33</a>></div></div></div></blockquote><div><br></div>What are you talking about now? Arrows or call-with-block-lambda-argument paren-free calls? The two are entirely separate strawmen, the latter part of block-lambdas.</div><div><br></div><div>If by David you mean DHH, didn't he endorse CoffeeScript, which uses arrow function syntax, and not any Ruby-ish block-lambda proposal from me? Please keep your arguments straight!</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><blockquote type="cite"><div>but we might want to cross that bridge anyway for arrow functions.</div></blockquote><br></div><div><fwiw></div><div><br></div><div>Arrow syntax is extraneous to JS developers. It's an unnecessary, radical style change. And ugly: there are JS developers that just *don't*like* it. </div></div></div></blockquote><div><br></div>People say that about block-lambdas and not just for the non-function-looking syntax -- especially for the semantics, which are novel.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>So, why ? </div></div></div></blockquote><div><br></div>I think the shoe is on the other foot.</div><div><br></div><div>Look, I wrote up both <a href="http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax">http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax</a> and <a href="http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival">http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival</a> to give both the arrow fans (not just CoffeeScript, it is in many languages and math-y notation systems) and block-lambdas (originated in Smalltalk, also in a more layered form in Ruby) both a fair shake.</div><div><br></div><div>Don't shoot the messengers who want only one, or neither. And don't shoot me for drafting these. JS's function syntax with mandatory return in braced body is too long. But fixing that is not a simple matter of *only* shortening function to some ugly and conflicted punctuator. It's not a matter of pretending block-lambdas are blocks and are already callable. It requires careful work to meet several often-conflicting goals and requirements.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Paren-free(ness) is a fashion: foo bar baz, what's a function, who's calling who ? with which parameters ? Meh! Ambiguities.</div></div></div></blockquote><div><br></div>How about you stop ranting and read the block-lambda grammar.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div></fwiw></div><br><blockquote type="cite"><div>If we succeed there, we may not need such an incompatible restriction on labels.<br></div></blockquote><br></div><div>-1</div></div></blockquote><div><br></div>-1 on what, the incompatible change being rejected? It isn't necessary anyway: we can split Block and ArrowBodyBlock or anything like it. So cheer up!</div><div><br></div><div>/be</div></body></html>