Reflect.parse (from RE:typeof null)

Allen Wirfs-Brock allen at
Thu May 10 09:38:20 PDT 2012

On May 10, 2012, at 8:28 AM, Claus Reinke wrote:

>>> 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:
> it appears that the SpiderMonkey AST has emerged as a de-facto
> standard. 

Does any other browser provide a built-in API that produces that AST?  If not, it isn't a de-facto browser standard.  It may be a de-facto standard among JS front end tool builders, but that isn't the same thing. 

> 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..

Or, possibly, it isn't important enough for other venders to care. Is this really a "browser platform issue" or a language tool builder issue?

> 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?

Basically, all standards development works approximately the same way. A group (people or organizations) with a common interest get together, write a specification, and get a standards organization to publish it.  Whether or not it actually achieves broad adoption (see, for example, E4X) will depend upon many factors. TC39 is open to hosting such efforts. That's what happening right now with the ES Internationalization API.  But the proponents need to provide the "feet on the street" to make such efforts actually happen.

> 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.

It isn't clear to me why esprima should care about the Mozilla parser implementation.  Why isn't Esprima free to do what ever its wants. While FF release turns aren't slow, certainly esprima can innovate faster than FF in this area.  Get ahead, show Mozilla how to do it.  

> 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?

But what does it matter whether or not Mozilla does.  If esprima turns out to be  the best browser independent ES front-end infrastructure its AST is likely to turn into the de-facto standard so it doesn't matter what Mozilla does. 

Basically, you win in the market, not by prematurely writing standards.  

> 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.

That's pretty much it...

However, it isn't clear if it is necessary or even desirable for this to been part of the ES standard, even by reference.  We need to start thinking of the browser/web as "the platform", comparable to the role Window or Unix/Linux has had for the past couple decades.  You will freeze innovation by making functionality prematurely a standardized immutable part of the platform.  Providing functionality in a form that can can exist above the platform layer is should be seen as a goal rather than as a consolation prize.  


More information about the es-discuss mailing list