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

[Feature Request] Resolution of namespaces #38

Open
Gravifer opened this issue Feb 10, 2021 · 5 comments
Open

[Feature Request] Resolution of namespaces #38

Gravifer opened this issue Feb 10, 2021 · 5 comments
Labels
enhancement New feature or request long-run Works that will be done in the unforeseen future

Comments

@Gravifer
Copy link

The current implementation supports document structure based on MMA cell structures (like (* ::Title:: *)). To my knowledge the official version is a pure front-end feature, and it is of much convenience to have it handled for code editors.
However, the kernel features - namespaces (contexts and packages) and scoping constructs like Module Block - are not resolved. Therefore, developers will have to go through the scripts manually to tell which context a symbol is in.

As most authors use namespaces concurrently along with cell structures, the current features are actually sufficient, and this issue may not be a necessity; if this is the case, this thread could be used to discuss the best practice for concurrent use of namespaces and cell structures.

@kenkangxgwe
Copy link
Owner

Cell structures are static while namespace and scoping functions are not. Begin["foo"<>ToString[Unique[]]] will give you a dynamic result. Resolving those will end up giving you wrong results. Thus, only if the file is evaluated once, will we know the actual context that a symbol is in. I am open to any effective, though not universally applicable, method to handle this.

@Gravifer
Copy link
Author

Since the traditional dynamic namespace is difficult to resolve, would it be easier to resolve the static new style package derivatives? Does CodeParser handle this already?

@kenkangxgwe
Copy link
Owner

kenkangxgwe commented Feb 23, 2021

The new-style package is somehow not officially documented and CodeParser recognizes it but doesn't support the full features. I doubt I can run the following code directly from Wolfram Kernel:

Package["MyPackage`"]
PackageImport["CodeParser`"]

mySym := 1

Can you try it out? Thanks. I wish there will be more examples/resources of this package usage, if you'd like to provide them. Thanks

@Gravifer
Copy link
Author

Gravifer commented Feb 23, 2021

This feature has been added since 10.x or so, and seems to be still in common use even though remaining undocumented.
I found some related resources in the following links:

I doubt I can run the following code directly from Wolfram Kernel: (code)

As mentioned above and explained in Leonid's answer, Package["MyPackage`"] and PackageImport["CodeParser`"] are only special static primitives, and are not really dynamically interpreted commands;. basically they are like PRAGMA macros in C/C++.

I see new-style packaging as a modernist attempt, but is not complete for designing nested packages and contexts. I won't fully switch to this practice, but I do think since the primitives are static, they can be easier to handle for the language server.

@kenkangxgwe
Copy link
Owner

Thanks for the information. I just tested the new-style and it seems working correctly (on Linux. No luck on my Windows' SimplifiedChinese version). Still gonna experiment with it for a while. I am starting to think about how we can leverage the namespace info now. Gonna leave this issue open for longer time.

@kenkangxgwe kenkangxgwe added enhancement New feature or request long-run Works that will be done in the unforeseen future labels Feb 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request long-run Works that will be done in the unforeseen future
Projects
None yet
Development

No branches or pull requests

2 participants