block lambda revival

Brendan Eich brendan at
Sat May 21 11:09:51 PDT 2011

On May 21, 2011, at 10:05 AM, Peter Michaux wrote:

> On Sat, May 21, 2011 at 7:56 AM, Rick Waldron <waldron.rick at> wrote:
>> Brendan,
>> Thanks for the clarification on that.
>> I've been following the shorter function syntax discussions pretty closely,
>> as well as reading the strawman proposals, so please forgive me if this has
>> been addressed or refuted.
>> Given your example: b = a.forEach (x) { x * x } And the issues you noted
>> there, would the same issues apply here:
>> b = a.forEach( (x) { x * x } )
>>              ^               ^
> I don't see a prefix being a problem to reduce ambiguity. It would
> actually be beneficial for readability.
> b = a.forEach( lambda(x) { x * x } )

'lambda' is not reserved, and extant JS on the web uses it.

You're ignoring the goal of providing paren-free block-argument call syntax for control abstractions that look like built-in control-flow statements.

> It seems this strawman is proposing true lambdas so the name is apt.
> It sure is easy to Google "JavaScript lambda" or search code for
> "lambda".

Do that now and see all the hits for uses of lambda we would be breaking.

> functionreturn is 14 characters. lambda is 6 characters. That is a
> 8/14 character savings which is pretty good for those worried about
> character count. I don't know why we have to be so extreme and get the
> savings up to 12/14. In the case that the lambda has a few possible
> return points the savings on repeated "return" would be repeated
> savings.

'lambda' is not reserved and still overlong. TC39 and this list have been over this ground before. I don't see anything new in your post to change the outcome.

> This strawman is much more interesting because it is not just sugar.
> It introduces something JavaScript does not have now which is a real
> lambda and that could take JavaScript in positive directions in the
> future. Many syntax possibilities and macros need to desugar to a real
> lambda that obeys Tennent Correspondence Principle, correct? Opening
> that door for the future would be beneficial.

All true (and why I revived this idea as a strawman), but nothing to do with syntax.

> I'm understanding the intention of the strawman correctly?

What is the question? New semantics and syntax come in an integrated design. Pointing out "look, new semantics!" does not automatically argue that the syntax should revert to something (a) not reserved; (b) long-winded like bad old 'function'.


More information about the es-discuss mailing list