Re: block lambda proposal in light of compiling to JavaScript
Brendan Eich-3 wrote: > > > 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. > > I'm +1 for block level lambdas. I think we definitely need shorter function syntax, so why not take it with additional power and simplicity that lambdas will give us. At least this: http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival looks very appealing to me. - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/block-lambda-proposal-in-light-of-compiling-to-JavaScript-tp31876202p31885102.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda proposal in light of compiling to JavaScript
So one thing that lambda really helps with, and where TCP is a serious practical issue and not just philosophical, is macros. Macros need the ability to create new kinds of control flow by taking expressions and reordering and delaying them. You can use 'function' for this but you don't want the expressions to change their meaning in a handful of clunky ways (this, arguments, return, etc.). Otherwise you have to say things like "this macro takes an expression and a statement -- but they can't refer to this or arguments, can't use yield or return or break or...". (Incidentally, turning the TCP violators into errors isn't much of a fix; it fails fast, which is better, but it still means that subterms that use |this| or |arguments| or whatever just can't be used with the macro.) I have some thoughts about how to approach macros for JS, and I know there's at least some interest both on the committee and in the wider community for macros. In the sense that macros are lightweight language extensions, transpilers like CoffeeScript could also benefit from blocks if they wanted to add features that delay evaluation. For example, a `lazy' construct for thunking an expression that can be forced on demand, such as in an event callback. That's just one example, but lambda is pretty much the fundamental building block for building features by shallow translation (aka macro expansion, aka desugaring, aka transpilers). This doesn't change the fact that being able to execute a return statement after its function has already returned is a new kind of error that wasn't there before. Personally, I blame return as the feature at fault... but sadly that horse left the barn somewhere in the 60's or 70's. ;) Dave On Jun 18, 2011, at 4:14 PM, Brendan Eich wrote: > On Jun 18, 2011, at 1:50 PM, Brendan Eich wrote: > >> On Jun 18, 2011, at 1:02 PM, Peter Michaux wrote: >>> So what can be done to help move the block lambda proposal towards Harmony? >> >> To me the biggest obstacle is the meta-point about "OMG too different" >> regarding return, break, and continue having TCP conformance. At least one >> TC39er also wanted |this| to be other than lexical (i.e., TCP-conformant). I >> don't know how to overcome this meta-discussion point. Arguing endlessly >> about it does not get anywhere. > > A couple of more thoughts: > > * I said at #txjs that instead of endless meta-discussions, we should > "address concrete use-cases, fill language gaps". That requires showing how > concrete use-cases unserved by function today are served by lambda, or else > showing a language gap that needs filling for a more subtle reason. > > * Implementing block-lambdas as an extension in a real browser and then > winning developers support, where the developers convey their wish in large > enough numbers to other browser vendors, would do it. Clearly this can take a > while (getters and setters, array extras). > > /be > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda proposal in light of compiling to JavaScript
On Jun 18, 2011, at 1:50 PM, Brendan Eich wrote: > On Jun 18, 2011, at 1:02 PM, Peter Michaux wrote: >> So what can be done to help move the block lambda proposal towards Harmony? > > To me the biggest obstacle is the meta-point about "OMG too different" > regarding return, break, and continue having TCP conformance. At least one > TC39er also wanted |this| to be other than lexical (i.e., TCP-conformant). I > don't know how to overcome this meta-discussion point. Arguing endlessly > about it does not get anywhere. A couple of more thoughts: * I said at #txjs that instead of endless meta-discussions, we should "address concrete use-cases, fill language gaps". That requires showing how concrete use-cases unserved by function today are served by lambda, or else showing a language gap that needs filling for a more subtle reason. * Implementing block-lambdas as an extension in a real browser and then winning developers support, where the developers convey their wish in large enough numbers to other browser vendors, would do it. Clearly this can take a while (getters and setters, array extras). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda proposal in light of compiling to JavaScript
On Jun 18, 2011, at 1:02 PM, Peter Michaux wrote: > 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. If you wrote "might" instead of "would", that is clearly true. But it's not enough to get them into Harmony. "Would" is a stronger claim and will lead to endless debates with too many hypotheticals. >> 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. This is a good point, but it may argue for unsafe features, call/cc and other "safe but inappropriate" features, more things like typed arrays, int and other machine types for arithmetic (not just storage as in typed arrays), and so on. Well before anyone wants lambdas. We're considering various features like the ones I just listed, and I know compiler writers including people compiling from source languages quite different from JS (e.g., Emscripten) will make good use of some of these extensions. Again lambdas have not come up from any of the compiler writers I've heard from. > So what can be done to help move the block lambda proposal towards Harmony? To me the biggest obstacle is the meta-point about "OMG too different" regarding return, break, and continue having TCP conformance. At least one TC39er also wanted |this| to be other than lexical (i.e., TCP-conformant). I don't know how to overcome this meta-discussion point. Arguing endlessly about it does not get anywhere. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda proposal in light of compiling to JavaScript
On Sat, Jun 18, 2011 at 1:02 PM, Peter Michaux wrote: [...] > So what can be done to help move the block lambda proposal towards Harmony? > Accumulating more arguments in its favor, as you are attempting to do in this thread, and answering arguments against. The gate is achieving consensus among the committee, and the only way through the gate is to convince committee members that lambdas are a good idea. There is no shortcut around that. Btw, here's another point in favor that I just posted in the quasis thread: Since the only TCP problems in JS *Expressions* are "this" and "arguments", prohibiting "arguments" and binding "this" [to thunkify an expression in an expansion] takes care of all TCP problems. [...] If we extend JS to allow statements within expressions, then we'll [lose this pleasant expression-thunkification technique]. Indeed, I would argue that we should only allow statements in expressions if we chose lambda over arrow functions, in order to avoid multiplying TCP problems. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda proposal in light of compiling to JavaScript
On Sat, Jun 18, 2011 at 11:53 AM, Brendan Eich 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
Re: block lambda proposal in light of compiling to JavaScript
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
block lambda proposal in light of compiling to JavaScript
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. 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. 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. 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. 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? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
