d.ap ;.rm 70 .subtitle QUALITIES ,.page .hl 1 ^&APL QUALITIES\&  X APL is a very powerful and interesting language. Much of this power almost seemed designed to make the life of an implementer difficult. This section discusses some of these qualities, and the solutions that were chosen in programming SCI__APL. L .hl 2 ^&APL is INTERACTIVE\&  x APL has the capability of defining statement sequences, i.e. functions, whose meanings @are not fully defined until these statements are executed, and thus may be different from one execution to another. This derives from the fact that ldata structures are not pre-defined, but are dynamically defined as the system is used. In fact, even the type of an element is not 4defined at the time a line is entered, but only when it is executed.   Thus, for example, a statement of the type: ` ######### a = b ( could be the replacement of the variable "a" 1) by the scalor "b", 2) by the T vector "b", etc., or even 3) by the result of executing the function "b". The meaning of this statement can only be determined when the  statement is executed. In order to handle this in the simplest of H ways it was decided to maintain the text of functions, i.e. defined code sequences, in source form, and interpret them each time they were encountered. t  This was carried to its logical extreme, so that in order to execute <a function the following interpretations are done.  .list h .le ;The header line, that defines the arguments, is interpreted 0both on entry and exit  .le ;The lines are then interpreted, both at entry, \and exit, to establish labels,  $.le ;Then as each line is encountered, it is interpreted to execute it.  P.end list  .note |This is the first area that should probably be optimized. It has been pointed Dout that it is possible, at least, to do an inital syntax scan of the statement when it is entered. This scan could determine the tokens, i.e. the APL operators pand the identifiers which may be operators or variables. Thus it should be possible to compress the function definition in a 8more compact and efficient way than by saving the input source text. .en  d.hl 2 ^&APL is an ENVIRONMENT\&  , APL consists not only of a language, but a total environment that permits users to read, edit and restore files, as well as storing and restoring the current status Xof the APL system for later use.   This required the addition of a text editor, and save restore capabilites. Since I and many other users were familiar with the VAX SOS editor, Lit was decided to make the editing of APL functions similar to normal SOS editing, in that the commands are a small subset of the SOS commands. x  This editor is adequate to write and edit APL functions, but @obviously not enough effort could be spent to write a good general editor. I think that an ideal  way to edit the APL functions would be to spawn a sub-process which l would permit the standard VAX editors to be used. 4!.hl 2 ^&SCI__APL should support VAX files\& ! ! SCI__APL should read and write a reasonable subset `"of the files used by the rest of the VMS operating system. " (# This required the addition of a file open capability, and #a linguistic way of reading and writing character and binary files, #in addition to its own internal file formats. T$ $ Due to the pressure of time this is an area which has not %been fully developed. The syntax for opening and closing %files is as follows: % H& #########)unit no {w or r}{a or b or c} {file__name} & ' where: t' ' #########no .. defines the APL unit number. <( ( #########w or r .. defines if the file is WRITTEN or READ. ) h) #########a or b or c .. defines the type of the file, )i.e. APL, BINARY 0*or CHARACTER. * * To read or write a file "L[no]" is used on the right or \+left of a replacement, i.e. as the source or target of data. +There is a special case, currently only implemented $,for output. If unit 0 is opened for writing, then the normal terminal ,output will also go to the file. This permits the user to "save" the ,results of his computation for later examination. P- -.hl 2 ^&SCI__APL should support both APL and ASCII terminals\& . |. APL is normally run using a terminal with, at least as .far as the implementer sees, only lower case D/alphabetic characters /and "strange" characters, i.e. operators, 0instead of the shifted alphabetics. In addition p0many of the symbols are in a different place 0than on a standard, VT-100 keyboard, and some of the APL operators are actually 81composed of the combination of a character, back space, and another one, 1i.e. an over-strike character. 2 d2 Since I was debugging SCI__APL on a VT-100 it was not possible to 2effectively use all the true APL character set. ,3This required an alternate charcter set, ASCII, The ASCII character set 3was derived as follows: 3 X4.list 4 5.le ;Many of the APL characters are already shifts of alphabetic characters 5that make sense, or were used infrequently enough so that 5it was not too much a bother to look them up when they were used. L6In these case the standard APL keyboard 6position was preserved even though the "printed" character was not that 7of APL. Thus, for example, the Reshape operator was retained as a shifted "r". x7This meant that the user must remember that "R" means reshape if he is 7using an ASCII terminal. @8 8.le ;A few operations, e.g. replacement, "=", and divide "%", were arbitrarly 9defined so that they seemed reasonable to the developer. Other standard l9operations were chosen to match the ASCII character even though 9they are in a different place on the ASCII keyboard. For example, 4:the plus operator is the ASCII "+" despite the fact that on the APL :keyboard the "+" is in the place of the ASCII "-". : `;.le ;Since CRTs do not generally support the overprinted characters, ;except by (of DEC's PDP-11 APL. Thus, for example, the >reverse operater, which is an upper case "M", backspace, upper case "O" >can also be entered as ".rv". H? ?.end list @ t@ This required two tables that are currently read in each time @SCI__APL is started. These tables give the APL-to-ASCII translation of