<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 9, 2008, at 4:15 PM, Jon Zeppieri wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Dec 9, 2008 at 5:42 PM, Michael Day &lt;<a href="mailto:mikeday@yeslogic.com">mikeday@yeslogic.com</a>> wrote:<br><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Or practically any other keyword we can think of. So this problem exists for</span></blockquote><blockquote type="cite">many of the proposed syntactic extensions to JavaScript. Is there any way<br></blockquote><blockquote type="cite">other than opt-in to introduce to new keywords without breaking existing<br></blockquote><blockquote type="cite">code?<br></blockquote><br>Aside from picking really odd keywords? &nbsp;I don't think so. &nbsp;That's why<br>people have been discussing the use of non-identifier ASCII<br>punctuation.</div></blockquote><div><br></div>Opt-in versioning was required for let and yield in JS1.7 -- it's a <i>fait accompli</i>.</div><div><br></div><div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">The benefit seems vanishingly small. &nbsp;I don't think it's enough to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cover the (admittedly minor) cost in language complexity.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Mozilla already has expression comprehensions, albeit without the<br></blockquote><blockquote type="cite">parentheses, so this aspect can be evaluated now.<br></blockquote><br>JS also has a more powerful expression language than ES, so it<br>wouldn't be an entirely accurate evaluation. &nbsp;It could be that Harmony<br>will adopt many of the JS additions, though.</div></blockquote><div><br></div>I wasn't sure whether "expression comprehensions" meant expression closures:</div><div><br></div><div>function hi() "there";</div><div><br></div><div>or array comprehensions:</div><div><br></div><div>&nbsp;&nbsp;return [i*i for (i in nat(N))];</div><div><br></div><div><br><blockquote type="cite"><div><blockquote type="cite">Everything currently in the specification describing functions will still<br></blockquote><blockquote type="cite">need to be there, even if some of it is rewritten to be expressed in terms<br></blockquote><blockquote type="cite">of lambdas. On top of that, lambdas will need to be described. This will<br></blockquote><blockquote type="cite">make the spec longer, and have more constructs that need to be understood.<br></blockquote><br>Harmony almost certainly won't use the pseudocode specification style<br>of current ES specs. &nbsp;So, I have no idea how long the spec will be. &nbsp;I<br>do know, however, that having more things to describe does not<br>necessarily entail a longer text, and I also know that length and<br>complexity don't have as simple a relation to one another as you seem<br>to imply.</div></blockquote><div><br></div>The relations are not simple. But I have to say that the lambda-coded for loop examples:</div><div><br></div><div><a href="https://mail.mozilla.org/pipermail/es-discuss/2008-October/007822.html">https://mail.mozilla.org/pipermail/es-discuss/2008-October/007822.html</a></div><div><br></div><div>were not what I would call clear specifications -- at least not to the audience of JS implementors working in C++ or a similar language, and not experienced lambda-coders.</div><div><br></div><div>/be</div></body></html>