Expression closures - use-cases for shortcut lambda syntax(blocks)

Lars T Hansen lth at
Tue Mar 20 13:53:01 PDT 2007

On 3/19/07, Brendan Eich <brendan at> wrote:

> Anyway, I'd like to hear Lars's preference, but I don't
> think consistency favors one outcome, and brevity can't always win
> (we're talking JS here, not C/C++/Java/C#).

gmail threading is pretty much broken so I don't quite know where all
of this stands as of now, but for the record I pretty much loathe
these proposals :-)

As far as I'm concerned if it doesn't start with "function" it's a
non-starter, because the terse syntax isn't worth the cost.  The
brevity of anything else doesn't actually pay off (none of the
examples posted convince me).

I'm not even sure that expression functions of the form "function (a)
a*2" are really worth it, but at least I'll concede that we agreed to
put those in.  I doubt it makes any difference at all whether one
writes "function (x) 37" or "function (x) => 37"; I think they're both
slightly inferior to "function (x) { return 37 }".

Note I'm not opposed to punctuation / special syntax in general; the
object/array initializers are obviously better than their more
"general" counterparts.  I'm just not convinced that that's the case
for function expressions, which are already quite succinct in ES3.

(Also, unless I'm mistaken something like the proposed
"(a,b,c,d,e,f,g,h,i,j) => 37" requires arbitrary lookahead in a
top-down parser, and I thought we were trying to avoid that.  I
understand it can be fixed in the same way we fix destructuring
assignments, but it makes me uneasy, as the arbitrary lookahead is
also required by the human reader.  At least for destructuring the
major use cases are in binding forms, not really in plain


More information about the Es4-discuss mailing list