simple shorter function syntax

[Brendan Eich]

Deja vu, or as dherman tweeted, "Groundhog Day".

In case people don't know about it, there's an archive for this list, and it has a pretty complete (clumsy to search directly; use google site: search) but sporadically messed-up record of past discussions. Not to pick randomly, but December 2008 had both "Allen's lambda syntax proposal" / "Concise functions..." and "Proposal: Modify automatic semicolon insertion in strict mode".

 https://mail.mozilla.org/pipermail/es-discuss/2008-December/

The LL(∞) problem came up then:

https://mail.mozilla.org/pipermail/es-discuss/2008-December/008348.html
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008352.html

Braces on the outside can solve this lookahead problem, and another problem worth reiterating (below). My hope is that if we keep working over these issues, then we (like Bill Murray's character) will achieve enlightenment and our lambda "Groundhog Day" will end.

In this post:

https://mail.mozilla.org/pipermail/es-discuss/2008-December/008512.html

I mention a problem beyond LL(∞), which is bottom-up parsing ambiguity:

a => a ? f : x++
(0);

Note that PostFixExpression cannot be an unparenthesized callee in a CallExpression, only MemberExpression can be the callee Here, the whole C#-style lambda must be parsed as the callee being passed (0). If lambdas of any kind are not braced or otherwise parenthesized, they end with a low-precedence expression body and a top-down parser cannot decide correctly when that body should end. A bottom-up parser generator would complain about "reduce/reduce conflict".

Waldemar first pointed this out in

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007883.html

/be