<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 29, 2011, at 2:11 AM, Claus Reinke wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>tl;dr:<br>   - JS-based PEG + ANTLR as a route for ES grammar experiments<br></div></blockquote><div><br></div>Mark and Tom already use Ometa at a <a href="http://code.google.com">code.google.com</a> project, as noted. What more do you want?</div><div><br></div><div>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 :-/.</div><div><br></div><div><br><blockquote type="cite"><div>   - would like to know about route viability and alternative routes<br></div></blockquote><div><br></div>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.</div><div><br></div><div><br></div><div><blockquote type="cite"><div>The relation to the current topic is that ANTLR's LL(*) parsing [1]<br>aims to generalize and optimize PEGs and related formalisms<br>typical for top-down parsers (while GLR and bison are typical for<br>bottom-up parsers, which are not relevant for ES implementations,<br>according to your information).<br></div></blockquote><div><br></div>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:</div><div><br></div><div><a href="http://mxr.mozilla.org/mozilla/source/js2/semantics/">http://mxr.mozilla.org/mozilla/source/js2/semantics/</a></div><div><br></div><div>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).</div><div><br></div><div>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,</div><div><br></div><div><span class="Apple-style-span" style="font-family: monospace; ">"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."</span></div><div><br></div><div>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.</div><div><br></div><div><br></div><div><blockquote type="cite"><div>The postings which triggered my inquiry were authored by<br>coders not implementing the major ES engines, but by ES<br>implementers nevertheless.</div></blockquote><div><br></div>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.</div><div><br></div><div>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).</div><div><br></div><div>/be</div></body></html>