ES parsing tools (Re: Short Functions)

Tom Van Cutsem at
Tue May 31 18:56:18 PDT 2011

I just wanted to provide a bit more context on our Ometa experiment: our
goal was to build an executable parser whose definition was as close as
possible to the BNF in the ES5 spec, which worked out fairly well. The main
purpose of the tool was to be able to quickly experiment with syntax
extensions, but it has never been our goal to have this tool be a
"production-quality" JS parser.

For rapid prototyping, Ometa is a marvelous tool. I liked it a lot.
Performance-wise, I have not pitched it against other JS parser generators
(I actually don't know of many others).

In terms of grammar validation, Ometa is fairly weak. We did at one point
get Alex Warth to implement an exclusive choice operator "||", in addition
to the standard PEG prioritized choice ("|" operator in Ometa), as a tool to
help us get more confidence in the grammar. However, the implementation of
that operator is naive and slow (as testified here: <>).

2011/5/29 Brendan Eich <brendan at>

> On May 29, 2011, at 12:21 PM, Brendan Eich wrote:
> Mark and Tom already use Ometa at a 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 :-/.
> To say a bit more, in a  more positive tone: I agree that deterministic
> choice is attractive considered in a vacuum, to avoid ambiguities and better
> match how hand-crafted recusrive descent parsers are written. So PEG or
> stronger is plausible when experimenting, no argument there. Mark and Tom's
> choice to use Ometa for their language lab seems fine.
> Recasting the ECMA-262 specification's unambiguous (after ASI, and assuming
> ES5 added no ambiguities to ES3) LR(1) grammar using a PEG could be tried
> and evaluated. I would be interested in seeing a no-other-changes
> translation of the spec grammar into a PEG that is validated somehow.
> Here the issue is not validation against ambiguity, since the PEG is
> unambiguous because of ordered choice. The validation we'd need would be
> that both grammars produce sentences only and exactly in the same language.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list