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 <a...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
