Bug? -- assignment to argument behaves strangely

[Ralf Hemmecke]

The attached program results in the output given below.

Why is revb3 showing the empty list whereas lb3 does not?

Interestingly, when I remove the line marked with ***, then the output
for revb3 comes out as expected (see second session below).

It seems like assignment to "revb" inside "delay" is creating a new
variable revb that is not the same as the argument of restRecip. That's
the only possible explanation I can come up with.

Ralf

-- first session --

%%% (1) -> )co foo.spad
%%% (1) -> S ==> Stream Fraction Integer
%%% (2) -> )set stream calc 4
%%% (2) -> s: S := [i for i in 1..]

(2) [1, 2, 3, 4, ...]

%%% (3) -> un := (recip_new s)$Foo(Fraction Integer);
[:> , revb, [1]]
[:> , revb2, [1]]
[:> , lb2, [1]]

%%% (4) -> sn := un :: S;

%%% (5) -> sn.2
[:> , revb3, []]
[:> , lb3, [1]]
[:> , zero? bn, true]
[:> , revb, []]
[:> , revb2, []]
[:> , lb2, []]

(5) 0

-- second session

%%% (1) -> )co foo.spad
%%% (1) -> S ==> Stream Fraction Integer
%%% (2) -> )set stream calc 4
%%% (2) -> s: S := [i for i in 1..]

(2) [1, 2, 3, 4, ...]

%%% (3) -> un := (recip_new s)$Foo(Fraction Integer);
[:> , revb, [1]]
[:> , revb2, [1]]
[:> , lb2, [1]]

%%% (4) -> sn := un :: S;

%%% (5) -> sn.2
[:> , revb3, [1]]
[:> , lb3, [1]]
[:> , zero? bn, true]
[:> , revb, [1]]
[:> , revb2, [1]]
[:> , lb2, [1]]

(5) 0

[Waldek Hebisch]

On Wed, Jul 24, 2024 at 10:30:07PM +0200, Ralf Hemmecke wrote:
> The attached program results in the output given below.
>
> Why is revb3 showing the empty list whereas lb3 does not?
>
> Interestingly, when I remove the line marked with ***, then the output for
> revb3 comes out as expected (see second session below).
>
> It seems like assignment to "revb" inside "delay" is creating a new variable
> revb that is not the same as the argument of restRecip. That's the only
> possible explanation I can come up with.

'delay' is a normal function call, but due to special complier rule
its argument is compiled as a nested function. In current Spad
compiler nested function gets new set of variables, and assigment
to those variables have no effect on enclosing function. Also,
there is official rule that if your first use of variable is a read,
then its initial value is inherited from enclosing scope, but I
suspect that our current code does not follow this rule. A safe
way of coding is to use new variables for anything that you want
to mutate in a nested function.

--
Waldek Hebisch