☜	Local Variable Handling Draft MDC Standard					☞

7.1.2.2 Local variable handling

In general, the operation of the local variable symbol table can be viewed as follows. Prior to the initial setting of information into a variable, the data value of that variable is said to be undefined. Data is stored into a variable with commands such as Assign, For, Job, Merge, Read, Set, TCommit, TREstart, and TROllback. Subsequent references to that variable return the data value that was most recently stored. When a variable is killed, as with the Kill command, that variable and all of its array descendants (if any) are deleted, and their data values become undefined.

No explicit syntax is needed for a routine or subroutine to have access to the local variables of its caller. Except when the New command or parameter passing is being used, a subroutine or called routine (the callee) has the same set of variable values as its caller and, upon completion of the called routine or subroutine, the caller resumes execution with the same set of variable values as the callee had at its completion.

The New command provides scoping of local variables. It causes the current values of a specified set of variables to be saved. The variables are then set to undefined data values. Upon returning to the caller of the current routine or subroutine, the saved values, including any undefined states, are restored to those variables. Parameter passing, including the Do command, extrinsic functions, and extrinsic variables, allows parameters to be passed into a subroutine or routine without the callee being concerned with the variable names used by the caller for the data being passed or returned.

The formal association of local variables with their values can best be described by a conceptual model. This model is NOT meant to imply an implementation technique for a M[UMPS] implementation.

The value of a variable may be described by a relationship between two structures: the NAME-TABLE and the VALUE-TABLE. (In reality, at least two such table sets are required, one pair per executing process for process-specific local variables and one pair for system-wide global variables.) Since the value association process is the same for both types of variables, and since issues of scoping due to parameter passing or nested environments apply only to local variables, the discussion that follows will address only local variable value association. It should be noted, however, that while the overall structures of the table sets are the same, there are two major differences in the way the sets are used. First, the global variable tables are shared. This means that any operations on the global variable tables, e.g., Set or Kill, by one process, affect the tables for all processes. Second, since scoping issues of parameter passing and the New command are not applicable to global variables, there is always a one-to-one relationship between entries in the global NAME-TABLE (variable names) and entries in the global VALUE-TABLE (values).

The NAME-TABLE consists of a set of entries, each of which contains a name and a pointer. This pointer represents a correspondence between that name and exactly one DATA-CELL from the VALUE-TABLE. The VALUE-TABLE consists of a set of DATA-CELLs, each of which contains zero or more tuples of varying degrees. The degree of a tuple is the number (possibly 0) of elements or subscripts in the tuple list. Each tuple present in the DATA-CELL has an associated data value.

The NAME-TABLE entries contain every non-subscripted variable or array name (name) known, or accessible, by the process in the current environment. The VALUE-TABLE DATA-CELLs contain the set of tuples that represent all variables currently having data-values for the process. Every name (entry) in the NAME-TABLE refers (points) to exactly one DATA-CELL, and every entry contains a unique name. Several NAME-TABLE entries (names) can refer to the same DATA-CELL, however, and thus there is a many-to-one relationship between (all) NAME-TABLE entries and DATA-CELLs. A name is said to be bound to its corresponding DATA-CELL through the pointer in the NAME-TABLE entry. Thus the pointer is used to represent the correspondence and the phrase change the pointer is the equivalent to saying change the correspondence so that a name now corresponds to a possible different DATA-CELL (value). NAME-TABLE entries are also placed in the PROCESS-STACK (see 7.1.2.3 Process-Stack).

The value of an unsubscripted lvn corresponds to the tuple of degree 0 found in the DATA-CELL that is bound to the NAME-TABLE entry containing the name of the lvn. The value of a subscripted lvn (array node) of degree n also corresponds to a tuple in the DATA-CELL that is bound to the NAME-TABLE entry containing the name of the lvn. The specific tuple in that DATA-CELL is the tuple of degree n such that each subscript of the lvn has the same value as the corresponding element of the tuple. If the designated tuple doesn’t exist in the DATA-CELL then the corresponding lvn is said to be undefined.

In the following figure, the variables and array nodes have the designated data values.

Also, the variable DEF existed at one time but no longer has any data or array value, and the variable XYZ has been bound through parameter passing to the same data and array information as the variable VAR2.

NAME-TABLE		VALUE-TABLE DATA-CELLS
VAR1		() = "Hello"
VAR2 XYZ		() = 12.34
VAR3		() = "abc" ("Smith","John",1234) = 123 ("Widget","red") = –56
DEF

The initial state of a process prior to execution of any M[UMPS] code consists of an empty NAME-TABLE and VALUE-TABLE. When information is to be stored (set, given, or assigned) into a variable (lvn):

1. If the name of the lvn does not already appear in an entry in the NAME-TABLE, an entry is added to the NAME-TABLE which contains the name and a pointer to a new (empty) DATA-CELL. The corresponding DATA-CELL is added to the VALUE-TABLE without any initial tuples.
2. Otherwise, the pointer in the NAME-TABLE entry which contained the name of the lvn is extracted. The operations in steps c and d refer to tuples in that DATA-CELL referred to by this pointer.
3. If the lvn is unsubscripted, then the tuple of degree 0 in the DATA-CELL has its data value replaced by the new data value. If that tuple did not already exist, it is created with the new data value.
4. If the lvn is subscripted, then the tuple of subscripts in the DATA-CELL (i.e., the tuple created by dropping the name of the lvn; the degree of the tuple equals the number of subscripts) has its data value replaced by the new data value. If that tuple did not already exist, it is created with the new data value.

When information is to be retrieved, if the name of the lvn is not found in the NAME-TABLE, or if its corresponding DATA-CELL tuple does not exist, then the data value is said to be undefined. Otherwise, the data value exists and is retrieved. A data value of the empty string (a string of zero length) is not the same as an undefined data value.

When a variable is deleted (killed):

1. If the name of the lvn is not found in the NAME-TABLE, no further action is taken.
2. If the lvn is unsubscripted, all of the tuples in the corresponding DATA-CELL are deleted.
3. If the lvn is subscripted, let N be the degree of the subscript tuple formed by removing the name from the lvn. All tuples that satisfy the following two conditions are deleted from the corresponding DATA-CELL:
   1. The degree of the tuple must be greater than or equal to N, and
   2. The first N descriptors of the tuple must equal the corresponding subscripts of the lvn.

In this formal language model, even if all of the tuples in a DATA-CELL are deleted, neither the DATA-CELL nor the corresponding names in the NAME-TABLE are ever deleted. Their continued existence is frequently required as a result of parameter passing and the New command.

Copyright © Standard Documents; 1977-2024 MUMPS Development Committee;
Copyright © Examples: 1995-2024 Ed de Moel;
Copyright © Annotations: 2003-2008 Jacquard Systems Research
Copyright © Annotations: 2008-2024 Ed de Moel.

Some specifications are "approved for inclusion in a future standard". Note that the MUMPS Development Committee cannot guarantee that such future standards will indeed be published.

This page most recently updated on 17-Nov-2023, 10:51:31.

For comments, contact Ed de Moel (demoel@jacquardsystems.com)