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

Module imports should disambiguate source modules #281

Open
tnelson opened this issue Nov 20, 2024 · 1 comment
Open

Module imports should disambiguate source modules #281

tnelson opened this issue Nov 20, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@tnelson
Copy link
Owner

tnelson commented Nov 20, 2024

Currently, opening another module will import sigs, predicates, etc. into the target module. Multiple modules can be imported into a single target. It is reasonable to imagine that both modules bind the same identifier. For example, suppose we are modeling Prim's algorithm: we'd probably have a Node sig. But then if we're modeling Kruskal's algorithm, we'd also have a Node sig. If we then want to reason about these algorithms in (some sort of) composition, we'd import both into a third module.

It is inconvenient to need to manually rename identifiers (e.g., KNode vs. PNode for the two above). Alloy handles this by automatically prepending the imported module name to the identifier imported. We should consider doing the same, or at least doing so when a conflict occurs.

If we do this, we should add an as annotation to open, similar to Alloy's, so a module can control the naming.

@tnelson tnelson added the enhancement New feature or request label Nov 20, 2024
@tnelson
Copy link
Owner Author

tnelson commented Nov 20, 2024

Note that chained imports are not included. E.g.,
if B opens A, and
C opens B,
the identifiers declared in A are not imported into C.

This may be a separate issue, but noting it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant