On Tue, Jun 28, 2011 at 5:02 PM, Mike Shaver <mike.sha...@gmail.com> 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? 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 > exist? > <https://mail.mozilla.org/listinfo/es-discuss> > 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. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
