Yes. I toke a code snippet and compiled to assembly. It looks like the .go file contain a specification of a program with a set of local variables where the (cons 'foo 'foo) is stored very much like the function
local vars on the stack. Now there is a link somehow to this program that is alive after it has been executed and itself links to the list of local vars. This theory can be shown by doing the same thing in a new let
and say (cons 'goo 'goo) afterwards for which the old local slot is used as storage. Hence at evaluation (gauardian) will show (foo . foo) but (goo . goo) will not appear due to beeing referenced by the local var slot.
Now, one solution would be to have a pass of cleaning the local slots after the execution because this behavior has the potential of leading to memory leaks. The next step is to question the use of keeping the link to the program
that comes from the loaded file, maybe due to cashing this is an effective strategy, but someone with greater overview of the code has to commment on this. In alles locally defined functions and variables should not be kept in the gc because
it is begging to yield memory leaks. cashing locally defined functions is a bit weaker and on first sight can be a good cashing strategy. On the other hand if one implementing schemes like Ian does one can easilly have a chain of objects that has to be gc:d is a specific
order and if one of these object is a local lambda gcing of the elements further down will not happen.
> I disagree. While I would certainly expect it to work if I made the
> reference to f weak, it would miss the point of my code entirely. Namely
> to make sure that f isn't gc'd until after some other value is (hence
> the weak reference to a cons, and my comment about expecting to need 2 gcs).
Sorry for may blunt statement here. You seam to come from a valid way of doing your coding. My fault.