ES parsing tools (Re: Short Functions)

Brendan Eich brendan at
Sat May 28 07:42:08 PDT 2011

On May 28, 2011, at 1:56 AM, Claus Reinke wrote:

> If OMeta's should really be slower than similar parsers, and
> the grammar-optimizing side is covered by the authors,
> perhaps there is room for old-fashioned JS code optimization?
> For instance, OMeta/JS is not the main line of OMeta code,
> and code that is idiomatic in another language might be
> less than optimal if moved to JS.

Does this line of inquiry do anything for (a) the spec grammar needing validation (no ambiguities); (b) implementor acceptability?

I don't see how (a) is served. Please correct me if I'm missing something.

The answer to (b) is "no". Implementors use tuned hand-crafted top-down parsers, not Ometa or anything like it.

> Btw, it would be nice to have an es-tools-discuss list, where
> one could discuss ES implementation and tooling issues
> (preferably with the engine implementers listening in).
> Does such a list exist?

No, we're not going to split this list. Volume is up lately but nowhere near fatally high, and topics interconnect.

Researching JS parsing is probably better done in a research setting. Talking about it here in open-ended ways doesn't help make near-term progress in the standardized language. Having a more closed or "done" solution that addresses (a) and (b) above would help, though.

I'm not against research (Mozilla funds research), and we do need better methods over time. But developing them is specialized work best done in more specialized venues, without the more practical constraints that JS developers, interested experts, and TC39 members face in working on "ES" and discussing it.

And if we can avoid research by using existing formalisms and tools, then we should. That's strictly better for standardization.


> Claus
> PS. Sometimes, I wonder whether es-discuss would profit
>   from being split into es-{spec,design,tools}-discuss: more
>   focus in the 'spec' part, more room in the 'design' part,
>   and pragmatic realities in 'tools'.
>   The 'design' part might be more inviting to all those
>   research groups that have built JS semantics or analyses,
>   and the 'tools' part might help to keep the variety of tool
>   efforts in view. Both would invite useful input/background
>   for 'spec'.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list