Local Modules (lib/ only)
#95
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This brings the name closer to the actual meaning of this construction.
This way, is is less likely one by accident exports the wrong function under a different name
This frees '-l' up to be used for a '--link' later
These are (a) only used by the runtime and/or (b) only used seldomly. Hence, we may as well open up for these to be used for something different, e.g. modules
This is the only place it is used. Furthermore, having it defined in IR removes it from the context of having to make it be valid JSON; anything that is deemed 'prettier' might by accident be "re"used
There seems to be some unecessary complexity as a leftover of previous designs?
This much better conveys the meaning of this argument, especially from the call site
This allows us later to store an initialised module. For now, it cleans up the scheduler by decreasing the number of responsibilities.
The compiler is extended with two flags:
- [-m] compile a troupe program as a Module. This outputs the IR
and also its (SHA256) hash.
- [-i] Include directory for modules. This is needed to find the
hash value of any module that was required.
During the frontend, the modules are mainly passed along at the
program level without further treatment.
At the IR level and beyond (backend), the module dependencies are
moved from the program level to the function definitions. Since
functions can be sent independently to others, this allows the
different functions to keep track of their respective dependencies.
So, when a function is sent from one user to another, even though the entire program depends on some module, the other user is only told about it if there truly is a dependency.
This only applies to the standard library in the 'lib/' folder; user-defined libraries that are opened via the `require` instead of `import` statement are ignored. What this does provide is a clean-up of the previous hacky library system. Doing so, we fix the inability to compute constants as part of library initialisation (issue TroupeLang#55). This provides the foundation for us to build the nomadic module system.
ssoelvsten
added
✨ enhancement
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Replaces library import system with something that matches what we intend for the nomadic modules later.
This only applies to the standard library in the 'lib/' folder. While this also adds the
requirekeyword to the compiler, the runtime ignores it. All in all, this creates the foundation on which we can begin implementing the nomadic modules. For now, this only really constitutes a cleanup of the compiler ( #79 ), the runtime ( #80 ), and the standard library ( #91 ). But, this does already fix #55 .This pull request requires that the pull requests #79, #80, and #91 have all been merged.