Allen's lambda syntax proposal

Brendan Eich brendan at
Sun Nov 30 00:46:25 PST 2008

On Nov 30, 2008, at 12:28 AM, Peter Michaux wrote:

> On Sat, Nov 29, 2008 at 11:53 PM, Brendan Eich <brendan at>  
> wrote:
>> On Nov 29, 2008, at 11:33 PM, Peter Michaux wrote:
>>> This would allow writing
>>> var foo = {|a, b, c| ...};
>>> which could be written even shorter as
>>> var foo(a, b, c) {...};
>> Why ever would you want to use 'var' there? Could foo be reassigned  
>> to
>> denote 42, or "hello"?
> Yes it could be reassigned.

You didn't say why, though -- what is the use-case?

>>> The later is more consistent with the following which would also be
>>> necessary at times.
>>> lambda(a, b, c) {...}
>> Necessary for what use-case?
> I believe the same ones as for {|a, b, c| ...}. For example, if one
> wants to pass an anonymous lambda to another lambda.

But why do you need to start such a lambda *expression* with a Greek  
letter-name keyword?

Function expressions and definitions in ES3 start with 'function',  
true enough. Allen's lambda syntax is simply an alternative proposal  
for the expression case. It doesn't make a compound lambda + binding  

> lambda(a, b, c) {...}
> function(a, b, c) {...}
> class(a, b, c) {...}
> Especially the syntax for lambda and function declarations seem as
> though they should be symmetrical because they will be called the same
> way: "foo()".

This seems good as far as it goes, but the 'lambda' keyword is  
overlong and obscure to some (I already agreed with you that it's le  
mot juste in a previous thread; but Allen's proposal avoids any mot at  
all, in favor of punctuation).

But why have three defining forms for callables? Sure, compatibility  
may require two. But three? The weakest link here is class, without  
more motivation (which I believe exists, see below).

> This also makes me thing that class's should be called
> the same way. That is, the "new" should be optional just like it is
> for Array constructor, for example.

Some constructors behave differently when called. This could be  
considered a rare quirk but (1) people like doing it in their own  
abstractions; (2) it's desirable for self-hosting the quirky built-ins.

But again, a class is not just another kind of function. It's a higher- 
integrity factory for higher-integrity instances. Whether one calls it  
via new or directly as a function is secondary. Its syntax can differ  
from function if necessary (not gratuitously).

IOW I think your argument oversimplifies.

I believe that TC39 agrees that classes should be generative (nesting  
a class in another class or function makes a new, distinct class  
"type" on each evaluation), and (unrelated point) optionally anonymous  
as your list shows. But this does not follow simply from borrowed/ 
desugared-to function syntax or semantics.  Classes may grow hair that  
functions won't, and lambdas must not (if they are to be worthy of the  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list