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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
