On May 31, 2011, at 9:34 PM, Brendan Eich <[email protected]> wrote:
> On May 31, 2011, at 9:08 PM, Kam Kasravi wrote: > >> On May 31, 2011, at 2:55 PM, Brendan Eich <[email protected]> wrote: >> >>> On May 31, 2011, at 2:30 PM, Waldemar Horwat wrote: >>> >>>> I would not want to use anything like a PEG to standardize a grammar. >>>> Here's why: >>>> >>>> PEG being unambiguous by construction simply means that it resolves all >>>> ambiguities by picking the earliest rule. This turns all rules following >>>> the first one into negative rules: X matches Z only if it DOESN'T match a >>>> Y or a Q or a B or .... You could pick the same strategy to disambiguate >>>> an LR(1) grammar, and it would be equally bad. > > > [just noting you are replying to Waldemar's words here, not mine. /be] > >> PEGs use of ordered choice provides an opportunity to minimize backtracking, >> but it still backtracks given a nonterminal where the first ordered choice >> is incorrect. A PEG must return one parse tree or an error after potentially >> exhausting all choices (unlike GLR). > > Yes. The problem with PEGs is not ambiguity (multiple parse trees for one > sentence) but the negative-rule future hostility problem that Waldemar cited. > That is hard to see at any given instant. It comes up when evolving a > language. > > >> I believe there are differing motivations to pick a parser depending on your >> goals, if you're experimenting with the grammar or want a parser to >> transform an extended grammar then PEGs make alot of sense because they >> closely matche the BNF grammar and it's easy to introduce new grammar rules. >> It's likely PEGs could provide diagnostics related to LR(1) ambiguity, at >> least with pegjs it looks like this could be built into the algorithm. I >> understand the motivation to avoid any parser which tolerates ambiguous >> LR(1) grammars, but PEGs can be great tools given the LR(1) requirement is >> enforced. > > This matches Tom's testimony. > > At this point I'm working under assumption ES.next sticks with the LR(1) > grammar. First target: destructuring, using an extended Reference type. There > are alternatives (thanks to dherman for discussion today about this) but I > think this is the minimal patch to ES5. > > Arrow function syntax can be handled similarly, provided Expression covers > ArrowFormalParameters. But that is a strawman, so it'll go after > destructuring. There was no suggestion on my part to deviate from LR(1), rather provide some info on PEG parsers annd their ability to parse ECMA-262 5th Edition and some proposed strawmen extensions. Its valuable to know the strengths of different types of parsers and the types of parsers currently in action. Is it a given that the grammar extensions in the various strawmen are all LR(1)? > > /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
