Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

Brendan Eich brendan at mozilla.com
Thu Jun 30 15:58:14 PDT 2011


On Jun 30, 2011, at 3:47 PM, Brendan Eich wrote:

>> Statement:
>>    UnlabeledStatement
>>    LabeledStatement
>> 
>> UnlabeledStatement:
>>    Block
>>    VariableStatement
>>    EmptyStatement
>>    ExpressionStatement
>>    ContinueStatement
>>    ReturnStatement
>>    LabelUsingStatement
>>    DebuggerStatement
>> 
>> LabelUsingStatement:
>>    IfStatement
>>    IterationStatement
>>    BreakStatement
>>    WithStatement
>>    SwitchStatement
>>    ThrowStatement
>>    TryStatement

I forgot to move Block from UnlabeledStatement to LabelUsingStatement. You can label a block. It's something people do now for break to label. And with the revisions below, it does not create any ambiguity.

/be


>> 
>> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list