Kevin Smith wrote:
LR(1) is for granddads ; )
Knuth. Respect.
This is really sexy.
Question: for ShortFunctionExpression, do we need an additional "=>"
form for this-binding a function body?
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here]
{ FunctionBody }
Identifier_opt ( FormalParameterList_opt ) => { FunctionBody }
We could do that and leave the arrow-free form with unbound |this|.
Better by my argument that anything based on today's function body-plan
should not start adding TCP conformance -- need new (fat arrow if not
freaky-deaky) syntax for new semantics (some or all of TCP).
/be
Identifier_opt ( FormalParameterList_opt ) => InitialValue
Thanks,
kevin
On Fri, Mar 9, 2012 at 3:17 AM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
We could add such an ad-hoc-GLR-like algorithm to ECMA-262, but we
would lose the LR(1) (modulo ASI and lookahead restrictions, and
the conventional shift-reduce conflict resolution for dangling
else) validation I wrote about. That's considered unacceptable by
TC39 members who spoke up last time we talked about this.
But let's say we find a way forward on the validation front. Can't
assume this (paging Waldemar) but for now let's waive it.
Then the grammar would look something like this:
FunctionDeclaration:
function Identifier ( FormalParameterList_opt ) { FunctionBody }
Identifier ( FormalParameterList_opt ) [no LineTerminator here]
{ FunctionBody }
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator
here] { FunctionBody }
Identifier_opt ( FormalParameterList_opt ) => InitialValue
Fat-arrow binds lexical |this| as in CoffeeScript and all
right-thinking languages :-P.
Change AssignmentExpression like so:
AssignmentExpression:
ConditionalExpression
LeftHandSideExpression = InitialValue
LeftHandSideExpression AssignmentOperator InitialValue
AssignmentExpressionNoIn:
ConditionalExpressionNoIn
LeftHandSideExpression = InitialValueNoIn
LeftHandSideExpression AssignmentOperator InitialValueNoIn
And change all uses of /AssignmentExpression/ outside of the
/Expression/ sub-grammar to /InitialValue/:
ElementList : // See 11.1.4
Elision_opt InitialValue
ElementList , Elision_opt InitialValue
PropertyAssignment : // See 11.1.5
PropertyName : InitialValue
ArgumentList : // See 11.2
InitialValue
ArgumentList , InitialValue
Initialiser : // See 12.2
= InitialValue
InitialiserNoIn : // See 12.2
= InitialValueNoIn
The cherry on top is the new InitialValue production:
InitialValue :
AssignmentExpression
ShortFunctionExpression
This avoids precedence inversion and restricts short function
expressions to appearing unparenthesized only where initial values
may occur today (in array and object literals, in argument lists,
on the right of assignment operators, and in variable initialisers).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
