Program local variables issue

[DrDarius]

In many HPPL programs I have seen declarations of variables placed outside of the bodies of any programs or functions of the module. Those variables were sometimes preceded by a keyword LOCAL, sometimes they were not. The variables were often initialized.
I am assuming that the goal of this structure was to create variables that had scope limited to the module (equivalent of a static global variable in c/c++).

Personally, I try to avoid such style. I try to declare all variables as locals in the body of the program and pass them to the functions as arguments. If I happen to need a global variable, I export it.

Recently I ran into problems with such a program I was trying to use. It could be ran only once. Every subsequent run was generating an error. I spent some time analyzing what's going on, and here is what I found.

The following program demonstrating the issue:

Code:

LOCAL List:={};
LOCAL Number:=101;
TestVariable:="Variable not exported & not local";
  
EXPORT WHATEVER()
BEGIN
  PRINT();
  // print values after initialization
  PRINT("After variable initialization:");
  PRINT (List);
  PRINT (Number);
  PRINT(TestVariable);
  PRINT(" ");
  // modify variables
  List:={{1,2,3},{4,5,6},{7,8,9}};
  Number:=999;
  TestVariable:="Variable modified";
  // print variable after modification
  PRINT("After modification:");
  PRINT (List);
  PRINT (Number);
  PRINT(TestVariable);
  PRINT(" ");
  // modify variables before exiting program
  List:=-1;
  Number:=0;
  TestVariable:="Totally different variable...";
END;

operates on three variables declared outside of the programs/functions. Two of them are declared as LOCAL, the third one is not (but it's not exported). All variables are initialized to (let's call it) state_1.
Inside the program the values of initialized variables are displayed, then they are modified to state_2, displayed again, and, finally, modified again to state_3 before exiting the program.

Please compile the program and run it. You will see the variable values displayed in order: state_1 and state_2, as it should be.
Then run the program again (without recompiling!). You will see the variable values displayed in order: state_3 and state_2.
Upon second run the variables were not initialized. More on, the supposedly local variables from the previous run somehow survived in the OS and were passed to the program upon subsequent run.

It is my understanding that the variables, as locals, should be destroyed the very moment the program terminates.
After the program returns control to the OS, the variables in question cannot be found in any variable catalog in the calculator menus, which seems to indicate they were not exported.

Can anybody shed some light on this behavior?

(Ran on G2 and simulator, f/w 2020 01 16.)

Darius

[cyrille de brébisson]

Hello,

Program globals (ie, variables declared in a program outside of the scope of functions) are persistent.
By default, they are not exported (meaning that they are hidden from the user outside of the program, EXCEPT if they are fully qualified, they will not apear in the UI either).
EXPORT makes them exported. LOCAL is a marker for not exported, but since it is the default, it is optional. It is however good practice to put it because it makes the variable declaration more obvious.

Program global ARE persistent from run to run of the program. They should also resist a recompile if all goes well. They should resist a calculator power cycle/reboot also.
They will NOT survive a send/receive however.

Cyrille

[CyberAngel]

(02-10-2020 06:16 AM)cyrille de brébisson Wrote:  Hello,

Program globals (ie, variables declared in a program outside of the scope of functions) are persistent.
By default, they are not exported (meaning that they are hidden from the user outside of the program, EXCEPT if they are fully qualified, they will not apear in the UI either).
EXPORT makes them exported. LOCAL is a marker for not exported, but since it is the default, it is optional. It is however good practice to put it because it makes the variable declaration more obvious.

Program global ARE persistent from run to run of the program. They should also resist a recompile if all goes well. They should resist a calculator power cycle/reboot also.
They will NOT survive a send/receive however.

Cyrille

OS upgrade resistant, too! Right?
- -
VPN

[Carlos295pz]

(02-10-2020 02:25 AM)DrDarius Wrote:  I am assuming that the goal of this structure was to create variables that had scope limited to the module (equivalent of a static global variable in c/c++).

HP PPL is simpler than that, I really like it as a language. Any variable outside a function, either LOCAL or EXPORT, is persistent as long as a recompile is not performed, therefore they will not be efficient to save changes, but in order to be able to use them in other functions, HP PPL forces to use them since there is no passing of arguments by reference (a bit annoying), but with a little order everything can be happiness. The user manual has a section that explains HP PPL, read it before creating great confusion.

