ES parsing tools (Re: Short Functions)

Kam Kasravi kamkasravi at yahoo.com
Sun May 29 19:35:20 PDT 2011


Does Waldemar still maintain the tool? the source dates seemed fairly old...

On May 29, 2011, at 12:21 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On May 29, 2011, at 2:11 AM, Claus Reinke wrote:
> 
>> tl;dr:
>>   - JS-based PEG + ANTLR as a route for ES grammar experiments
> 
> Mark and Tom already use Ometa at a code.google.com project, as noted. What more do you want?
> 
> This does *not* address the issue of a usable spec grammar that can be validated (my point (a)). In spite of over a thousand words and many paragraphs in reply :-/.
> 
> 
>>   - would like to know about route viability and alternative routes
> 
> Tom testified to slowness. Mark and Tom being on TC39 does *not* address the "implementor acceptability" (my point (b)) of Ometa, which is nearly nil.
> 
> 
>> The relation to the current topic is that ANTLR's LL(*) parsing [1]
>> aims to generalize and optimize PEGs and related formalisms
>> typical for top-down parsers (while GLR and bison are typical for
>> bottom-up parsers, which are not relevant for ES implementations,
>> according to your information).
> 
> The ECMA-262 spec uses LR(1), and ES3's grammar was validated by Waldemar using his custom common lisp program, source available in the old Mozilla CVS repo:
> 
> http://mxr.mozilla.org/mozilla/source/js2/semantics/
> 
> Changing to something new is certainly possible, but we need at least "that much" validation (what Yacc calls shift/reduce and reduce/reduce conflict detection).
> 
> Top-down formalisms may not be suitable if they do not check for ambiguities and rule them out. To quote from Waldemar on this list in October 2008,
> 
> "This is why ambiguous grammars are bad and unsuitable for our spec.  In an unambiguous grammar, if you find a series of production expansions that matches a source program, then you know that those are the expansions that will be taken.  In an ambiguous grammar, you also need to prove the negative: no *other* expansion can match that source program and shadow your expansions.  Proving the negative causes trouble because a language extension could turn the mismatch into a match and because sometimes[...], you expected some other part of the grammar to shadow your expansions but it didn't."
> 
> At this point, I'd like to plead for fewer words and aspirational statements, and more concrete details about validation against ambiguity in the system(s) you are proposing.
> 
> 
>> The postings which triggered my inquiry were authored by
>> coders not implementing the major ES engines, but by ES
>> implementers nevertheless.
> 
> If you mean Mark and Tom, please say so. They did not implement a performant JS engine, so that's not helpful for point (b). Last time I'll say this, please don't rehash.
> 
> Many people are playing with JS parsers, testing extensions, building transpilers. That's all great, but it does not address the spec issue, specifically both points (a) and (b).
> 
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110529/44e40df0/attachment-0001.html>


More information about the es-discuss mailing list