APL Objects Research Articles

Structured APL

APL, although a very powerful language, has failed to gain wide acceptance in part due to its lack of control structures. A proposal is made for introducing structure in APL objects by adding to the items that can be located on the left of the colon (:). These markers show the beginning and ends of blocks of code and allow for selection, iteration, and termination. The set of control structures is shown to be robust by showing their use in the creation of traditional control structures. A method of conversion to ISO APL is also presented.This paper briefly discusses proposals that have been made in the past along with an evaluation of their merits and shortcomings. The paper ends with a discussion of related issues, including elimination of branching, introduction of definition blocks, and lexical scoping in APL. Several areas for continuing work are given.

The workspace manager

This paper describes the Workspace Manager (WSM), a tool that helps to support and add discipline to APL system development and maintenance efforts.The WSM acts as a repository of APL objects (variables, functions, and operators). Programmers use WSM tools to find where objects are used, edit objects, save changed objects, and request that objects be installed into (or erased from) production workspaces.Periodically, the WSM installs new releases of production workspaces by merging new and changed objects into existing workspaces.Audit trails are maintained for all of these activities, making it possible to review the change history of an object, compare different versions of an object, compare different releases of a workspace, revert to an old release of a workspace, and so on.

The dual structure of ordered trees

Although they were described by K. Iverson in his 1962 book [1], ordered trees have never been implemented as APL objects. However, APL2 as well as ISO-APL, provide many facilities to handle them. This paper illustrates with simple examples, the duality between the tree-structure and what will be presented as an "object-oriented definition structure". APL functions are proposed to facilitate the conversion of one form into the other one. Trees have great utility in data base processing, as well in science, as in business applications. Interfaces with the "outer world" - e.g. word processors, or LISP and PROLOG can become easy to build with the help of this simple concept of duality.

APL object manager

In order to co-ordinate APL code written for the European Commission, which has several different computers (mainframes, minis and micros) and thus several different APL's, a comprehensive set of programming standards was developed. The standards outline, amongst other topics, how workspaces, APL objects and files should be structured, especially with respect to documentation. To aid the programmer to follow the standards, a development environment was produced and is now being used to develop systems written in DYALOG APL. The development environment guides the user through various programming tasks and organizes the documentation associated with each APL object. This paper discusses the concepts and facilities of the development environment with specific references to the standards.

APL object transfer in a multi-APL site

In order to transfer APL objects, workspaces and files between the different mainframes, minis and micros at the European Commission, two APL object transfer systems have been developed. One such system is based on using tapes and follows the Workspace Interchange Convention. This convention had to be extended since it does not handle generalized arrays and user-defined operators. The other system transmits data direct over the communication line. The STSC's supplied workspaces SERXFER and SERHOST have been used and modified to establish this. Since the Commission has several different APLs on its range of computers, some new approaches had to be developed, which are discussed in this paper.

Arrays of objects in rationalized APL

A number of proposals have been made so far to extend the array concept of APL to functions thus allowing functions of non-zero array rank [Bernecky 84, Brown 84]. Some of them required significant extensions to the APL language, both in syntax and in functionality. In this paper a scheme is presented which extends arrays to all classes of APL objects: data, function and operator . It is based on the extensions made by K.E. Iverson, first published in “Rationalized APL” [Iverson 83] and formally described in “A Dictionary of APL” [Iverson 87]. It is shown that the construction of arrays of any class can be achieved without additional extensions to the rationalized APL syntax. True generalized arrays, which may contain enclosed elements of any class, are introduced. A function application operator is proposed which extends the domain of a number of functions to function arrays. Finally the operator is used to rationalize vector and canonical representation of simple, derived and defined functions and function arrays.

APL function definition notation

A pure functional notation for defining APL objects is described, and constructed with previous work in this area. The notation is extended to address both theoretical and pragmatic programming considerations. The notation is compatible with existing implementations, and is shown to straightforwardly incorporate popular extensions to the language.

Editing APL objects with CMS XEDIT

The VM/SP System Editor XEDIT is used to edit APL objects. Two approaches are possible: with an APL function, or with an exec written in REXX (the new VM/SP System Interpreter). The advantages of the latter are that nothing need be copied into the user's workspace, and that APL code can be executed from XEDIT, and XEDIT commands from APL. No new Auxiliary Processor is needed. The technique is in use at IBM Yorktown.

Semicolon-bracket notation

The semicolon-bracket (SB) notation for indexing an array in APL has often been regarded unfavorably because of its anomalous character relative to other APL functions: the function symbol is a pair of brackets rather than a single character; the bracket pair is bound to the associated array at a higher precedence than any other function; and the requisite number of semicolons must appear literally within the brackets, so that the construct within the brackets when one or more semicolons are present is not an APL object, and therefore cannot be substituted for by another APL expression without semicolons. Nevertheless, this notation provides a simple way to index arrays of any rank, and has proven to be very convenient in practice. In this paper, it will be shown that the SB notation can (a) easily be extended to defined functions, and that it can also be used (b) to allow a multiplicity of names to be used unambiguously to the left of assignment, (c) to allow multiple statements on a line in a manner similar to that provided by the diamond separator in some APL systems, and (d) to extend and generalize the use of bracketed expressions as an axis operator.

The design of APL

This paper discusses the development of APL, emphasizing and illustrating the principles underlying its design. The principle of simplicity appears most strongly in the minimization of rules governing the behavior of APL objects, while the principle of practicality is served by the design process itself, which relies heavily on experimentation. The paper gives the rationale for many specific design choices, including the necessary adjuncts for system management.

The Design of APL

This paper discusses the development of APL, emphasizing and illustrating the principles underlying its design. The principle of simplicity appears most strongly in the minimization of rules governing the behavior of APL objects, while the principle of practicality is served by the design process itself, which relies heavily on experimentation. The paper gives the rationale for many specific design choices, including the necessary adjuncts for system management.