1. Note 8 defined a method of controlling local workspace within a file, and passing arguments across to another file. It does, however, suffer from two defects :-
(a) The fixed number of local variables means that either the user will be restricted (by the number of arguments passed) in the amount of workspace, or the number of variables allocated per file will cause wastage of space.
(b) Values cannot be passed back from one file to another via arguments (ie. a true dummy variable scheme).
1.1 The first restriction as imposed so that fixed blocks could be allocated in the file stack for workspace, thus simplifying the stack handling system. However, variable sized working areas can be controlled by the use of a separate stack. Each sequence item would have a fixed block of store allocated to it for local variables. Within this block, a variable stack of local space for each file can be organised. The proposed method of local declaration at file definition time means that the number of variables required by a file is known, so this information can be kept in the file header. Thus on entry to a file via DRAW, the pointer to the head of the local variable list for the calling file can be saved in the stack, and a new set of space allocated for this file. This space would not be initialised, and would be lost on exit from the file. FIDF and ADVFLM would restore the local workspace pointer correctly.
The advantage of this method is that one file can be allowed a considerable amount of workspace, at the expense of other files in the same sequence. However, one must allocate, for each sequence a suitable amount of space (say 50 words).
1.2 A possible mechanism to allow arguments to be passed by location as well as by value involves having two entries per variable in the variable stack (implemented as two parallel stacks). One entry would contain the value of the variable, whatever it was, and would be accessed by the PR, AR mechanism in the usual way. The second entry would indicate whether the variable was an argument called by location (non-zero entry) or not. An argument called by location may reference either a local variable in the calling file (indicated by +n, where n is the variable position in the variable stack) or a global variable (indicated by -n, where n is the position in the global table). Routines such as LOAD, ADD, etc would update the variable value in the stack, and also the value of the referenced variable (if it exists). It would also be necessary to specify, by different versions of the routine ARG, what form of argument passing is required.
Note that, at file definition time, the only variable distinction is between global and local. There is no indication as to whether the locals used within that file are to be pre-set, to be local only, or to return values to any calling file.
Another possibility is to make the dummy-local distinction (by another file declaration, DUMMY say, in place of LOCAL) and allocate an extra bit per display routine argument to the IPRMV marker, indicating whether the value is referencing a dummy or not. Adding the restriction that al1 DUMMY calls occur before LOCAL calls, we can ensure that all dummies will be the first variables in the local list. If we add the further restriction that only call by location will be allowed, the routine ARG will plant an address (+ve for local, -ve for global) in the dummy location. The setting of the IPRMV list will cause RCNCL to treat the contents of the local variable referenced as a dummy, and access the true variable for the value. Routines such as LOAD, ADD, etc, will have to set the IPRMV bit themselves to indicate dummy access, and indirection here (the use of PR in the first argument of these routines) will not be possible. This system appears to be too restrictive.
To compare these two systems, consider the two sets of functions
LOAD (ANAME('X'),ANAME('A'))
ADD (PR1('X'),2.0)
and
ADD (ANAME('A'),2.0)
We would like these two sets to be equivalent, whether X and A are globals, locals or dummies. Consider the case where A is a dummy and X is local. Then, under the first scheme, the declarations
LOCAL ('A')
LOCAL 'x')
would be sufficient, and the two sets would become (within a file).
routine IPRMV arguments
LOAD 0 -2.0,-1.0
ADD 1 -2.0,2.0
and
ADD 0 -1.0,2.0
However, under the second scheme, the declarations are
DUMMY ('A')
LOCAL ('X')
and the two sets become
LOAD 0 -2.0,-1.0
ADD 1 -2.0,2.0
and
ADD 4 -1.0,2.0
which are not equivalent. There is no mechanism for passing the fact that the contents of X is the address of a dummy (as opposed to a local).
However, we can modify this second scheme somewhat by storing with a file not only the number of local variables used, but also the number of dummies. Then the extra IPRMV bit is not required, the low number of the local variable itself indicating that it is a dummy. This third scheme therefore does not require the extra entry for each variable in the variable stack, but still restricts the user somewhat by not allowing call by value.
The previously described method of accessing arrays (that is, when meeting AR('FRED'), for example, access the three index variables FRED1, FRED2 and FRED3) will not work for locals, since the naming system is not the same. There are a number of possible solutions.
(a) Do not allow array references using locals. This would appear to be unnecessarily restrictive.
(b) Use a different method of access, depending on whether the name FRED is declared local or not. If it is 1oca1, the array is considered to be the local variable FRED followed by the next two local variables. It seems a pity to have two different mechanisms.
(c) Always declare arrays before use:
ARRAY ('FRED1', 'FRED2', 'FRED3')
would create three index variables which would be adjacent (an error would occur if any of the names had been already defined). 'Thus we would use
AR ('FRED')
to access the array, whether it is global or local. This scheme will not allow 'mixed' arrays, where the variables declared are not of the same type (local, global or dummy) .
(d) Always specify the three index variables required as arguments to AR, and allow the pre-processor to clean up the syntax. We no have a problem on how to handle three variables in place of one, when storing the display routine call in a file. One possible method is as follows.
The function AR stores a marker in IPRMV as before and plants the three index variable 'addresses' in a separate table, returning a pointer to this table as argument. STORE will plant the three addresses in line in the file entry. RCNCL will pick up the three 'addresses' either from the file entry or from the table, depending on context, and satisfy the array reference. Thus the arguments of
TOXY (AR1('A','B','C'), AR2('X','Y','Z'))
are converted to
arg 1 pointer to array table A
B
C
arg 2 pointer to array table X
Y
Z
and IPRMV = 10 (indicating both arguments are arrays).
If we are storing the call, the storage is
routine IPRMV arguments
TOXY 10 A, B, C, X, Y, Z
and if we are obeying it, RCNCL will get the triplets either from the array table (not within a file) or the argument list (within a file).