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

Jeff Dyer jodyer at
Tue Mar 20 16:38:30 PDT 2007

> From: lars.t.hansen at [mailto:lars.t.hansen at] 

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

The => is a deal breaker for me. It looks foreign in the context of the
function keyword.

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

Let expressions strengthen the case for statement-less function
expressions. But let's be clear, both new forms exist for aesthetics
only. They do nothing that isn't already being done by ES3 function

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

Good point. 

> --lars

More information about the Es4-discuss mailing list