block lambda revival

Rick Waldron waldron.rick at
Sat May 21 07:56:25 PDT 2011


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 } )
             ^               ^

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?

Thanks in advance!


On Sat, May 21, 2011 at 10:37 AM, Brendan Eich <brendan at> wrote:

> On May 21, 2011, at 7:31 AM, Rick Waldron wrote:
> At the very bottom, there is a note that says:
> "With GLR parsing for the spec grammar, we could consider, e.g. (x) {x} instead
> of {|x| x} with *LineTerminator* excluded between parameters and body."
> FWIW, Speaking from a developers perspective, the syntax: (x){x} , has a
> very familiar voice that I'm confident would find immediate acceptance and
> fast adoption (I know this because it's recently been discussed by myself
> and several different groups of my developer peers)
> The problem is ambiguity:
>   b = a.forEach (x) { x * x }
> looks like a call, a.forEach(x), whose return value is assigned to b, where
> the assignment expression is followed by a block statement on the same line,
> a syntax error currently.
> The restriction that ) and { are on the same line is necessary for this to
> be a backward-compatible extension, but it doesn't help the parsing
> ambiguity.
> Putting block parameters on the inside of the { }, even though that
> requires | | or a longer way of bracketing the parameters, does not
> introduce this ambiguity.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list