optional "function" keyword

Brendan Eich brendan at mozilla.org
Fri Mar 9 14:06:47 PST 2012

Kevin Smith wrote:
>     Anyway, I'm still trying to get something for shorter function
>     syntax into ES6. I think TC39 can yet make an exception if we have
>     our validation story figured out. That is where to focus fire.
> Must it be LR(1), then?  I don't think an LR parser can handle short 
> functions (or arrows) as we've laid them out.  Essentially, we can't 
> reduce *anything* until we know whether we're trying to parse an ( 
> Expression ) or a ( FormalParameterList ).  Same goes for Dart.

If Expression covers FormalParameterList then LR(1) is enough -- we'll 
know when we see that arrow (or { on same line as the ) before it). This 
is considered somewhat future-hostile by some on TC39.

If we bought into GLR (what I think you mean in your next post by NLR) 
then no problemo!

LR(1) is well-understood and safe. Committees do well by being 
conservative. We have enough in the way of exceptions on top: ASI, 
operand/operator role change for /, restricted productions, -NoIn 
productions, and dangling-else disambiguation (easy but it's on the list).

> And yet my intuition tells me it's unambiguous nonetheless (or that it 
> can be, if the grammar is constructed with care).
Intuition is not as reliable as a validated-unambiguous grammar. We had 
let-expressions and expression closures in ES4, both ran into trouble 
even though "intuitive".

> I think that the procedure I outlined yesterday can be implemented 
> efficiently, especially for the expected case where a parameter list 
> is short (e.g. not the length of the entire file).  And since the 
> source code of every parsed function has to stay in memory anyway (via 
> Function.prototype.toString), I don't think the arbitrary lookahead 
> imposes additional restrictions there.

The cover grammar approach works too and requires only some AST-label 

> Given this situation, what kind of validation story would be sufficient?
If we buy into the cover grammar approach, used so far in ES6 drafts 
(see "Supplemental Syntax"), then we still have some trouble if we want 
to prefer

   (x,y) => {p:x*y} // return an object literal

over parsing the body as a block statement. The problem is that the p: 
looks like a label. For the arrow function syntax strawman,


I wrote a two-token lookahead restriction. It seemed simpler than 
alternatives, but it's a step up from k=1 lookahead.

An alternative, mostly-compatible change I drafted:


The fundamental trade-off remains: object literals cannot grow extra 
features (~ or ~ prefixes to property names, e.g.) that make them 
ambiguous with block statements. This restriction is arguably not 
future-hostile, rather user-friendly!


More information about the es-discuss mailing list