return when desugaring to closures
Maciej Stachowiak
mjs at apple.com
Thu Oct 16 19:29:56 PDT 2008
On Oct 16, 2008, at 7:01 PM, Brendan Eich wrote:
> On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote:
>
>> On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote:
>>
>>> I don't think you can come up with a consistent "shift" or
>>> "greedy" notion.
>>
>> Funny, yacc has had one for decades, used to resolve dangling-else.
>
> Which ES1-3 also use:
>
> 12.5 The if Statement
> Syntax
> IfStatement :
> if ( Expression ) Statement else Statement
> if ( Expression ) Statement
> Each else for which the choice of associated if is ambiguous shall
> be associated with the nearest possible if that would otherwise have
> no corresponding else.
>
> The grammar is not enough in ES3 without let expressions. You need
> at least this shift-reduce conflict resolution rule (I'm ignoring
> ASI, / as division vs. regexp delimiter, etc.). Adding let
> expressions does not add novel requirements for extra-grammatical
> disambiguation rules.
>
> The ambiguity between blocks and object initialisers is another well-
> known case, resolved by "negative lookahead":
>
> 12.4 Expression Statement
> Syntax
> ExpressionStatement :
> [lookahead ∉ {{, function}] Expression ;
This one can be solved without negative lookahead, we have separate
NoBF (no brace or function) and NoIn productions in our grammar to
solve these without ambiguity:
Expr:
AssignmentExpr
| Expr ',' AssignmentExpr
;
ExprNoIn:
AssignmentExprNoIn
| ExprNoIn ',' AssignmentExprNoIn
;
ExprNoBF:
AssignmentExprNoBF
| ExprNoBF ',' AssignmentExpr
;
With the NoIn / NoBF variants propagated through the rest of the
grammar if needed. Kind of brute force, but it does the job without
ambiguity. JavaScriptCore's grammar runs through bison with no shift/
reduce or reduce/reduce conflicts.
I think it might be better to write the official ES3.1 grammar in this
way, even though it is a little annoying and repetitive, so it can
more readily be verified that the language grammar has no ambiguities
by running through a parser-generator like yacc or bison or
boost::spirit.
As to the else issue, I don't think that ambiguity can be avoided, but
bison lets you solve that with %nonassoc, which is a sound
disambiguation mechanism.
Regards,
Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20081016/4ccb70d1/attachment.html
More information about the Es-discuss
mailing list