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
staging.
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,
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
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:
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
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!
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
