DRAW has been altered so that, if the routine is called inside a file definition, and the local priority setting causes it to be executed, the commands contained in the specified file are stored instead. The jump table in OBEY remains unaltered.
Local priority does not enable a user to convert an absolute file to a relative file if SETXY orders occur. Also, since all point routines are equally fast in execution, use of local priority does not necessarily speed the execution of a file, given the current priority settings of the display routines. The only effect that the use of local priority has on a routine such as TOX is the ability to store this as a TOXY call or as a TODXY call. In both cases, index variables are evaluated at file definition time, and in the case of TOXY the arguments are calculated with respect to the current values of XPOS, YPOS. Thus it is possible> by altering the environment when the file is DRAWn, to cause TOX to produce a non-horizontal line!
It has therefore been decided that the priority system should change so that SETX has the same priority as SETXY and TOX has the same priority as TOY. There should not be much trouble caused by a file consisting of a mixture of TOX, TOY and TOXY orders, say, rather than just TOXY orders, when using it in a context such as in-betweening.
Much discussion took place on this subject with the following results and comments:
As most of the non-display routines need to be accessed by Data mode, and as the file execution jump table does not allow storage of commands, a new jump table independent of the one in OBEY will be required. It should be possible for users to add new items to this table (by recompilation) and hence introduce new Data mode commands.
It was decided that Data mode should be a subset of the input expected by the pre-processor, so that the same cards could be input to both. This led on to what format the pre-processor expected. The following suggestions were made:
a. the pre-processor shou1d accept normal FORTRAN statements, or 'free format' FORTRAN. The word CALL would be omitted from subroutines.
b. FORTRAN orders such as IF, DO etc and all SPROGS routines would be considered reserved words.
c. Continuation cards would be signalled by- at the end of a line. Identifiers should not be split over a line.
d. Thus, in Data mode, the normal command form would be
TOXY (2,3)
or
TOXY 2,3
with integers being widened to reals. This form would also be acceptable to the pre-processor. Data mode however can only refer to existing SPROGS commands, with no extra FORTRAN inclusion.
e. Index variables, arrays and file names need to be distinguished in SPROGS routines. No final agreement was reached, but the following is a possibility:
All file names enclosed in' ' eg 'J1M'
All index variables (accessed by PR) are referenced by . ' ' , eg .'FRED'
All arrays can be explicitly specified as triples by , eg, .'A:B:C'
or by declaring one variable for the triple using a new routine, AR, eg
AR ('SAM', 'A','B','C')
.'SAM'
Use of : in this way implies restricting the characters allowed in an Index variable name.
This means that the following are equivalent DRAW
DRAW('FRED') and CALL DRAW(ANAME('FRED'))
DRAW(.'FRED') and CALL DRAW(PR1(ANAME ('FRED')))
AR'SAM','A','B','C')
TOX(.'SAM') and TOX(AR1(ANAME('A'),ANAME('B'),ANAME('C')))
f. The following shorthand for a string of null commands can be used.
NULLS ( , , , , ...)
g. It is likely that Data mode will produce as output a string similar to that read from a file,
ie Routine number,IPRMV setting,Arguments.
The PDP15 will probably send text strings across the BSI, as this appears to be the easiest form at the moment. SPROGS commands on the PDP155 will have provision for the insertion of arguments from lightpen, tablet etc, and this form of transmission should avoid a complete parse by PIGS being necessary.