System commands have always had a very important role in, or, more accurately, just outside, the APL language. They are the pidgin dialect which provides communication between the clean, abstract world of pure APL and the often messy environment of the APL system which allows APL programs to be executed. Despite their importance in the development and use of all APL applications, very little attention has been paid to them. They remain, in contrast to APL itself, ineffectual, irregular, and inconsistent. They have no regular syntax and return no usable result. There are two possible ways to deal with this situation. Get rid of them, or make them better. To date, most APL systems have been gradually implementing the first approach. One by one, system commands have been superseded by system functions and variables which do approximately the same thing. In the case of system variables such as □ IO and □ RL whose values effect the actual results of calculations as implicit arguments, this change has properly moved the ability to set these parameters into the province of the language itself. In the case of the system functions, however, the move has blurred the useful distinction between the language and the host environment and introduced a most unattractive collection of obscure English words and abbreviations into a previously ideographic language. By moving the English words out of APL and into the realm of system commands, we open up the possibility of having the actual words used be a function of some natural language selection facility such as □ NLT in IBM's APL2. One of the problems with the □-function approach is that APL functions take data arguments and return data results. This is, of course, what allows them to be used in ever more complex expressions. Unfortunately, since the environmental constructs acted on by system functions are not data, the arguments and results of system functions often bear only slightly on the main action which is taken as a side effect. Another problem is that an APL function works within a certain name environment (workspace), and generally cannot affect things outside of that environment. As large applications increasingly tend to rely on cooperation between many different workspaces, the need to make extra-workspace adjustments to the environment has become apparent. This is especially true in Analogic APL which is designed to facilitate the sharing of both functions and variables between workspaces. Starting a brand new implementation of APL is a great opportunity. We at Analogic decided to take advantage of it by providing a better environment for our favorite language to run in. Our approach was to leave the language proper alone (Analogic is committed to strict adherence to the ISO APL standard), but to rethink the way that APL applications interact with their environment. To take advantage of these enhancements, an applications programmer must set up a variety of links between different workspaces or name contexts. Usually, this only needs to be done once at the time an application is put together. The exact mechanism, called threaded workspaces, is described elsewhere [1]. The important points for this discussion are that the actions generally need not be dynamic and that there are many variations in the details of the connections. We decided that system functions were not the answer. Doing as many things as we envisioned by using system functions would have entitled either an unacceptably large number of confusingly named &squarel-functions (like the 135 found in STSC APL*PLUS/PC) or unacceptably obscure arguments to a smaller number of □-functions (like the left arguments of □ WS and □ FD in Sharp APL). System commands, many of which are already required by the ISO standard, can provide the answer so long as they are given a regular and self-documenting syntax, and the universe of names visible to any command is expanded to include names in workspaces other than the one in which the command is invoked. It should be understood that Analogic APL is a work in progress. The ideas expressed here reflect the current state of the specification of Analogic APL. Details such as the names of individual fields are likely to change as we the implementation progresses and we gather experience.
Search from 250 M+ research papersSearch from 250 M+ research papers
Open Access
May 1, 1986
Jim Weigang 
