Kevin Smith wrote:
If I understand correctly, it's still an open question whether parsing
() => {} is feasible or not using a recursive top-down parser.
Is that right?
No. Top down parsers can be hacked to do a great many things. What we
seek is a grammar that can be parsed by a well-established algorithm and
validated as unambiguous -- only one parse tree for a valid sentence.
ES3's grammar was validated using LR(1) plus ASI and lookahead
restrictions, automatically (Waldemar's Mac Common Lisp code at
cvs.mozilla.org/mozilla/js2/semantics).
Failure to disambiguate can paint us into painful corners in the future.
Ambiguous grammars are "easy" to parse using top-down LL(1)-equivalent
techniques -- many people write recursive descent parsers for ambiguous
grammars and think everything's great, until it isn't.
That's one issue.
Another which I cited just a few messages back: parsing ( params ) as (
expr ), as any top down parser must until it gets to an arrow or other
distinguishing token ({ on same line as ), e.g.), can be considered
future-hostile. params should be declarative, but expr must now cover
all future declarative syntax, including optional guards.
At the limit, the grammar would become a loose "cover grammar" and
semantic validation of the parse tree produced for either (expr) or
(params)->... would be required. That would be a mistake. We want a
fairly tight grammar, with only a few simple semantic validation steps
required by runtime or mandated as early errors (e.g. return from
non-function, illegal LHS of assignment).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