(02-10-2020 02:25 AM)DrDarius Wrote:  It is my understanding that the variables, as locals, should be destroyed the very moment the program terminates.

Outside of any function, every variable is global, and the point of LOCAL and EXPORT is for a visibility change for the calculator. LOCAL can be omitted only outside the program, let's say they are local to the compilation (checkmate). Regarding visibility, they are not visible but still accessible through ProgramName.LocalVariableName

[CyberAngel]

(02-10-2020 11:07 AM)Carlos295pz Wrote:  X
Regarding visibility, they are not visible but still accessible through ProgramName.LocalVariableName

When one gathers a program library with systematic names
this is a good feature that prevents name space pollution.

Plan ahead!

VPN

[DrDarius]

(02-10-2020 11:07 AM)Carlos295pz Wrote:  

(02-10-2020 02:25 AM)DrDarius Wrote:  It is my understanding that the variables, as locals, should be destroyed the very moment the program terminates.

Outside of any function, every variable is global, and the point of LOCAL and EXPORT is for a visibility change for the calculator. LOCAL can be omitted only outside the program, let's say they are local to the compilation (checkmate). Regarding visibility, they are not visible but still accessible through ProgramName.LocalVariableName

I got lost in the meanders of terminology, and didn't express myself clearly. I was thinking what I see from the OS level, and used "local" to describe variables that have focus set to inside of the module (alike mentioned before "static global"). Sorry for the confusion.
After your explanation I can see, though, that they are closer to being an equivalent of the public methods of the class...

Thanks for explanations. I definitely learned something today.

(02-10-2020 02:25 AM)DrDarius Wrote:  The user manual has a section that explains HP PPL, read it before creating great confusion.

I did read the manual, more than once. In my opinion it leaves a lot to desire. It looks to me like it did not get enough of TLC. After I learn programming details of HP PLL, I can see that one can read between lines and deduce certain things and features.
(Example: find ma a word "persistent" in the manual used in the context of persistent variables. Or, I could not find any example of the local variable defined outside of begin/end block; all were exported.)

But now we're getting to the MO issues. For me a calculator is a tool which I can use to aid whatever I am working on. I don't worship it, and I don't have time to sit for hours and test whether certain things work or not. At least I want to minimize such events. At the same time, I want to use it efficiently.
I understand that there is a conflict here: the manual cannot be too advanced, because it's for the... well... a calculator. Thus, I would like to see an appendix describing advanced topics clearly and without any ambiguities.

What counts for me is efficiency and ease of use. Before prime I used C on TI84+CE, Python on NumWorks. In my opinion HP Prime beats both of those two despite inefficiencies of HP PPL. And I am planning on using it until something better comes around. (To all the readers of this post: sorry if I hurt somebody's feelings with somewhat cynical approach.)

But it's a subject for a long discussion. There is no need to bore other forum members.

Darius

[Gene222]

(02-10-2020 06:09 PM)DrDarius Wrote:  I did read the manual, more than once. In my opinion it leaves a lot to desire. It looks to me like it did not get enough of TLC. After I learn programming details of HP PLL, I can see that one can read between lines and deduce certain things and features.
(Example: find ma a word "persistent" in the manual used in the context of persistent variables. Or, I could not find any example of the local variable defined outside of begin/end block; all were exported.)

For a good explanation of how to program with local variables, see 4.2) HP Prime Programming: Variable types and their priorities. This document is located within the HP-Prime: Documentation & Tutorials located at the top of this forum.

[Wes Loewer]

(02-11-2020 04:34 AM)Gene222 Wrote:  For a good explanation of how to program with local variables, see 4.2) HP Prime Programming: Variable types and their priorities. This document is located within the HP-Prime: Documentation & Tutorials located at the top of this forum.

If I'm reading this document correctly, then its description of local variables defined outside of a function is not correct. It says:

Quote:Unlike local variables declared inside a program block, such as var7, local variables declared outside of any program block retain their values even after program execution reaches completion and up until the source is recompiled. This is the only effective difference. They are still not accessible to programs defined in a separate source file, or the user.

Here is a counterexample. Create these two program in separate source files.

Code:

LOCAL var1:=1;

