arrow syntax unnecessary and the idea that "function" is too long

Brendan Eich brendan at mozilla.com
Sun May 15 11:42:25 PDT 2011


Ok, final and most delicate part of the mission here: allow (v) -> {k: v} and even -> {} to return objects, not make useless block statements.

// Expression bodies needs no parentheses or braces
let identity = (x) -> x;
 
// Fix: object initialiser need not be parenthesized, see Grammar Changes
let key_maker = (val) -> {key: val};

Thanks to Doug for pushing on this idea. I believe that it is sound (still to be formalized and tested mechanically) in a bottom-up parser.

The top-down approach by default is to parse a cover grammar until an unambiguous decision point is reached, then depending on the decision, rewrite the AST (e.g., to make a labeled statement in a block instead of an object initializer).

/be

On May 15, 2011, at 10:26 AM, Brendan Eich wrote:

> On May 14, 2011, at 11:33 PM, Brendan Eich wrote:
> 
>> Grammar Changes

To enable unparenthesized ObjectLiteral expressions as bodies of arrow functions, without ambiguity with Block bodies, restrict LabelledStatement as follows:

LabelledStatement :
    Identifier : LabelledStatement
    Identifier : LabelUsingStatement

LabelUsingStatement :
    NonEmptyBlock
    IfStatement
    IterationStatement
    BreakStatement
    SwitchStatement
    TryStatement

NonEmptyBlock :  // See 12.1
    { StatementList }
The resulting grammar should be unambiguously LR(1) (ignoring ASI), because { L: expr...} can parse only as an ObjectLiteral, and { L: { if (cond)... } } or similar LabelUsingStatement variations can parse only as a LabelledStatement.

TODO: evaluate top-down parsing difficulty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110515/9a011a7d/attachment.html>


More information about the es-discuss mailing list