Reflect.parse (from RE:typeof null)

Claus Reinke claus.reinke at talk21.com
Thu May 10 08:28:03 PDT 2012


>> Will Reflect.parse be standardized?

> Maybe. It's too late for ES6 and different implementations have 
> different concrete parse trees, I bet -- although perhaps they all agree 
> on concrete, there's still the question of mapping to abstract. This 
> needs more time to bake.
> 
> It's also a mouth to feed, not as much as a second built-in parser but 
> it takes its maintenance toll feeding over time. More time needed to get 
> implementor buy-in on this count.

In the absence of an ES standard for Reflect.parse, for reasons
documented in this strawman page:

http://wiki.ecmascript.org/doku.php?id=strawman:ast

it appears that the SpiderMonkey AST has emerged as a de-facto
standard. 

There was just too much pressure for this not to happen, as one 
cannot even test a standalone parser without some way to 
represent its output. Parser implementors and parser users 
needed a target spec, and the SpiderMonkey AST was the best
known, and the only one with engine-maker buy-in.

So, the concerns about not forcing different vendors to support
a standard AST API have led to one vendor "owning" the standard..

Given the speed of parsers like esprima, and the performance
and complexity implications of other engine's internal ASTs
not matching the SpiderMonkey AST, it does seem right not
to force engine makers to implement Reflect.parse.

The question is: how to move this de-facto standard forward?

For instance, there is an esprima branch implementing modules,
does it have to wait for someone (Mozilla?) to extend the AST 
spec? Or does the feature get merged into the master, and
everyone has to change when Mozilla implements? Similarly 
for other parts of the evolving ES6 spec.

Or, there are issues emerging from the increasing use of the
AST API - will everyone have to apply to Mozilla for changing
the spec? Will Mozilla do that if it means changing their
implementations? Do they now have to pay the maintenance
toll mentioned above?

It might be useful to decouple the SpiderMonkey AST API
from its initial implementation, and to create a forum in which
all users of the AST API spec (parser implementors, parser
users) can discuss and influence the development. Then the
question of whether or when Mozilla or others implement
which parts of the spec would be separate from what the
spec is. Such a forum and its spec could then be mentioned
in the ES standard as an appendix, without including the
AST spec itself in the ES standard.

Claus
 


More information about the es-discuss mailing list