Adin D. Falkoff

A formal description of SYSTEM/360

All SYSTEM/360 functional characteristics having programming significance are completely and concisely described. The description, which is formal rather than verbal, is accomplished by a set of programs, interacting through common variables, used in conjunction with auxiliary tables. The language used in the programs involves operators and notation selected from mathematics and logic, together with additional operators and conventions defined to facilitate system description. Although the formal description is complete and self-contained, text is provided as an aid to initial study. Examples to illustrate the application of the formal description are given in an appendix.

Algorithms for Parallel-Search Memories

The underlying logical structure of parallel-search memories is described; the characteristic operation of three major types is displayed in the execution of searches based on equality; and algorithms are presented for searches based on other specifications including maximum, miniTnum, greater than, less than, nearest to, between limits, and ordering (sorting). It is shown that there is a hierarchy of dependency among these algorithms, that they appear in pairs with each member of a pair belonging to one or the other of two distinct classes, and that every type of search can be executed within each class.

Development of an APL standard

Following an extended period of development, with more than half a dozen iterations, a standard for APL was not long ago adopted for use within IBM. In this paper we offer some highlights of our experience in this development process, as well as an appendix containing the technical matter in the standard itself. If a standards effort should get under way in the wider APL community, this experience and its work product may perhaps be found useful, and it is offered here in recognition of this possibility, without any commitment on the part of the IBM Company to support or not support such an effort. It should also be understood that this material is not offered as a specification of the function or performance of any particular IBM product. Standards in a field as rapidly changing as computers are not static. This is particularly true with respect to a language like APL, which is still actively evolving. Hence, the document in the Appendix can only be regarded as a snapshot of where we are now. It does not by itself convey any idea of the development process that produced it, just as it does not necessarily represent in any specific detail what it might be in the future. In this paper, then, we will try to show something of the dynamics of the process we participated in by discussing the evolution of several significant aspects of the standard, and sketching the outlines of some of the broader issues that affected the result. The paper has three sections. The first deals broadly with the question of what the standard should include; the second is concerned with the structure and tools of description; and the third traces the development of three technical issues.

The evolution of APL

This paper is a discussion of the evolution of the APL language, and it treats implementations and applications only to the extent that they appear to have exercised a major influence on that evolution. Other sources of historical information are cited in References 1-3; in particular, The Design of APL [1] provides supplementary detail on the reasons behind many of the design decisions made in the development of the language. Readers requiring background on the current definition of the language should consult APL Language [4]. Although we have attempted to confirm our recollections by reference to written documents and to the memories of our colleagues, this remains a personal view which the reader should perhaps supplement by consulting the references provided. In particular, much information about individual contributions will be found in the Appendix to The Design of APL [1], and in the Acknowledgements in A Programming Language [10] and in APL\360 Users Manual [23]. Because Reference 23 may no longer be readily available, the acknowledgements from it are reprinted in Appendix A.

Some implications of shared variables

Recognition of shared variables as the fundamental means of communication between concurrently operating processes has important implications for the design of systems and programming languages. As a consequence, current APL systems, such as APLSV, embody two shared variable facilities: one for establishing temporary interfaces between system components, and the other one for defining parts of the permanent interface between an APL program and the underlying processor. These are treated in depth in this paper. More general implications for language and system design, system programming, and system performance are briefly noted. It is observed, for example, that languages that attempt to communicate with the environment without the explicit use of shared variables do not have a true communication facility, and therefore tend to absorb more and more of the environment within their own formal structure.

Semicolon-bracket notation: A hidden resource in APL

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 IBM family of APL systems

The developmental history of IBM subfamilies of APL systems is traced in this paper, focusing on the inter-relationships among them and the methods of implementation used by the various groups involved. The language itself, and the way its evolution was managed, are also considered as factors influencing the development process. A chart is included that illustrates the evolution of mainframe and small machine programming products supporting APL, beginning in 1964 up to the present time.

A pictorial format function for patterning decorated numeric displays

An extension to the APL dyadic format function is proposed, using a character vector left argument. This argument is a literal pattern having the exact length of the last dimension of the resultant array. No special markers are required to separate adjacent numeric fields, arbitrary decorations may appear within or outside of fields, negative or positive numbers can be distinguished by symbols of choice, and there is provision for accommodating the number representation practices of different countries. The extension completely covers the present functional capability of dyadic format with one minor exception (and possible improvement) in a detail of exponential presentation. In the proposed extension, format information is carried in three ways: in the structure of the pattern, in the choice of digits to denote number fields, and in a system variable. Common requirements, such as the use of commas, floating negative signs on either or both sides of a number, and optional suppression of zero values, are achieved very simply. This paper will describe the evolution of this proposal, which was first discussed at APL/73, give a rigorous formulation of the rules, and show examples of its use.

APL 75 and APL 76: an overview of the proceedings of the Pisa and Ottawa congresses

A continuous flow centrifuge system having a disposable fluid container of constant cross-section mounted in a circular channel. The channel, defining a separation region, has a constant height and side walls of divering spirals to increase the cross-sectional area from inlet to outlet. The container expands dynamically to conform to the claimed geometry and the collection chamber is attached to the container to obtain the separated fluid fractions. The channel may be in an insert, defined between the walls of the insert and the rotor bowl or in a rotor head assembly.