block lambda revival

Peter Michaux petermichaux at
Sat May 21 11:30:36 PDT 2011

On Sat, May 21, 2011 at 11:20 AM, David Herman <dherman at> wrote:
> Previously, you argued against the importance syntactic convenience, but it seems what you really were opposed to was a new function form that wasn't a true lambda. But now that there is one back on the table, you're OK with counting conciseness as a win.

I must not have been clear enough with what I wrote with regard to
conciseness. I wrote the following...

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

The "for those worried about character count" part was intentional and
did not include me with regard to reducing the length of function
literals. I don't see how that is motivation


> I don't mean to single you out on this-- it's a general phenomenon on es-discuss that really frustrates me. Design discussions are dysfunctional when they're treated as a zero-sum game between opponents. Design requires being honest about trade-offs. When people feel threatened that their concerns aren't being taken into account, they get defensive and start discounting others' concerns, and then the whole thing becomes a negative feedback loop.
> For my part, I will do my best to at least listen to people's concerns and register them as part of the equation, even if not every design can fulfill every constraint. I haven't always succeeded at that, but I'll do my best. I hope everyone will try to do the same.
> Dave
> 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 } )
>> 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".
>> 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.
>> 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.
>> I'm understanding the intention of the strawman correctly?
>> Peter

More information about the es-discuss mailing list