JavaScript parser API

David Herman dherman at mozilla.com
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:

    http://hg.mozilla.org/tracemonkey/file/2ce7546583ff/js/src/tests/js1_8_5/extensions/reflect-parse.js#l1051

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.

Dave

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

> On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
>> http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
>> 
>> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list