The Sequence List implementation defined here was accepted apart from a storage mechanism associated with ADSQLS. When this command is used either inside or outside a file there appeared to be two useful starting conditions: the global conditions current when the initial DRAW is called or the conditions current when the sequence item is first entered and obeyed. The case described in the paper (the conditions current at the time the ADSQLS order was obeyed) will not prove very useful in practice.
To distinguish the conditions two routines will replace ADSQLS.
(a) ADSQLL
add to sequence list and start item with the conditions current at that time.
(b) ADSQLG
add to sequence list and start item with the conditions current when the initial DRAW is called.
Thus a sequence list item will not necessarily always have the global conditions at the top of the stack. In practice the global conditions will always be stored in the first location in the stack. On entering an item for the first time the top of stack pointer will point either to the global conditions or to a new block containing the current conditions (so each sequence item must be marked to indicate which). On exit at the end of the sequence item, restoration of conditions will be performed from the head of stack unless this is the last remaining item in the sequence when the global conditions will always be used.
It is likely that it will be necessary to split routine RSSQLS to indicate that conditions are to be restored on resurrection.
Although the suggestion put forward in para 4.4 of SPROGS PAPER 21 was generally accepted it was felt preferable to refer to local variables by name. The following routine would be defined
LOCAL ( 'name' )
This may only appear within a file definition and indicates the name of a local variable. Up to seven names (using separate calls to LOCAL) can be defined in this way, the names being associated with variables by position. Thus
LOCAL ('A1')
LOCAL ('A2')
LOCAL ('A3')
will associate A1 with variable 1, A2 with variable 2 and A3 with variable 3. Subsequently any reference to an index variable in the file will be checked to see if it is a local reference, If so, instead of the real number version of the text name being planted, a negative number pointing to the local variable will be used. We thus do not need the extra routines LR, ALOCAL.
A1so we can use ARG to reference local variables by call order rather than by explicit reference viz:-
ARG (X)
ARG (Y)
ARG (Z)
would plant X Y Z in the first three local variables of the next file to be drawn.
The example at the end of paper 21 now becomes
STDF ('FRED')
LOCAL ('x')
ADD (ANAME('X'), 4.0)
TOXY (PR1('X'), PR2('Y'))
FIDF (1.0)
ARG (20.0)
LOAD (ANAME('Y'),3.0)
DRAW (ANAME ('FRED'))
with FRED stored as
Display Routine Marker Arguments ADD 0 -1.0, 4.0 TOXY 5 -1.0, real number for Y FIDF 0 1.0
This implies the following routine changes.
a. RCNCL must detect negative numbers and satisfy parameters from local space if necessary.
b. PR and AR must search the local name table and set negative local pointers in place of the real number representation of the name.
c. ADD, LOAD etc must also search the local name table in the same way. However, this scheme will not allow indirect references to local variables in these routines since
LOAD (ANAME('X'), ANAME ('Z'))
will always load the real number form of Z into X, so
ADD (PRI ('X'), 2.0)
will reference the global variable Z, unless a new routine (ALOCAL) is retained to allow
LOAD (ANAME('X'), ALOCAL ('Z'))
Discussion of the subject covered
a. The form of file table entry b. The structure of library on backing store c. The mechanism for calling library. items d. The mechanism for updating a library e. The mechanism for preserving space in the filestore
The following plan was suggested:
Libraries should be associated with streams. Two routines GETLIB (N) and GETFILE ('name',N) should cause entries to be made in the file table for each item in library N or for file 'name' from library N. The backing store pointer in the table would point to the correct file but no entry in the file store would yet be made. DRAW would transfer a file from backing store to filestore if it was not there already but would abort if the requested file name was not in the file table.
It would be possible to conserve space in the filestore by deleting such files occasionally, in which case some form of garbage collection would be required, and zeroing the store pointer in the file table entry. This assumes that the libraries remain unaltered during a run, so updating of libraries would have to be done separately.
Libraries can therefore be stored as a directory (hashed) pointing to the files. Backing store pointers in the file table will reference the associated stream number and the position of the stored file itself (not the directory entry for that stored file).
Experience with GROATS suggests that a user will not use a vast number of files during a run. However fonts prove an exception to this since it is normal to use two or three concurrently. If we have an identical mechanism for fonts, the file table will need to be very large. A possible solution to this would be to always set up a standard font at the beginning of a run, thus earmarking the first 64 locations of the file table for characters. The display routine
FONT (N)
would bring down 64 files from library N overwriting the first 64 entries in the file table if the file names coincided. It would be a lengthy process however to delete the overwritten items on the filestore since a large garbage collection will be required (unless for example fonts are a1ways stored at the far end of the filestore so that overwriting is easy, and no garbage collection is required. This would prove difficult to work if the concept of an expandable filestore is used.) Another problem concerns the access to lower case variables which will have to be in a separate font. Text consisting of a mixture of upper and lower case would certainly cause considerable overheads if fonts were swapped in every time the case changed. On the other hand fonts associated in this way could be defined using separate file numbers (in contrast to an earlier proposal to have all fonts distinguishable by file number, it is better to distinguish fonts by library number and associated fonts by file number), implying that access to lower case letters would involve a longer search in the file table.