Author: Han Duong (original article)
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:
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). The 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
If another procedural function
MySecondProg() is defined in a different source file, then it may not access
Local variables which 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.
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)
LOCAL var2; // local variable whose scope is limited to within EXAMPLE var1 := 2; // var1 may be used by anything defined below the declaration of var1END;
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.
Z, and the symbol
θ; initial value is always
Z9; initial value is
L9; initial value is an empty list:
G0(the current screen), and buffers
System global variables, functions, and commands are of the same priority.
They are all of lower priority than local 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
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
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.
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
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
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.
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.
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
These are like the user variables, but created within the CAS view. In the Memory Browser or Program Catalog, they have the (CAS) designation next to their name.