We have hit various problems in the current definition of SPROGS which require discussion. This paper tries to consider them.
The various NULL routines, 1 to 6, have been provided to allow files to be built-up which can be used to produce varying results, and even to contain data to be read by other programs (via index variable arrays). Currently, when a NULL is obeyed, the last display routine called is resurrected. This leads to the following problems.
a. Only low level routines can ever become the last routine obeyed, since, for example, VEC will call SETXY, TODXY - and so a NULL following a VEC will resurrect TODXY.
b. DRAW is a display routine, so a file consisting solely of NULLs will always resurrect DRAW. To overcome these problems, a new display routine
NULSET (X)
will be defined. (It has to be a display routine so that it can be included, if necessary, within a file.) X will be a display routine number, which may not be 'NULL'.
Example
NULSET (DSRTNM('TODXY '))
NULL2(DX, DY)
would be obeyed as
TODXY (DX, DY)
Currently, it is possible to access information in a file as data by the use of index variable arrays. The use of the function set AR1, AR2 etc indicates a trio of variables defining a file and a position within that file, However, what this-position actually defines is open to question. If general files can be accessed in this manner, the position could indicate either the nth item in the file including display numbers, parameter indicators, etc, or the nth argument in the file, ignoring display numbers and parameter indicators. In either case, the fact that the file consists of display routines with variable numbers of arguments means that, unless separate 'current position' pointers are used for each array, the file must be scanned from the beginning, with each item being read, every time an array access is used. The overhead thus generated would be prohibitive.
A possible solution to this problem (and incidentally an aid to the solution of the NULL problem as well) is to allow arrays to access only files which consist entirely of NULL commands. To avoid the difficulty of having variable numbers of arguments, only one basic NULL routine will exist, equivalent to NULL1, and NULL2 to NULL6 would convert into multiple calls of NULL. A file type has already been defined to indicate that the file consists solely of NULLs. It would be possible to remove the display numbers altogether from such files, to aid compactness. It is now possible, from the file type and storage mode information, to compute the location in store of an argument from the pointer in the array.
This will imply that NULL is not legal outside a file, and that, if the file is executed with the current display routine, defined by NULSET, requiring more than one argument, these arguments are taken from subsequent NULLs.
Example (abbreviated command form used)
STDF('DATA')
NULL(X1)
NULL(Y1)
NULL(X2)
NULL (Y2)
FIDF
NULSET(DSRTNM('TOXY'))
DRAW(' DATA')
is equivalent to
TOXY (X1,Y1)
TOXY (X2,Y2)
and array access to DATA with the pointer at 3 would yield the value x2.
The above scheme will now prevent a user from defining an existing drawing (say a circle) as a possible p-curve, since the drawing would not consist of NULL commands. To recover this facility, it will be necessary to allow a user to convert a given file into NULLs by just copying across the arguments. Initially this should be sufficient, but later it will probably be necessary to convert one file into a number of files, each of which will contain one connected curve from the original file.
This does not affect the question as to whether indirect references are to be allowed (ie, if an argument is flagged as an index variable reference, should the contents of that variable be returned by an array reference). Initially, no indirection will be allowed.
At present, file numbers are reset to 1 after each routine that accesses a file (such as DRAW, STDF, etc). This is normally the requirement, but if different fonts are to be accessed by different file numbers, there is quite an overhead involved in resetting the file number between each DRAW of a character.
It therefore seems to be reasonable to add an extra FIDF type which leaves the file number unaltered on exit from a file, and to use this when defining character files. Also, it would help if the user could define his own number, which would be taken, instead of 1, as the default number. Thus
TEXT('AbC')
where b was in a different font, would be translated into, say,
Draw A
Select 'currentnumber+1'
Draw B
Select 'standard(original)number'
Draw C
Thus file numbers will be selected by
NUMBR(n) select number n for the next (and possibly subsequent) files. BNUM(n) select number n as the standard file number. RNUM(n) select number 'standard+n' for the next (and possible subsequent) files.
Then the FIDF option will either leave the file number alone, or reset it to the standard number.
At present, an entry in the File Table points to an entry in the Name Table which points to text in the String Table. Apart from the overhead of having to go through a second table to get to the text name, and of having the Name Table filled as well as the File Table when files such as fonts are read down, there is a problem associated with saving files in libraries. Suppose a file contains a DRAW command, and that file is written to a library and read down later into a different environment. Then the new Name Table, String Table and File Table. may all be different, and bear no relation to the pointer saved with the DRAW in the file. To preserve the intended effect of this file, the actual text of the file name must be saved with the DRAW.
FORTRAN does not allow text to be used in assignment statements, nor to be stored in real numbers. Thus to store the text would require a PLAN routine to plant an integer argument. This conflicts with, for example, normal mode storage, where all numbers are to be stored as reals. If the storage modes only imply the number of bits to be stored (eg normal mode means 'store 48 bits as a bit pattern'), the whole storage system will need to be in PLAN, and the storage routine will be called with arguments sometimes real and sometimes integer, which is unlikely to work on other machines.
An alternative system is to store the characters in real numbers, packing as many into a word as possible, by using multiplying factors. On the 1906A, with a 39-bit matrix, we could store six, 6-bit characters in one floating point word by
word1 = 64.0*word + char number
for each character.
We could store more characters in a word if we limit the number of characters allowed. For example, it would be no great hardship to 1imit file names, index variable names and display routine names to contain letters and numbers only, thus using 37 as multiplying factor. This would not of course do for TEXT. The number of characters actually stored would depend on the machine used. For example, 7 characters could be stored on the 1906A, and 5 characters could be stored in a real number having a 26 bit mantissa.
Since character codes vary from machine to machine, the number used in the above computation would be the SPROGS character number (as used in PLOT). This means a reordering of the SPROGS character list.
This scheme will remove the need for a String Table. All names can be stored in place of string pointers now, although it does mean that some tables that were originally integer will now become real (or be split into real and integer parts). The Name Table will only be used for index variable and array equivalences.
The above plan does not include TEXT, when a user will require to output all printable characters, and not be limited as to number. The routine TEXT will be divided into a series of calls to STEXT, which will have one real argument. This argument will consist of characters converted as before but allowing all 64 possible printing characters. To allow for different machines word sizes, it will be necessary to store only 4 characters per word. The SPROGS character list will need to be reordered to set all the printing characters in the first 64 places.
Example
TEXT('ABCDEFGHIJ',10)
will become
STEXT(X1)
STEXT(X2)
STEXT(X3)
where X1 is the number from ABCD
X2 is the number from EFGH
X3 is the number from IJ
STEXT is a display routine and can be stored in a file.
Fonts will have to be defined in batches of 64 characters. Thus lower case will be in a separate font. Therefore it will be necessary to define at least one printing character to represent 'change-font', and maybe even two (one for 'select font + 1' and the other for 'select standard font'). Each font character will be defined so that the font (file) number remains unchanged after drawing. Thus STEXT will have to detect these special symbols, and introduce NUMBR commands in place of DRAWS. The user must be able to select his own shift character representation so that it will always be possible to print all characters.
Example
[ means 'select standard font +1'
] means 'select standard font'
TEXT('A[B]C',5)
becomes
STEXT(number from A[B] )
STEXT(number from C)
RNUM (0.0)
(the last command ensures that each call of TEXT starts in 'upper case').
which becomes
DRAW(number for A)
RNUM(1.0)
DRAW(number for B)
RNUM(0.0)
DRAW(number for C)
RNUM(0.0)
Similarly, 'newline' will be representable by a printing character.
The SPROGS manual should contain an appendix describing the plotting areas of each hardware output device available locally.