block lambda proposal in light of compiling to JavaScript

Peter Michaux petermichaux at
Sat Jun 18 10:33:50 PDT 2011

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

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


More information about the es-discuss mailing list