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

Possible move to ESTree? #2

Open
RReverser opened this issue Jun 23, 2015 · 8 comments
Open

Possible move to ESTree? #2

RReverser opened this issue Jun 23, 2015 · 8 comments

Comments

@RReverser
Copy link

ESTree is a standard JavaScript AST representation used by most of devtools (parsers - Acorn, Esprima, ..., transformers, transpilers like Babel, etc.).

Looking at your currently used format, it seems to be simple to migrate, and would allow to interoperate with those tools (feed input from alternative parsers or from transpiler's output).

Would you be open for such migration?

@chicoxyzzy
Copy link

I believe that interop with ESTree compatible tools will open very cool possibilities

@jdalton
Copy link

jdalton commented Jun 24, 2015

Related Shift \cc @michaelficarra

@RReverser
Copy link
Author

Well, to be honest, Shift is a good & convenient alternative, but not a community standard. /cc @dherman @mikesherov @sebmck

@mikesherov
Copy link

Output to multiple formats is always an option. As far as builtin communities go, ESTree makes sense, but shouldn't preclude a long term goal of also supporting Shift.

@sebmck
Copy link

sebmck commented Jun 24, 2015

Biggest benefit to ESTree is interoperability which Shift does not have (I know an AST converter exists but it's not really the same thing). Is any outside of Shape using Shift anyway?

@RReverser
Copy link
Author

@mikesherov It's not about output but more about input (ability to generate WebAssembly from readily transformed AST). Of course, Shift can easily be plugged in as well, since they already have transformer to ESTree AFAIK.

@mikesherov
Copy link

@RReverser right. I meant input. :shipit:

@michaelficarra
Copy link

@RReverser

ability to generate WebAssembly from readily transformed AST

Shift is designed primarily for being the ideal AST for transformation. I recommend you read our blog post about it (which is a bit dated now) to understand our motivations.

As an example, consider the program var a; for(var b;;);. ESTree represents both var a and var b as VariableDeclaration nodes. Shift chooses to wrap the VariableDeclaration node representing var a in a VariableDeclarationStatement node. This is one part of many considerations that were taken in order to give you the guarantee that you can safely replace any Statement node with any other Statement node. You don't have that or any of the many other important features that make for a decent experience transforming ASTs with ESTree.

Shift is a good & convenient alternative, but not a community standard.

Though you may not want to call it a "community standard" because we haven't received much input from the community during its design, we have always asked for community involvement, and anyone can read, fork, and implement the specification freely because we have licensed it under the Apache 2 license.

Of course, Shift can easily be plugged in as well, since they already have transformer to ESTree AFAIK.

And from ESTree to Shift, so the other way around is just as much a possibility.

I'm not personally opinionated about what format this project accepts, but I don't want the decision to be driven by misinformation from this thread. Also, it seems to me that neither of these formats are ideal given the goals listed in the README. It would probably be best for each community to create a transformation from their preferred AST representation to the one that is actually ideal for this project.

Thanks for the mention, @jdalton.

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

6 participants