Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shift initiative #30

Closed
Victorystick opened this issue Feb 16, 2015 · 2 comments
Closed

Shift initiative #30

Victorystick opened this issue Feb 16, 2015 · 2 comments

Comments

@Victorystick
Copy link

I'm interested in the groups opinion on the Shift AST, which is heavily influenced my SpiderMonkey but breaks compatibility by reducing the number of invalid programs that the AST may represent.

I wonder if the goal of ESTree is simply to have the community standardize the SpiderMonkey AST, our if it aims to address issues and build a refined and more convenient AST for ECMAScript tooling.

@michaelficarra
Copy link
Member

See https://twitter.com/jspedant/status/567037276450848768.

Note that this is not a "new" standard, but simply the original SpiderMonkey standard (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API) now on Github. The Github discussion is meant to standardise previously unspecified ES6 nodes in the SpiderMonkey format. Also, it will be the ultimate source of truth for when SpiderMonkey's Reflect.parse differs from what is specified on MDN.

As I understand it, we are not interested in making backwards-incompatible changes. If someone wants to go through and update every tool to support a backwards-incompatible change to the SpiderMonkey AST, I see no reason why they wouldn't just switch to the Shift AST.

Full disclosure: I helped create the Shift AST, but I am trying to be as impartial as possible in these discussions. I know SpiderMonkey-based tools are not going away any time soon.

@RReverser
Copy link
Member

Yes, the goal of this spec is to be living SpiderMonkey-compatible standard for AST forms of new syntax features and not to create another own standard.

So I guess we can close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants