Block lambda is cool, its syntax isn't

Sam Ruby rubys at
Fri Jan 13 03:30:18 PST 2012

On Fri, Jan 13, 2012 at 12:20 AM, Brendan Eich <brendan at> wrote:
> We have three coarse-grained alternatives:

If you are going to enumerate all potential alternatives (including
ones that you need to be rejected for one reason or another), then a
CoffeeScript inspired syntax should be included:

  (params) -> {body}

- Sam Ruby

> 1. λ  (params) { body }
> 1a. One problem is what should we use for λ? 'lambda', 'block', etc. are not
> reserved the syntax. Whatever the identifier (including Greek lambda: λ),
> this is an incompatible change.
> 1b. Another problem: this form looks like a function expression with a
> different introductory keyword, but Tennent's Correspondence Principle makes
> the meaning of body elements including |this| and return/break/continue
> radically different. Different-enough semantics should have different
> syntax.
> 2. { (params) body }
> Putting the parameter list in parentheses is more consistent with function
> syntax, while putting the parameters on the inside stresses the block-ness
> over function-ness. By block-ness I mean (ignoring let, const, and function
> in Harmony) how code and {code} are equivalent.
> Of course this cuts against the syntax too: block statements are not
> first-class callables whose code bodies are evaluated only if invoked, they
> are statements evaluated eagerly when reached. This syntax is arguably too
> block-like.
> A point that I remember having come up in past TC39 meetings: if we ever
> want structuring forms (object literals or destructuring patterns) that use
> () for grouping property names, this syntax is future hostile.
> 3. { |params| body }
> This is new-to-JS, idiomatic block-like -- but not too block-statement-like
> -- syntax for novel body semantics.
> The bars will drive some people to distraction. Others will grok, or already
> do via Ruby. This is not to favor Ruby, just to build on the belief that
> some precedent in language design is better than none.
> We could reject (3) in favor of (2) if we had an overriding non-aesthetic
> reason. I don't see one.
> Aesthetics vary. The more conventional look of (2) seems like a usability
> hazard to me, which trumps aesthetics. Again I'd rather have something more
> different-looking to signal the novel application of TCP.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list