Why x:=CAS("x") = 0 ?

[Carlos295pz]

I know that doing this may not make much sense, since the use of CAS variables does not require the creation of an HP PPL variable with the same name, or even that they are created. But recently I could see how some people use it and I have doubts.

LOCAL x=CAS("x");
PRINT(x) → 0 //Why? recursivity?

LOCAL var1=CAS("x");
PRINT(var1) → x //Expected, usual practice

LOCAL x=CAS(CAS("x"));
PRINT(x) → x //Why???

I would like to know what this is due to and if there will be any correction in this regard.

[Han]

When using CAS(), any variable references will first be resolved within the user's existing CAS environment. Then, variables are resolved using the local variables from the routine that called CAS(). At that instance, the local variable x has a default value of 0. You can test this by separating the declaration from the assignment.

When you use CAS(CAS()) the inner CAS() commands will try to use the outer CAS() command's local variables (and there are none).

[Carlos295pz]

It is an assignment in the same line of LOCAL, I would understand it if it were:
LOCAL x;
x:=CAS("x");
But this could also be possible:
LOCAL var1:=var1; → var1=0 ??

I do not really agree that it fails like that.

Regarding the double environment generated by CAS CAS, it seems to me that it is not working as expected, now it can be exploited but will should continue searching until it leaves the final nested environment?

[Carlos295pz]

I'm considering name resolution, but something does not quite convince me.
http://www.hpmuseum.org/forum/thread-621...l#pid55671

[Carlos295pz]

Great Mr. parisse, I invoke you, please destroy me with their words.