block lambda proposal in light of compiling to JavaScript

Peter Michaux petermichaux at gmail.com
Sat Jun 18 13:02:10 PDT 2011


On Sat, Jun 18, 2011 at 11:53 AM, Brendan Eich <brendan at 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


More information about the es-discuss mailing list