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

TLA+ module support (for completeness) #158

Open
fhackett opened this issue Sep 17, 2021 · 2 comments
Open

TLA+ module support (for completeness) #158

fhackett opened this issue Sep 17, 2021 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@fhackett
Copy link
Contributor

Currently, PGo will crash with NotImplementedError if a TLA+ module it's compiling references external definitions.

Anything involving EXTENDS, INSTANCE and a module that is not built-in will cause this problem.

While this does not impact most usage, it would be good to eventually implement the relevant scoping / compilation features.

@fhackett fhackett added the enhancement New feature or request label Sep 17, 2021
@minhnhdo minhnhdo self-assigned this Oct 17, 2021
@minhnhdo
Copy link
Contributor

@fhackett
Copy link
Contributor Author

Good to see work's gotten started; commits make sense so far :)

Some notes I forgot to add originally:

  • A non-obvious consequence of these requirements will probably be to implement an error in case of duplicate definitions. This is needed due to the TLA+ module system's solution to the diamond inheritance problem, which relies on uniqueness to make actual sense. TLA+ forbids name shadowing, but PGo doesn't actually care right now. This will probably matter more then loading multiple possibly-conflicting definitions, as with custom modules.
  • You can identify definitions by "pointer identity", at least at the parser+scoping stage, and the withDefinition function could be a good place to insert any such logic (give or take some potentially tricky interactions with parser backtracking).
  • If you didn't find it already, have a look at the MPCal parser's logic, re: how it extracts relevant TLA+ definitions to consider in-scope for the MPCal block (it does this at its entry point, in the object). This should be more or less adaptable to implementing the module "inclusion" primitives.

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

2 participants