EXPORT PROG1()
BEGIN
 RETURN var1;
END;

and

Code:

EXPORT PROG2()
BEGIN
 PROG1.var1:=PROG1.var1+1;
 RETURN PROG1.var1; 
END;

Run PROG1, then PROG2 and you see that var1 has changed. If you run PROG1 again, it confirms that var1 really has changed. Likewise, you can alter PROG1.var1 from the Home screen as well.

[CyberAngel]

(02-11-2020 06:25 AM)Wes Loewer Wrote:  X
Likewise, you can alter PROG1.var1 from the Home screen as well.

and use them in the Plotting Apps or otherwise
(save your own version of app for you to use at will)
PROG1.var1 can be thought as just a string of characters applicable in almost anywhere.
Use character manipulation, Quote, EXPR, CAS("PROG1.var1"+other), etc
You can use a lot of objects inside lists, matrices,
and manipulate them in unorthodox ways

Just giving people some ideas!
- -
VPN

[Gene222]

(02-11-2020 06:25 AM)Wes Loewer Wrote:  Here is a counterexample. Create these two program in separate source files.

Code:

LOCAL var1:=1;

EXPORT PROG1()
BEGIN
 RETURN var1;
END;

and

Code:

EXPORT PROG2()
BEGIN
 PROG1.var1:=PROG1.var1+1;
 RETURN PROG1.var1; 
END;

Run PROG1, then PROG2 and you see that var1 has changed. If you run PROG1 again, it confirms that var1 really has changed. Likewise, you can alter PROG1.var1 from the Home screen as well.

You are correct. One can access a local variable that was created inside a program block by using its fully qualified name. Still, I found Han's explanation of program variables to be better than the explanation in the user manual. There was another exception about variables created in an app view functions, but I can't remember it.

[DrDarius]

(02-11-2020 04:34 AM)Gene222 Wrote:  For a good explanation of how to program with local variables, see 4.2) HP Prime Programming: Variable types and their priorities. This document is located within the HP-Prime: Documentation & Tutorials located at the top of this forum.

Thanks for the link.

A bit of nostalgia: I realize that no manual is perfect and usually the material filling the gaps follows.
For instance, let's consider TI84+CE's manual. It's also written in somewhat confusing way (stress put on also ).
But there is a book written by Dr. Christopher Mitchell which describes process of programming the calculator--when I was reading it, I found it occasionally explaining too obvious things (Chris: if you're reading it, sorry! ), but I learned the details of a few things which weren't initially clear to me.
When I bought HP Prime I looked for such a book, but, alas, there was none. Gap fillers are scattered all over the place and usually it takes a lot of time to find them. And often times to find this time is a problem. (Thanks again Gene222 for pointing me to the document.)

Maybe some HP Prime guru having spare time on hand should seriously consider writing "Programming HP Prime" book? I believe many would benefit from it (including the author who will get royalties).

Darius

[Joe Horn]

(02-11-2020 04:41 PM)DrDarius Wrote:  Maybe some HP Prime guru having spare time on hand should seriously consider writing "Programming HP Prime" book? I believe many would benefit from it (including the author who will get royalties).

Maybe nobody is doing that because all their work would become obsolete (at least partially) with the very next firmware update. The title would have to be "How Prime Was Programmed When This Book Was Published".

[CyberAngel]

(02-12-2020 03:18 AM)Joe Horn Wrote:  

(02-11-2020 04:41 PM)DrDarius Wrote:  Maybe some HP Prime guru having spare time on hand should seriously consider writing "Programming HP Prime" book? I believe many would benefit from it (including the author who will get royalties).

Maybe nobody is doing that because all their work would become obsolete (at least partially) with the very next firmware update. The title would have to be "How Prime Was Programmed When This Book Was Published".

No new features
unless the CAS can have separate libraries so that at least some extra external sublibraries can be added. XCas documentation is readily available.

I see no changes coming to the actual HPPL programming.

[cyrille de brébisson]

hello,

HPPL has changed over the years...
One of the latest thing has been about the passing of local variables to the CAS system in PPL/Cas interactions...

This was done around 1.5 year ago if I remember well. A pain to implement :-)

But it is true that the language is relatively mature, so changes are less, and less important than they were at the begining.

Cyrille