On May 13, 2011, at 2:52 PM, Brendan Eich wrote: > One might be tempted to make an unparenthesized (on the outside) function > expression with an unparenthesized expression body be a low-precedence > expression (say, AssignmentExpression), but then it can't be used as the > callee part of a CallExpression without being parenthesized. Such a > low-precedence function expression would have to be parenthesized with every > operator save comma.
CoffeeScript does something like this. It separates Invocation from Operation (both are Expressions, and an Operation combines Expressions using operators, sometimes with a narrower non-terminal than Expression on the left of a dyadic operator). Invocations can be chained but the basis case is a Value as callee nonterminal, and a Value must be parenthesized if it contains Code. The Code nonterminal produces a CoffeeScript function expression, with optional parenthesized parameter list, arrow (-> or =>), and a block body. The ECMA-262 grammar could be extended like this. It would mean -> and => as proposed in http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax would not be sugar for existing function expression (with .bind or some tamper-proof internal equivalent in the case of =>). But that seems better than requiring parentheses. This grammar interlude reminds me of the grammar dependency graphs at http://blog.nicksieger.com/articles/2006/10/27/visualization-of-rubys-grammar -- the Java and JavaScript grammars show the C-family expression sub-grammar-dependency tower (duplicated in JS's case due to the NoIn productions), with all those precedence levels we know and love. Ruby has a flatter graph with a popular "primary" non-terminal in the middle. http://www.flickr.com/photos/nicksieger/280661836/sizes/o/in/photostream/ (warning: BIG) I'll update http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax to include an ES5 grammar patch. The Ruby-ish block (Allen's lambda syntax proposal) approach has to be considered, still, since it has braces around the outside and avoids all this grammar hacking. The downside is an empty "block" has to be distinguished from an empty object initialiser (from an empty block statement :-P). That may not be a big downside as Allen noted, although I don't think undefined or null can stand in for empty block. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
