Well, it's still context-free (contex-sensitive may have terminals on LHS too, JS cannot). It requires extra cover grammar, and additional static semantics, but still potentially can be parsed by a LALR/CLR parser - yes, you'll have to do parsed nodes reinterpretation in semantics handlers (e.g. validate and transform parsed ObjectLiteral into an ObjectPattern when parsing destructuring), but should be doable in general. It won't be doable if lookaheafs won't be enough, and only a backtracking can recover (like the cases with Flow parser).
Dmitry On Wed, Jan 11, 2017 at 6:09 PM Isiah Meadows <[email protected]> wrote: > Heuristically, I doubt it's even context-free at this point, considering > the concept and widespread prevalence of early errors now. I suspect it's > mildly context-sensitive (maybe tree-adjoining?), but I'm no formal > language expert here. > > > > On Wed, Jan 11, 2017, 14:23 Dmitry Soshnikov <[email protected]> > wrote: > > One yet has to check the pure ES6+ grammar to be LR(1) compatible (the > Cover grammar with nodes reinterpretations makes it harder), but for a very > practical use-case, e.g. combined with Flow, it'll not be easy to have an > automated parser (since Flow's parser uses backtracking for some edge cases > which is already not LR-parser). > > I have some subset of ES6 working as an example language for Syntax > tool[1] (since I just took a bunch of productions from JS), but I haven't > tried the full ES6 grammar (not having time to work on this project, since > it'll be not a straightforward process of just matching the grammar 1:1 to > the parser generator -- based on the above reasons). > > Long time ago I also had a brief discussion with authors of another > popular parser generators for JS. Both didn't try it as well, but mentioned > that even for ES5 it was hard to parse e.g. regexp, etc. > > Someone (with enough time for the project) should just sit, and spend some > time actually porting the grammar from the spec on some powerful parsers > generator. > > [1] Syntax: https://github.com/DmitrySoshnikov/syntax > [2] https://twitter.com/DmitrySoshnikov/status/666327209959751680 > > On Wed, Jan 11, 2017 at 10:28 AM, Michael Dyck <[email protected]> wrote: > > In the past, it has been said (usually by Brendan Eich) that TC39 intends > that the ECMAScript grammar be LR(1). Is that still the case? (I'm not so > much asking about the "1", but more about the "LR".) > > > > > > If so, I'm wondering how lookahead-restrictions (e.g., [lookahead <! > terminals]) fit into the LR approach. It seems like there are three > possibilities: > > > - modify the grammar (before the parser is constructed), > > > - modify the construction of the parser, and/or > > > - modify the operation of the parser. > > > It's not clear to me that any of these (or any combination of these) will > work. > > > > > > Has anyone algorithmically generated an LR parser from the spec grammar? > If so, how did you you handle lookahead-restrictions? > > > > > > -Michael > > > _______________________________________________ > > > es-discuss mailing list > > > [email protected] > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > _______________________________________________ > > > es-discuss mailing list > > > [email protected] > > > https://mail.mozilla.org/listinfo/es-discuss > > > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
