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

Scope #17

Open
conartist6 opened this issue Sep 4, 2022 · 7 comments
Open

Scope #17

conartist6 opened this issue Sep 4, 2022 · 7 comments

Comments

@conartist6
Copy link
Member

I need to create some pattern for understanding scope in CSTs. That will be critical to understanding the abstract portion of the tree so that it is truly useful for codemods.

@conartist6
Copy link
Member Author

Scope is understood in the context of grammar rules. But how will the information be stored and presented? Better take a look at some existing scope analysis tools

@conartist6
Copy link
Member Author

The matchNode tree is probably a decent place to keep a scope representation. It is safe to keep some graph-structured references in there, data stored in a matchNode is guaranteed to have been validated, and it would allow scope data to be used when traversing a matchNode tree, an operation which I expect to turn into the library's primary low-level API.

@conartist6
Copy link
Member Author

I'm going to close this for now. I may eventually build my own scope tools, but for now I'll let people use babel on my trees.

@conartist6
Copy link
Member Author

Ehhh I changed my mind I'm gonna leave it open. I think I can build some level of functionality without tackling everything.

@conartist6 conartist6 reopened this Sep 7, 2022
@conartist6
Copy link
Member Author

I think the basic functionality I want is to establish which identifiers are the same symbol. I think the way to do this is by attaching a scope reference to the identifier token (either as a property or using a WeakMap). There will also need to be a way to find for a given scope id which node defined it. I would also like to consider differentiating between an identifier that defines a symbol and one that references a symbol.

This data would allow building a significant number of tools, yet it would not bless any particular API for manipulating scope. It would ideally allow the creation of many tools, each of which could support many languages out of the box by including a prebuilt grammar.

@conartist6
Copy link
Member Author

Another possibility, which I think may be better:

Instead of attaching a "identifier id" to each identifier, attach a "scope id" to each node.

@conartist6
Copy link
Member Author

conartist6 commented Nov 2, 2022

What happens for nodes that define more than one new scope? Javascript doesn't have a problem as it uses the BlockStatement node type, but a language in which curly braces are not optional for control structures for example might not choose to do this, instead having some node type whose tokens are:

if (ref) { ref[] } else { ref[] }.

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

1 participant