On Jun 28, 2011, at 3:10 PM, Brendan Eich wrote:
> Block:
> { UnlabeledStatementFirstList }
> { WellLabeledStatement StatementList? }
>
> UnlabeledStatementFirstList:
> UnlabeledStatement
> UnlabeledStatementFirstList Statement
>
> Statement:
> UnlabeledStatement
> LabeledStatement
>
> UnlabeledStatement:
> Block
> VariableStatement
> EmptyStatement
> ExpressionStatement
> ContinueStatement
> ReturnStatement
> LabelUsingStatement
> DebuggerStatement
>
> LabelUsingStatement:
> IfStatement
> IterationStatement
> BreakStatement
> WithStatement
> SwitchStatement
> ThrowStatement
> TryStatement
>
> LabeledStatement:
> Identifier : Statement
>
> WellLabeledStatement:
> Identifier : LabelUsingStatement
> Identifier : WellLabeledStatement
>
> ...
> If I have this right, then we could add a new production:
>
> PrimaryExpression:
> Block
This creates an LR(1) ambiguity, a shift-reduce conflict between shifting : in
WellLabeledStatement : Identifier.: LabelUsingStatement
WellLabeledStatement : Identiifer.: WellLabeledStatement
and reducing on : lookahead via
PropertyName : Identifier.
under PropertyAssignment under ObjectLiteral.
(The dots in the productions are yacc/bison-style cursors showing where the
parse is.)
One easy fix is to "de-minimize" the PropertyAssignment grammar:
PropertyAssignment:
PropertyName : AssignmentExpression
get PropertyName ( ) { FunctionBody }
set PropertyName ( PropertySetParameterList ) { FunctionBody }
PropertyName:
IdentifierName
StringLiteral
NumericLiteral
to look like this:
PropertyAssignment:
IdentifierName : AssignmentExpression
StringLiteral : AssignmentExpression
NumericLiteral : AssignmentExpression
get PropertyName ( ) { FunctionBody }
set PropertyName ( PropertySetParameterList ) { FunctionBody }
PropertyName:
IdentifierName
StringLiteral
NumericLiteral
This works because the lookahead after : in this revised PropertyAssignment and
in WellLabeledStatement is disjoint except for { and that loops back through
the same paths, with the tie broken by a disjoint lookahead token, eventually.
Is this grammar refactoring worth the trouble? Making blocks be expressions
could be well worth it if we accept block-lambdas. Just for statements as
expressions, I'm not sure. Comments welcome.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
