Variables global to a program

[Bob Frazee]

DegF;Mph;wct;wcto;ft;

WindChillIntroDisplay();
InputPgm();
FrostBiteEqn();
WindChillEqn();
OutputPgm();

EXPORT TestWindChillPgm()
BEGIN
LOCAL K;
Additional program code here...

I do understand that the above bolded variables are only visible within the "TestWindChillPgm" program. In my experimentation, they appear to retain their values if the emulator is shut down and restarted. When I go into the memory manager (shift B), and select "user variables", they do not appear. Is there some other place to see them other than the program they are created in? I have searched and have been unable to find them anywhere. If not, will the memory manager someday be able to view them, edit their values, and delete them? Can these variables be purged(deleted) when the program is finished?
Thanks
rcf

[Michael de Estrada]

I don't know what you mean by "global to a program." How exactly did you create them in the first place. Global variables are seen everywhere in the calculator, including Apps. If you type any of them in Home view, do they display as values ?

[Bob Frazee]

Michael;
"Global to the program" means they can only be seen inside the "TestWindChillPgm" program file. Any additional subroutines in the above file can see the variables, but nothing outside that program file can see or mess with the variables. I created them by defining them at the very top of the program file (there are other threads under the Prime category that talk about this type of variable). If I type any of the variables in the home view, it asks me if I want to create a new variable, so it's not seeing them there. They appear to be hidden variables, taking up memory space, with no way to really access them or view them. This PPL language is really strange.
rcf

[Michael de Estrada]

OK. These are LOCAL variables, and therefore will not appear as User variables. Every time you run the program they are created, and once you exit the program they vanish into thin air. No need to delete or purge them.

[patrice]

Code:

EXPORT MyExpVar;
MyGlobVar;

MyIntFunc()
BEGIN
...
END;

EXPORT MYFunc()
BEGIN
LOCAL MyLocvar;
...
END;

MyExpVar is visible everywhere, in all functions of all programs, and Home and memory manager.
MyGlobVar is visible in all functions in this program
MylocVar is visible in this function of this program only.

Your program is responsible to initialize and clear all the variables it use.

[Bob Frazee]

Michael;
I suppose you could call them LOCAL variables, but they don't appear to behave like regular LOCAL variables in the fact they retain their values if you exit the program or emulator. A regular LOCAL variable will lose it's value once the program is exited, these particular variables do not appear to lose their values.

Patrice;
You said: "Your program is responsible to initialize and clear all the variables it use." I know how to initialize the variables, but am not clear if it is possible to purge (delete) them, within the program, like you can with User RPL. I could clear them within a program, but they are still there taking up memory space. The only way an EXPORTEDed variable can be deleted from memory is to manually remove it's definition from the program. A ":=" created variable can be deleted manually through the memory manager, but I have not found a way to delete it automatically when I exit the program. Your "MyGlobVar;" cannot be deleted through the memory manager(memory manager doesn't see it), nor have I found a way to delete it automatically when I exit the program. I hope this is a more clear explanation.

[Han]

Yes, there are two types of global variables (and this does not include built-in system global variables). As Patrice noted, there are exported global variables, and non-exported global variables. In both cases, global variables cannot be deleted. However, the contents of exported global variables can be viewed (and reset) via the memory browser. But they cannot actually be purged (in the same sense as in the HP 50G). You can, at best, have your programs reset them but storing the number 0 into them upon the completion of your program(s). However, they will still take up at least the size of a real number. Exported global variables may also be altered by the user without ever using any program or subroutine that created them. Non-exported global variables are basically the same as exported global variables, but they are not visible nor accessible to the user.

The scope of a global variable lies only within the source file that created it. That is, any program/subroutines within the same source file that created the global variable can make use of that variable. However, programs/subroutines from a different source file cannot access non-exported global variables.

In order for a program/subroutine to make use of exported global variables created from a separate source file, it must be created AFTER the other source file has already be completed AND compiled (i.e. exited from the program editor without errors). When that happens, the exported global variable is, for all intents and purposes, no different from a built-in system global variable such as X. As long as the program you create doesn't also create its own global variable of the same name, then there is no issue. And if it does, then the state of the global variable is basically ambiguous (and depends on the last compiled source file).

When you create a new program, what you are creating is really a new project source file, in which many programs can actually be created, all sharing the same resources (global variables). In fact, one may create a "new program" with file name "MYPROGRAM" and yet have no programs with that name. MYPROGRAM is more like a project name, and whether there is a program MYPROGRAM() all depends on whether you create such a routine within the source file named MYPROGRAM.

File 1 saved as "PROG1" with content:

Code:


EXPORT VAR1=3.14;

EXPORT PROG2()
BEGIN
  VAR1:=VAR1 + 1;
END;

EXPORT PROG3()
BEGIN
  MSGBOX("This is prog3 running!");
END;

File 2 saved as "PROG3" with content:

Code:


PROG4()
BEGIN
    VAR1:=2.718;
END;

If you edit source file "PROG1" first, and then exit, then two programs are created: PROG2() and PROG3(). There is no program PROG1(). A global variable is also created: VAR1. This variable is now visible to all other programs created from this point on. Now, if you create source file "PROG3", then the program PROG4() can use VAR1 as if it were like the global variable X. However, if you reverse the creation order (i.e. create source file "PROG3" before source file "PROG1") then it will not work and you will get syntax errors.

If we now create a new file

File 3 saved as "MYPROG5" with content:

Code:


EXPORT VAR1="123";

EXPORT PROG5()
BEGIN
  PROG2();
END;

Then we basically break PROG2(); because of the conflict in global variable names. Even worse, the behavior of these programs are dependent on which source file is compiled first.

This was an issue that was seen in the period table of elements that we saw a while back, prior to this new forum being created. Users of the English version were getting errors because that version compiled fine on the author's machine/emulator due to the presence of an exported routine of the same name in a different source file (which would not have been the case for English users).

[Michael de Estrada]

What is your basis for believing these variables "retain" their values. Like Patrice said, they exist only while the program is being executed and then they are gone. MyGlobVar does not exist outside the program, which is why it does not appear in the memory manager. Now, MyExpVar definitely exists and will appear in the User Program Variables list under whatever name you assigned to the program group. It will also retain any value you assigned to it. The only way to delete it is to delete the declaration itself inside the program. If you don't precede your variable names with EXPORT, they will not be retained.

[Han]

(12-22-2013 04:02 AM)Michael de Estrada Wrote:  What is your basis for believing these variables "retain" their values. Like Patrice said, they exist only while the program is being executed and then they are gone. MyGlobVar does not exist outside the program, which is why it does not appear in the memory manager. Now, MyExpVar definitely exists and will appear in the User Program Variables list under whatever name you assigned to the program group. It will also retain any value you assigned to it. The only way to delete it is to delete the declaration itself inside the program. If you don't precede your variable names with EXPORT, they will not be retained.

Code:


MYVAR;

EXPORT TEST()
BEGIN
  MYVAR:=MYVAR+1;
END;

Run TEST() a few times.

[Michael de Estrada]

(12-22-2013 04:43 AM)Han Wrote:  

Code:


MYVAR;

EXPORT TEST()
BEGIN
  MYVAR:=MYVAR+1;
END;

Run TEST() a few times.

Wow ! So, if you fail to explicitly initialize variables that are used as counters you will get unpredictable results. Also, I created a second program TEST1() in a separate program group with MYVAR; and it started at 1 and is not in sync with the MYVAR in TEST(). So, the variable name is not unique, and values are being stored at different locations. This is crazy.

Also, if I change the variable name to say MYVAR1, it resets to zero and increments again. Just for yucks, I did a soft reset (On Symb), but it did not reset these values. I've never encountered any programming languages that worked like this, and am having a hard time understanding the purpose if any.

[Snorre]

IMHO global non-exported variables are of huge value to store state information between program calls without cluttering the namespace (and VAR-Menu).
It's quite easy to reassign them to initial values every time the program starts (if needed).

[Han]

(12-22-2013 05:51 AM)Michael de Estrada Wrote:  Wow ! So, if you fail to explicitly initialize variables that are used as counters you will get unpredictable results. Also, I created a second program TEST1() in a separate program group with MYVAR; and it started at 1 and is not in sync with the MYVAR in TEST(). So, the variable name is not unique, and values are being stored at different locations. This is crazy.

Also, if I change the variable name to say MYVAR1, it resets to zero and increments again. Just for yucks, I did a soft reset (On Symb), but it did not reset these values. I've never encountered any programming languages that worked like this, and am having a hard time understanding the purpose if any.

No, failing to initialize variables just leaves a default initial value of 0. If you were to open and close the source file, the count starts back at 0. When you created a new program group using MYVAR, it created a new variable MYVAR unique to TEST1(), unless you exported it. I presume that you did not, so that MYVAR for TEST() is different from MYVAR for TEST1(). Bascially, unexported global variables are unique even with the same name. Exported global variables, however, are not. If MYVAR were exported (in both programs) then as soon as you exit the source file for either, MYVAR gets reset to whatever the exiting source file declares. As I understand it:

1. All global variables retain their value if the program using them do not re-initialize their values. The initialization of a global variable outside of a program (i.e. in a variable declaration line written outside of a program's BEGIN/END block) happens ONLY during compile time (i.e. when you press Check or exit the editor). Note that source files are not re-compiled every time a program is run.

2. Non-exported global variables are unique to the source file that created them. That is, if you create two source files that declare MYVAR (unexported) then two separate memory locations are allocated, one for each source file.

3. Exported variables of the same name have the same memory location. So two source files that export MYVAR will create only one instance of MYVAR. The initial value of MYVAR will be whatever the most recently exited source declares.

4. #1. through #3. also apply to actual program names that define a BEGIN/END block.

Because exported objects share the same memory location, this is the only thing that could possibly cause ambiguity. That is, if one source file creates an exported routine called PROG1(), and you forget about it, and later create a new source file that also exports a different routine that happens to also be named PROG1(), then this new PROG1() can possibly break old programs that used the older PROG1(). You can temporarily fix it by recompiling the first source file (but then the programs in the newer source file may break).

[Michael de Estrada]

Thanks Han. As usual, you have a deep understanding of this topic and are also able to explain it with great clarity. So, PPL is a compiler rather than an interpreter, such as with Basic, and once a source code has been compiler it remains so until opened again for editing, correct ? Are non-exported variables effectively the same as dummy variables, where the variable names are just compiled pointers within the program ? I guess I still can't get used to data being saved in this manner, having spend most of my life programming in FORTRAN and RPL.

[Han]

(12-22-2013 03:15 PM)Michael de Estrada Wrote:  So, PPL is a compiler rather than an interpreter, such as with Basic, and once a source code has been compiler it remains so until opened again for editing, correct ?
Are non-exported variables effectively the same as dummy variables, where the variable names are just compiled pointers within the program ?

Yes to both questions; that is how I understand it to be.