Re: can't export conditional variable set with 'cond'

[Skyler Ferris]

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.