block lambda revival

Brendan Eich brendan at
Sat May 21 08:05:48 PDT 2011

On May 21, 2011, at 7:56 AM, Rick Waldron wrote:

> Brendan, 
> Thanks for the clarification on that. 
> I've been following the shorter function syntax discussions pretty closely, as well as reading the strawman proposals, so please forgive me if this has been addressed or refuted.
> Given your example: b = a.forEach (x) { x * x } And the issues you noted there, would the same issues apply here:
> b = a.forEach( (x) { x * x } )
>              ^               ^

That thought has occurred to several people but then it looks like a block erroneously run up against a.forEach, where inside the block (the outer braces) there's a parenthesized expression run up against an inner block containing an expression.

Note how the inner braces are not necessary.

We could make this work but it would risk turning what might be an easy error, losing a newline between a.forEach and a braced block, into something that runs and has very different meaning. Another possible error: losing ( and ) around an object literal passed to a.forEach.

> Maybe unrelated:
> Is b = a.forEach (x) { x * x } meant to illustrate a general syntax ambiguity? Perhaps I'm missing a piece of the puzzle  because forEach has a second, optional thisArg param - how would that be included?

My thinking is: write a second block argument:

  b = a.forEach {|x| self.list.push(x * x); } {self}

where self is the |this| parameter to pass.

The ambiguity requiring GLR parsing is that (a, b) is a comma expression and a formal parameter list (the two syntaxes overlap but formal parameters may want "more syntax", e.g. guards, destructuring shorthand, parameter default values with larger syntax than nested assignment expressions cover, etc.). A parser can't decide until the restricted {...} is parsed fully. That requires GLR or equivalent.


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

More information about the es-discuss mailing list