Hi Daniel, > I think this has something to do with compilation indeed. More specifically, > it is caused by cross module inlining [1]. You probably need to declare your > env module as not declarative by setting #:declarative? to #f inside the > define-module form of env. I think the compiler inlines varB somehow. Not > super sure, I am no Guile expert but you could inspect the assembly for main > to see what the compiler did. > > 1: https://www.wingolog.org/archives/2021/05/13/cross-module-inlining-in-guile > 2: > https://www.gnu.org/software/guile/manual/html_node/Declarative-Modules.html
Interestingly, it's actually the testexport module that needs to be `#:declarative? #f`, not the env module. Which makes some sense after I think about it - it is the variables in the testexport module that need to get the updates not the env module. The mental model I use when thinking about guile imports (which may or may not correspond to the implementation) is that importing a variable is just defining a variable with that name, and it happens to refer to a memory location allocated by a different module. Then, assuming that the cause of the problem is inlining as you describe (which seems quite plausible), the memory locations are optimized away and the symbols lose their "declarativeness". Part of me wants to say it would make sense for non-declarative modules to propagate their non-declarativeness to dependent modules. But this seems like it could cause a significant loss of optimization if there is one random module that needs to be non-declarative for some reason and happens to be near the root of a large tree. It might be easier to manage if declarativeness was associated with memory locations, instead of modules or (as the manual implies) symbolic definitions. But I know nothing about how declarativeness is implemented/tracked, so that might be a big ask.