JavaScript parser API

David Herman dherman at
Tue Jun 28 17:21:01 PDT 2011

Yeah, tough questions. I don't know. I tried to make the API flexible by allowing custom builders, and in fact if you look at the test suite you'll see I did a proof-of-concept showing how you could generate the format that Mark mentioned:

But there are also tough questions about what the parser should do with engine-specific language extensions.

I agree about the issue of multiple parsers. The reason I was able to do the SpiderMonkey library fairly easily was that I simply reflect exactly the parser that exists. But to have a standards-compliant parser, we'd probably have to write a separate parser. That's definitely a tall order.


On Jun 28, 2011, at 4:02 PM, Mike Shaver wrote:

> On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer <axel at> wrote:
>> I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance that this kind of API will make it into Harmony? It would be really useful for a variety of generative/meta-programming tasks.
> I'm interested in this too, for a number of applications, but I keep
> getting stuck on one thing.
> Would you standardize the resulting parse tree, too?  That would
> probably mean that every engine would have two parsers, since I'm sure
> we produce different parse trees right now, and wouldn't want to lock
> down our parser mechanics for all time.
> If you don't standardize the parse tree, is it still useful?  More
> useful than just using narcissus or whatever other parsing libraries
> exist?
> Mike
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list