e96d4018ae
The old model for imports was to use top-level declarations on the enclosing module itself. This was a laudible attempt to simplify matters, but just doesn't work. For one, the order of initialization doesn't precisely correspond to the imports as they appear in the source code. This could incur some weird module initialization problems that lead to differing behavior between a language and its Coconut variant. But more pressing as we work on CocoPy support, it doesn't give us an opportunity to dynamically bind names in a correct way. For example, "import aws" now needs to actually translate into a variable declaration and assignment of sorts. Furthermore, that variable name should be visible in the environment block in which it occurs. This change switches imports to act like statements. For the most part this doesn't change much compared to the old model. The common pattern of declaring imports at the top of a file will translate to the imports happening at the top of the module's initializer. This has the effect of initializing the transitive closure just as it happened previously. But it enables alternative models, like imports inside of functions, and -- per the above -- dynamic name binding. |
||
---|---|---|
.. | ||
compiler | ||
diag | ||
encoding | ||
eval | ||
graph | ||
pack | ||
resource | ||
tokens | ||
util | ||
workspace |