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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
