#600 Inner procedure call modifying variable in outer scope

[DanielAjoy]

I'm using version 8.4 in English under Wine under Linux and I have this code:

to b :captured
(show (ponA [[[E] :E] 1000]) :captured)
end

to ponA :ab
output apply [disruptor list ?1 ?2] :ab
end

to disruptor :captured
output apply [invoke ?1 ?2] :captured
end

When I run this line:

b 1

I was expecting

1000 1

instead, I get:

1000 [[[E] :E] 1000]

Tested the code using Ucblogo 6.2.2

and got what I feel is the correct result:

1000 1

[David Costanzo]

The example isn't self-evident. I suppose you're saying that the :captured argument of disruptor should shadow the :captured in b and therefore its assignment should not affect the value of :captured in b.

[DanielAjoy]

Yes. that interpretation is correct.

What's more, if I change the "b" procedure in this way:

to b :captured
(show (ponA [[?] 1000]) :captured)
end

The problem vanishes:

b "hello
1000 hello

I changed this

[[E] :E]

to this:

[?]

I'm not sure if this helps pin-point the problem or not.

[DanielAjoy]

another weird thing is that the value of captured is only wrong in the first show line, but not the last line show :captured below:

to b :captured
(show (ponA [[[E] :E] 1000]) :captured)
show :captured
end

b "hello
1000 [[[E] :E] 1000]
hello

[David Costanzo]

Thanks for the additional information, Daniel. I've simplified your original example to

to a :a
(show (b) :variable)
end

to b
output run [c 100]
end

to c :variable
output run [apply [[E] :E] [1000]]
end

a 1
1000 100

To break down the behavior, apply [[E] :E] [1000] should evaluate to 1000. Therefore, c should also output 1000, which means b should also output 1000.

It's clear that a 1 should throw an error, as :variable has no value in a. Somehow the stack frame for the RUN/APPLY makes it to a. I suspect this is a bug in the interplay between tailcall optimization and macros, as RUN and APPLY are both macros. It might even be a duplicate of Bug #599. If you remove the tailcall from c, the problem disappears.

While the UCBLogo behavior seems better, it's not flawless. For example, on my Fedora 41 machine, after adding the above, UCBLogo crashes if asked to run

show apply "c 100

[David Costanzo]

I had previously written:

It might even be a duplicate of Bug #599.

I fixed bug #599 and this bug (Bug #600) remains, so this is not duplicate.

[David Costanzo]

I simplified the example as much as I could:

to a
   (show b 1 :variable)
end

to b :variable
  output apply [[x] 2] [3]
end

a
2 1

a should throw an error because :variable is not defined. Instead, it prints 2 1. The 2 is correct, as that's what b 1 outputs.

If the named-slot template in the apply is changed to a named procedure template or an explicit slot template, then problem does not reproduce.

[David Costanzo]

I have committed a fix with [r6136].

Although the fix was relatively simple, it does not follow the code in UCBLogo, which makes less confident in it. The updated code passes all my tests, but that doesn't mean that my fix didn't introduce new problems. I have attached a pre-release version of the update, in case you'd like to test it before it's release in FMSLogo 8.5.0.

[DanielAjoy]

Thanks David,

Very much appreciate the time you've spent tracking this bug down. I'm going to start using the attached pre-release version.

It loaded LogoFE normally (no issues there) and I ran a few commands that I thought might have some interplay with nested APPLYs, and so far so good.

I'll keep you posted if something related to this issue comes up again.