On Oct 20, 2011, at 12:31 AM, Andreas Rossberg wrote: > One concern might be that we probably cannot make arrow notation (if > we introduce it) a primary expression, and it might be confusing if > they have different precedence.
We absolutely cannot and the strawman specifies the grammar fully: http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax AssignmentExpression : ArrowFunctionExpression ... ArrowFunctionExpression : ArrowFormalParameters_opt Arrow AssignmentExpression ArrowFormalParameters_opt Arrow ArrowBodyBlock_opt ArrowFormalParameters : ( FormalParameterList_opt ) ( this Initialiser_opt ) ( this Initialiser_opt , FormalParameterList ) Arrow : one of -> or => Arrow function expressions must be low precedence, unparenthesized on the right of assignment operators. > I also think it is easier to parse for the human reader when he sees > > (function f() { ... })() > > instead of > > function f() { ... }() > > especially when this occurs as a statement. (Mh, actually, could we > even distinguish between function declerations and expression > statements starting with a function expr in LALR(1), without heavy > grammar transformation?) The grammar currently uses a lookahead restriction to disambiguate in favor of function declaration: 12.4 Expression Statement Syntax ExpressionStatement : [lookahead ∉ {{, function}] Expression ; NOTE An ExpressionStatement cannot start with an opening curly brace because that might make it ambiguous with a Block. Also, an ExpressionStatement cannot start with the function keyword because that might make it ambiguous with a FunctionDeclaration. /be > > /Andreas > > On 20 October 2011 01:20, Brendan Eich <bren...@mozilla.com> wrote: >> On Oct 19, 2011, at 3:29 PM, Allen Wirfs-Brock wrote: >> >> On Oct 19, 2011, at 2:53 PM, Brendan Eich wrote: >> >> On Oct 19, 2011, at 8:16 AM, Allen Wirfs-Brock wrote: >> >> Function expressions were added in ES3. Were they just added at the wrong >> place in the grammar? >> >> Thanks for raising this, I keep forgetting to. >> Oddly enough, SpiderMonkey always had them (prior to ES3 even being drafted) >> as PrimaryExpressions. No one can observe the difference, as you note. >> Either way, one can write >> var fun_member = function () {}.member; >> On aesthetic grounds, I would prefer the grammar to make function >> expressions primary. >> >> Good, I want to make that change because for semantic specification purposes >> FunctionExpression works better as PrimaryExpression. >> I just wanted to make sure, before I make the change, that there wasn't some >> grammatical subtlety I was overlooking >> >> Toy grammar (| is meta, other punctuators after the : are concrete): >> E: ME >> ME: PE | FE | ME [ E ] | ME . ID | ... >> PE: ( E ) | ... >> and there's no way that ME -> FE would be reduced where ME -> PE -> FE was >> not possible, *and* there are no PE occurrences on the RHS of a production >> whose LHS is *not* ME, then FE can move "down" one precedence level from >> being the sole RHS part of ME, to being the sole RHS of PE. >> (Lotta abbreviation there, sorry.) >> Trivial search shows PrimaryExpression occurs in only one RHS, as the sole >> RHS part produced from MemberExpression. >> /be >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
