Allen's lambda syntax proposal

Peter Michaux petermichaux at
Sun Nov 30 01:54:44 PST 2008

On Sun, Nov 30, 2008 at 12:46 AM, Brendan Eich <brendan at> wrote:
> 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?

Currently it is relatively common to reassign to a variable holding a
reference to a function. I don't know of cases where I want to assign
an integer to a variable that references a function; however,
reassigning a function to a variable referencing a function is common.

// file 1 : the program

var foo = function() {}

// file 2 : the debugging program

var foo = (function() {
  var original = foo;
  return function() {
    return original();

I wrote a layered XMLHttpRequest library which used the above idea of
wrapping and reassigning.

There is also the lazy function definition pattern.

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

It isn't necessary to start with a Greek letter-name keyword. It could be

b, c) {...}

Hey, you said this thread was for fun! ;-)

All I meant was that if there was a short form

  var foo(a, b, c) {...}

there would still need to be a lambda expression.

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

It is no different in the amount of typing. Both




both take only two characters (e.g. ell tab) to type in any editor
with snippets.

Even without snippets, I simply don't think "lambda" is very long. In
fact, 99% of the time I type "function() {};" manually because I
rarely remember eff tab will do the same thing for me and it doesn't
bother me at all.

> and obscure to some

Yes obscure at first but once they learn about lambda and its history,
don't you think they will cherish the privilege to use it?

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

I like the "lambda" version and think the syntax fits in nicely and
shows how lambdas and functions are related semantically.

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

They do?!

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

Yes it could be different. Since Java has dispatch on argument type
and hence can have multiple constructors, it wouldn't make much sense
to have class(){} in Java.

> 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),

I agree with this requirement. I'm not in favor of type-checking
because I don't think it will work well in ES (not even as well as it
doesn't work in other languages) but it will be interesting to see how
type-checking is proposed to work with this requirement.

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



More information about the Es-discuss mailing list