ES parsing tools (Re: Short Functions)
brendan at mozilla.com
Sun May 29 12:21:26 PDT 2011
On May 29, 2011, at 2:11 AM, Claus Reinke wrote:
> - 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 
> 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:
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss