May 24-26 rough meeting notes

Kam Kasravi kamkasravi at yahoo.com
Tue May 31 22:07:41 PDT 2011



On May 31, 2011, at 9:34 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On May 31, 2011, at 9:08 PM, Kam Kasravi wrote:
> 
>> On May 31, 2011, at 2:55 PM, Brendan Eich <brendan at mozilla.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110531/122c94db/attachment.html>


More information about the es-discuss mailing list