On Jun 18, 2011, at 10:33 AM, Peter Michaux wrote: > Recently, I've invested time looking at current > compiling-to-JavaScript developments. Although people have been doing > this for many years now, it seems CoffeeScript is making it clear that > being a target of compilation is at least part of JavaScript's future. > The pending additions in browsers of support for debugging original > source language seems to reinforce this future direction as a serious > possibility.
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. > 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). > 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 > 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). It seems to me you are using the expressive power of lambda to argue for efficiency, which is makes a category mistake. > 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. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
