-
Notifications
You must be signed in to change notification settings - Fork 358
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
Define scope of this project #219
Comments
I think this is reasonable. I agree with what @RReverser expressed in the linked thread, that we should have an agreement on what portion of source text is being represented by an AST node, regardless of how concrete syntax information is being conveyed.
There's many ways to convey concrete syntax information, and each has its benefits and drawbacks depending on the use case. I don't think there should be single blessed way to represent and pass around concrete syntax info. For most cases, I prefer a side table style approach, but I can also appreciate the convenience (and difficulties) of inlining concrete syntax info into the AST.
Please no. The format is extensible, let them extend it. The most I could see the estree project doing is coordinating reserved prefixes or something for type names to avoid extensions stepping on each others' toes.
No, for the same reason we don't include concrete syntax information like whitespace, position, and unnecessary grouping. Comment representations are also varied and have the same tradeoffs I mentioned with concrete info above. I'd be interested to see either this project or a similar project try to standardise the various comment "attachment" rules, though, defining how comments associate with adjacent nodes. In our comment-based templating system, we ran in to some tricky cases and disambiguated them with optional node types included in the comment. |
I agree that answer is "no" in general to most of these questions. If we ever have enough people and interest to tackle problem of CST again, we could create it as a separate project under the However, I think it might make sense to follow the precedent of "extensions" like @nzakas added for base type annotation definitions here https://github.com/estree/estree/tree/master/extensions and perhaps define existing common non-standard extensions used by parsers - e.g. Not sure if it brings much value, but at least it would be documented somewhere as a point of reference for such optional extensions. P.S.
I forgot about these by now, but damn, that looks like a reasonable suggestion. Past me was smarter than today 😅 |
Okay, so it seems like we have a general agreement that:
Is that a good summary? @RReverser @JLHwung |
Sounds good. Just few clarifications:
Just the general logic, not the actual properties, right? We can still define the properties under (3) though, just want to make sure we have a clear scope.
I think these can similarly be merged under (3) - that is, like other popular extensions, we might document how they work without making them part of the official standard. |
I came here to say the same thing. We should define what portion of source text corresponds to what AST node(s) in a parse, but not define how the ranges from a parse of a particular source text are represented, either within the AST or outside it. |
@RReverser @michaelficarra just to make sure I'm understanding about |
@nzakas Yes, this includes at least
For the first two, imagine the AST nodes were named "A", "B", "C", etc. and their properties were named "a", "b", "c", etc. What would you need to document to still be able to implement tooling based on the spec? |
Yeah, I think a good example here would be something like Or loop statements where properties describe conditions and the body, but node covers keyword and punctuation as well. It should be fairly simple / logical in most cases, but needs adding examples to each node. |
Okay, gotcha, thanks for explaining. I'll try to put together a scope statement on the README soon. |
To aid in communicating with participants, it would be helpful to come up with a statement of scope so everyone knows what is and is not a part of ESTree. There has traditionally been some confusion around this:
From the response (or lack thereof) to these various issues, my guess is the answer to each is "no," but it would be nice to get some consensus and then narrowly define the scope of the project so we can more easily respond to issues and PRs as they come up.
The text was updated successfully, but these errors were encountered: