Does Waldemar still maintain the tool? the source dates seemed fairly old...
On May 29, 2011, at 12:21 PM, Brendan Eich <bren...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
