block lambda proposal in light of compiling to JavaScript

Brendan Eich brendan at
Sat Jun 18 13:50:08 PDT 2011

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.

> 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.


More information about the es-discuss mailing list