On Sat, Jun 18, 2011 at 11:53 AM, Brendan Eich <bren...@mozilla.com> wrote: > On Jun 18, 2011, at 10:33 AM, Peter Michaux wrote:
> Yet CoffeeScript does not need lambdas with TCP control effects today. It > translates in a straightforward (mostly) "transpiling" way. Even its > expression-language mapping of statements as expressions does not require > lambdas. Maybe CoffeeScript doesn't need it today. Another source language could benefit from JavaScript having lambdas. > > JavaScript doesn't have macros to allow programmers to tune the > > language to their likes and needs. So it seems that developers have > > decided that compiling to JavaScript is the route to go because they > > can do that right now. They are, however, limited by the features that > > are part of JavaScript with regard to what features the source > > language can have that are efficient in the compiled JavaScript. > > Additions to JavaScript, especially low-level functionality, will open > > doors for the source languages. > > Sure. The problem is drawing the line, as we've discussed in this list since > 2006 (when Nicholas Cannasse brought up call/cc). Drawing the line in the right place is important of course. I was trying to contribute to the case that drawing the line with lambdas in would be beneficial to some and perhaps a growing group in the future. > > The most interesting part of the block lambda proposal is adding > > lambdas to JavaScript. Regardless of syntax, this would mean a lot of > > possibilities open for languages targeting JavaScript. > > That's not yet evident. Yes, some source languages (and some compiler > writers) would want lambdas. Not all, and the compiler writers seem to be > doing fine working around lack of lambdas: > https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS I don't think that list proves too much. Many of those languages are sufficiently far from JavaScript's semantics that the compiled JavaScript code is too inefficient to run in a production system. In fact, this may be partly why CoffeeScript is the first language that compiles to JavaScript to draw major attention. CoffeeScript is just a thin skin over JavaScript and so the compiled code can perform well. > > Often a heavy > > function is not a good idea in the compiled code and the lack of > > Tennent's Correspondence Principle for functions means the compilers > > need to do big tricks to get the compiled code to do what is desired. > > As a trivial example, if JavaScript had lambdas but no let blocks then > > a source language could add efficient let blocks quite easily. > > How efficient is wide open to question. VMs implementing let can more > readily optimize without having to optimize lambdas in full (TCP effects > included). Fair enough. I don't know which VM implementations would benefit or suffer. > It seems to me you are using the expressive power of lambda to > argue for efficiency, which is makes a category mistake. I didn't intend that. > What is the current feeling about the block lambda proposal in TC39? > What can be done to help move the block lambda proposal towards > Harmony? > > I noted the reaction here and in talks I've given, citing the straw poll I > took about arrow functions, lambdas, there-can-be-only-one. 8/6/unanimous > (some abstained). IOW, TC39 wants at most one > lambda-or-just-shorter-function syntax (lambda carries semantics). The > committee was mixed on arrow functions with Waldemar concerned about > grammatical issues I've tried to address in the strawman. Others were quite > in favor of arrows. > Block lambdas were more divisive, in part because of the syntax, but in > larger part (IMHO) because of the novel TCP semantics. Some on the committee > decried "excessive bits of cleverness". Others said "won't this confuse > n00bs?" (Meta-discussion #27 > from http://www.slideshare.net/BrendanEich/txjs-talk). More than a few were > quite in favor, though (Allen, Dave Herman, Mark Miller). > So, a mixed reaction and no consensus for ES.next. So what can be done to help move the block lambda proposal towards Harmony? Peter _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
