Mark S. Miller
erights at google.com
Tue Jun 28 16:11:56 PDT 2011
On Tue, Jun 28, 2011 at 5:02 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
> On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer <axel at rauschma.de>
> > 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?
A resulting AST, yes. And the need to agree on an AST is part of why
previous proposals along these lines failed to achieve consensus. I continue
to like the ASTs we generate at <
http://es-lab.googlecode.com/svn/trunk/site/esparser/index.html>. YMMV. But
I would be in favor any AST format we could agree on.
> 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
The only option I can see for standardizing a parser but not an AST is to
standardize an (SAX-like) callback emitting parser. But this doesn't really
avoid any of the hard issues. The signature of each of these callbacks has
exactly the same design issues as the format of an AST.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss