+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: Articles Forum (/forum-14.html)
+--- Thread: HP Prime Programming: Variable types and their priorities (/thread-215.html)
HP Prime Programming: Variable types and their priorities - Han - 12-23-2013 04:02 AM
Edit: Last updated 24-JAN-2013: Added new information about local variables; removed notion of "unexported global variable" as they are really just another form of local variables with a wider scope
Below is a categorization of the types of variables and their priority according the parser. The information was provided by Cyrille; I have added some details with the hope that they add clarity. From highest priority to lowest:
1. Local Variables
There are two types of local variables. The first type is limited in scope. These variables are created inside a procedural function (a "program"; see further below). They are created and only exist during the execution of the procedural function. After the function has completed execution, the variables are discarded (presumably deleted). Similarly limited in scope are local variables which are declared as arguments of a procedural function (see example below). They are essentially the same as local variables declared by using LOCAL within a procedural function.
The second type is a local variable declared outside of a procedural function but within a source file. This local variable is usable by all procedural functions defined in the same source file. These variables can be declared by either LOCAL variablename; or simply variablename; -- make sure they are defined outside of a procedural block. A good place is at the top/beginning of a source file. Such a local variable retains its contents even after program execution reaches completion.
Local variables are not accessible by the user, or anything else that is not defined within the same source file. That is, if MyVar is such a local variable, and MyProg() is a procedural function (program), and both are declared/defined in the same source file, then MyProg may access MyVar. If another procedural function MySecondProg() is defined in a different source file, then it may not access MyVar.
Local variables that are declared outside of a procedural block retain their values even after program execution has completed (much like global variables). Their scope is from the point of declaration to the end of the source file. This is why it is generally a good idea to place their declarations at the beginning of a source file.
Code:
LOCAL var1; // this local variable may be used by any procedures defined blow this line of code
var1; // alternate syntax for the line above (use one or the other!)
// in the procedural function named EXAMPLE below, three local
// variables are created: a, b, and c. They are equivalent to having
// used LOCAL a,b,c; as a line within the procedural block in that
// their scope is limited to just EXAMPLE()
EXPORT EXAMPLE(a,b,c)
BEGIN
LOCAL var2; // local variable whose scope is limited to within EXAMPLE
var1:=2; // var1 may be used by anything defined below the declaration of var1
END;2. System Global Variables and Functions/Commands
The system variables are built-in variables which store only specific objects. They may not be deleted and are always present. As a result, they may be used without ever being declared. They are:
- Real numbers may be stored in variables named by the single capital letters A through Z, and the symbol \( \theta \); initial value is always 0.
- Complex numbers may be stored in the variables Z0, Z1, ..., Z9; initial value is 0.
- Lists may be stored in L0, L1, ..., L9; initial value is an empty list: {}.
- Matrices/Vectors may be stored in M0, M1, ..., M9.
- Graphics objects are stored in G0 (the current screen), and buffers G1, G2, ..., G9.
3. Current App Functions and Variables
These variables/functions are associated with the current built-in app or custom app. The name of the current app is displayed at the top of the screen at the Home view or CAS view. The variables/functions associated with built-in apps can be found using the connectivity kit. Simply open the connectivity kit, and select the Content tab appear at the far left of the connectivity kit window. Click on the [+] next to the Application Library label, and then double-click on the name of the built-in app. A new (sub)window will open up and show the various built-in variables/programs associated with that app. For example, clicking on the Symbol tab for the Function app reveals the variables F0, F1, F2, ..., F9.
Custom apps are current based on existing built-in system apps. They inherit all the variables/functions of the built-in app upon which they are based. So if one creates an app named MyApp based on the Function app, then MyApp will have all the same variables/programs that are associated with the Function app in addition to any new variables/functions created within the app source file.
App variables/functions can be accessed one of two ways: via qualified names or unqualified names.
Fully qualified names. Suppose the current app is the Advanced Graphing app. However, should one need to make use of the variable named MyVar from the custom MyApp app while keeping the Advanced Graphing app in view, then the variable must be fully qualified by the name MyApp.MyVar (provided MyVar is exported; see further below). The variables/functions of built-in apps are an exception (explained further below). One special qualifer is the CAS qualifier. For example, if function is a CAS command, then CAS.function() is a means for calling the CAS function from non-CAS environments (i.e. Home view or within a program).
Unqualified names. Suppose the current app is MyApp which contains a variable named MyVar. While it is perfectly valid to refer to this variable using the fully qualified name MyApp.MyVar, one may simply refer to this variable using the unqualified name MyVar. The same holds true for variable/function declaration.
4. Global variables/functions (programs)
Global variables are declared inside a source file using the EXPORT command. They are then created at compile time -- i.e. after exiting the source file (or by pressing Check in the menu while editing the source file via the Program Editor). Global variables always retain their assigned values because they remain resident in memory. Global variables cannot be deleted except by removing them from the source file in which they are defined.
Exported variables, once created, behave similar to the built-in system variables (e.g. the A through Z variables). That is, the user, any other procedural function or program or app may access and modify these variables. Moreover, once an exported global variable has been created, any procedural function or program created later on may use these variables without having to declare them. (Note the emphasis on the pre-condition.) Exported variables may be "deleted" only in the sense that their values may be reset via the Memory Browser. They can never be purged in the sense that the memory allocated to these variables can never be deallocated (except for removing their definition from within a source file).
Exporting a function makes that function behave as if it were a built-in command. It can be used in the command line, or called by any program or procedural function -- provided that the programs calling such a function is compiled AFTER the function itself is compiled. That is, if MyProg2 calls MyProg1, then the source of MyProg1 must be compiled first!
A function that is not exported is neither accessible by the user, or other programs residing in a separate source file.
Remark: In a previous edition, I referred to non-exported global variables. These are actually local variables with a larger scope.
5. Unqualified Built-in app variables/functions (programs)
For example, the variable F1 is a symbolic variable used by the Function app. One may simply use F1 as a variable without having to declare it, and without having to fully qualify the name as Function.F1. These are not a new type of variable (same as #3), but they have a different priority level when called by their unqualified names.
6. User Variables (Home)
These are the variables which are created by something like MyVar:=2; at the Home screen. (An equivalent method is to use the Sto▶ command accessible by pressing the [Shift] key followed by the [EEX] key.)
7. CAS Variables
These are like the user variables, but created within the CAS view. In the Memory Browswer or Program Catalog, they have the (CAS) designation next to their name.