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

How do we prevent duplication of transitive imports? #511

Open
luketpeterson opened this issue Nov 20, 2023 · 0 comments
Open

How do we prevent duplication of transitive imports? #511

luketpeterson opened this issue Nov 20, 2023 · 0 comments
Assignees
Labels
question Further information is requested

Comments

@luketpeterson
Copy link
Contributor

How do we prevent duplication of transitive imports? For example, consider:
ModA imports ModOne and ModTwo. ModOne imports ModB. ModTwo also imports ModB. How do we
make sure ModA doesn't end up with duplicate definitions for everything in ModB?

This is usually solved in other languages using some combination of strategies.
1.) Keep loaded modules contained within their own name-spaces. And allow aliasing between a parent's
space and a child module's space. This is the "import module as bar" pattern, but I think we also want an
"from module import *" and "from module import foo" pattern so modules like stdlib can make all of its
contents available to its parent without an explicit namespace access.

2.) Allow a conditional "import-unique" brute-force import which is tantamount to inlining the dependency
at the point of the import statement. e.g. #include in C., but with the "ifdef" guards to make sure
the same header isn't inlined multiple times. We may want to offer this functionality, but I assume
we'll want to offer this in addition to a more hygenic module system structure, given that most languages
(Python, JavaScript, even Perl!) that started off with brute-force imports have retrofitted more
sophisticated dependency management as they have matured

3.) Force a module to be explicit about what can be exported from the module. e.g. the pub visibility
qualifiers in Rust, etc.

Personally, I feel like 3. (being explicit about exported items) is the cleanest solution and provides
the most flexibility into the future (such as the ability to unload modules, etc.)

@luketpeterson luketpeterson added the question Further information is requested label Nov 20, 2023
@luketpeterson luketpeterson self-assigned this Nov 20, 2023
luketpeterson added a commit to luketpeterson/hyperon-experimental that referenced this issue Jan 8, 2024
…n with new `import` operation

Updating comments to be a bit more precise & informative in a few places

NOTE: This commit comes after a long exploration to find a good half-way step to get all of the behavior in `f1_imports.metta` through the new import mechanism.  Specifically thr problem discussed here: trueagi-io#511 . Unfortunately all of the solutions I tried were very ugly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant