Doc/A Source Book in APL

From J Wiki
Jump to: navigation, search

A Source Book in APL

Papers by Adin D. Falkoff and Kenneth E. Iverson, with an introduction by Eugene E. McDonnell, APL Press, 1981.


1. Formalism in Programming Languages, by K.E. Iverson, 1964. link

2. Conventions Governing Order of Evaluation, by K.E. Iverson, 1966. (From K.E. Iverson, Elementary Functions: An Algorithmic Treatment, Science Research Associates, 1966.) link

3. Algebra as a Language, by K.E. Iverson, 1972. (From K.E. Iverson, Algebra: An Algorithmic Treatment, Addison-Wesley, 1972, Appendix A.) link

4. The Design of APL, by A.D. Falkoff and K.E. Iverson, 1973-07. link

5. The Evolution of APL, by A.D. Falkoff and K.E. Iverson, 1978-08. link

6. Programming Style in APL, by K.E. Iverson, 1978-09-18. link

7. Notation as a Tool of Thought, by K.E. Iverson, 1980-08. link

8. The Inductive Method of Introducing APL, by K.E. Iverson, 1980-10-06. link


The purpose of this book is to provide background material for teachers and students of APL. In a course on APL the focus is necessarily on the details of the language and its use; it may not always be apparent what the purpose of a particular rule might be, nor how one piece of the language relates to the whole. This book is a collection of articles that deal with the more fundamental issues of the language. They appeared in widely scattered sources, over a period of many years, and are not always easy to find. They are arranged in the order of their appearances, so it is possible to get a sense of the development of the language from reading the articles in sequence.

The first article, Formalism in Programming Languages, appeared before there was an implementation. The reader who knows only contemporary APL will have to master some differences in notation in order to understand it. The effort will be repaid, however, because it condenses in a very small space some information which appears nowhere else. In the discussion following the paper, R.A. Brooker asks a key question, one which has followed APL through its development:

Why do you insist on using a notation which is a nightmare for typist and compositor and impossible to implement with punching and print equipment currently available? What proposals have you got for overcoming this difficulty?

The question had no good answer at the time. The best that had been proposed involved transliteration rules that would have made it very difficult to work with the language. It was not until the advent of IBM's Selectric typewriter, with its replaceable printing element, that it became possible to think of developing a special APL printing element. Jean Sammet dismissed the paper in her review of it two years later by writing, "as soon as [the author] starts to defend the work on the grounds that it is currently practical, he is on very weak grounds." By the time the review appeared, however, the very impractical notation had found its implementers, and I read the review as I was sitting at a terminal connected to a 7090 system which was the time-sharing host for something called IVSYS, the immediate precursor of what would be called APL.

The second paper is connected with the transition from a pure notation to an implemented programming language. When it was written, although implementations had begun to appear, and the APL printing element had been developed, it was still not clear what was the best way to publish the language. In the book, as you can see from the selection, use was still made of boldface and italic type styles, rather than the single font imposed by the printing element. In the answer book, however, functions were displayed in both the old style and the new, so that the user could easily see how to translate between the two.

In the third selection, Algebra as a Language, the case is made for the superiority of APL notation over those of conventional arithmetic and algebra. It also gives a discussion of the analogies between teaching a mathematical notation and teaching a natural language, a note that will be heard again in the last selection. The paper makes clear that there is a larger purpose to APL than merely to give people something in which to program. What is intended is a thorough reform of the way mathematics is taught, given the existence of the computer.

The next two papers form a pair and can be discussed together. In the first, The Design of APL, Falkoff and Iverson give the reasons for many of the design decisions that went into APL. The occasion for the second paper, The Evolution of APL, was a conference on the history of programming languages. The criteria for a language to be represented at this conference was that it 1) was created and in use by 1967; 2) that it still be in use by 1977; 3) that it had considerably influenced the field of computing. In the introduction to the proceedings, APL was described as follows:

This language has received widespread use in the past few years, increasing from a few highly specialized mathematical uses to many people using it for quite different applications, including those in business. Its unique character set, frequent emphasis on cryptic "one-liner" programs, and its effective initial implementation as an interactive system make it important. In addition, the uniqueness of its overall approach and philosophy makes it significant.

The quotation properly notes the success of APL in commercial areas, and also gives appropriate credit to the effectiveness of the initial implementation. One has to have lived through the trauma of early time-sharing systems to be able to appreciate how good this early APL really was. I could tell dozens of stories about how bad most early time-sharing systems were, and for each of the bad ones, I could tell a dozen stories about the good qualities of this first APL.

The last three papers have in common that they use the direct definition form of function definition. It is a bit early yet to say now important this concept will be, but there is beginning to be some evidence to suggest that it will have applicability in many areas of programming. At first glance, it might appear that its use would be restricted to simple mathematical functions, and might not, perhaps, be employed in large-scale programming activities. However, I have seen reasonably large report generators— involving several dozen functions—built using this form, and have seen other systems in which two or three hundred of these functions interact.

As APL enters its third decade, it promises to find a significantly larger number of users. Those who truly wish to master it should know more than just the meanings of its primitive function symbols. This book is meant to help them!

A note on the origins of "APL"

I remember quite well the day I first heard the name APL. It was the summer of 1966 and I was working in the IBM Mohansic Laboratory, a small building in Yorktown Heights, NY. The project I was working on was IBM's first effort at developing a commercial time-sharing system, one which was called TSS. The system was showing signs of becoming incomprehensible as more and more bells and whistles were added to it. As an experiment in documentation, I had hired three summer students and given them the job of transforming "development workbook" type of documentation we had for certain parts of the system into something more formal, namely Iverson notation, which the three students had learned while taking a course given by Ken Iverson at Fox Lane High School in Mount Kisco, NY. One of the students was Eric Iverson, Ken's son.

As I walked by the office the three students shared, I could hear sounds of an argument going on. I poked my head in the door, and Eric asked me, "Isn't it true that everyone knows the notation we're using is called APL?” I was sorry to have to disappoint him by confessing that I had never heard it called that. Where had he got the idea it was well known? And who had decided to call it that? In fact, why did it have to be called anything? Quite a while later I heard how it was named. When the implementation effort started in June of 1966, the documentation effort started, too. I suppose when they had to write about "it", Falkoff and Iverson realized that they would have to give "it" a name. There were probably many suggestions made at the time, but I have heard of only two. A group in SRA in Chicago which was developing instructional materials using the notation was in favor of the name "Mathlab". This did not catch on. Another suggestion was to call it "Iverson's Better Math" and then let people coin the appropriate acronym. This was deemed facetious.

Then one day Adin Falkoff walked into Ken's office and wrote "A Programming Language" on the board, and underneath it the acronym "APL". Thus it was born. It was just a week or so after this that Eric Iverson asked me his question, at a time when the name hadn't yet found its way the thirteen miles up the Taconic Parkway from IBM Research to IBM Mohansic.

There was a period of time, however, when the name was in danger of having to be changed. IBM had just gotten over the experience of having to withdraw the name NPL which it had given to its "New Programming Language", because of a conflict with the use of the same initials by Britain's National Physics Laboratory. The conflict involving APL arose when a paper appeared in the 1966 AFIPS Fall Joint Computer Conference Proceedings. It was by George Dodd, of General Motors Research, and was entitled APL—a language for associative data handling in PL/I. (PL/I was the name now given to the former NPL.) In a review of the paper that appeared in Computing Reviews 8, for September-October 1967 (review 12,753), Saul Rosen wrote:

This reviewer has one suggestion that is offered quite seriously, though some readers might consider it frivolous. There already exists at least one language that is reasonably well known by its acronym APL. I refer to the language developed by Iverson for which translators and interpreters have been written on a number of computers. It would be helpful if the authors of the present article could make some minor change in the name of their processor to remove this very global ambiguity.

George Dodd replied in a letter to the editor that appeared in CACM 11, for May 1968, p. 378:

I would like to offer a rebuttal to the last paragraph of the otherwise excellent and accurate review of APL—a language for associative data handling in PL/I ... In the review it is pointed out that there already exists one other language known by the acronym APL; that being the language developed by Kenneth Iverson of IBM. The reviewer concludes that the name of our processor should be changed to avoid a conflict of names.
Before naming the language we conducted a thorough search of Computing Reviews, AFIPS Reviews, and other sources, and at that time (spring, 1966) ascertained that the APL acronym was unique. Unfortunately, Iverson's language, which is an internal IBM development project and not an announced product, has also come to be known by the same name. We feel our public reference to APL preceded Iverson's and that a more reasonable request from the reviewer would be that the name of the Iverson APL be changed.

There was a short but fairly intense skirmish inside IBM following the George Dodd letter. I don't know all the details, but I believe the IBM branch office which handled the General Motors account was supporting George Dodd, and the case for IBM's right to use the initials was being made by Al Rose. I don't know what became of George Dodd's processor. The issue wasn't resolved until late in 1968, and was one of the things preventing the release of APL as a product. Rose eventually won the day by making the case Iverson had established his stake in the initials when his book A Programming Language was published in 1962, long before Dodd's use of the letters in 1966. The story goes that, at the final meeting to decide whether to release APL, the account representative said, "The Detroit branch office nonconcurs—" at which point the vice president sitting in judgment replied, "That settles it! Branch offices don't nonconcur." And so IBM retained the use of the letters.

Curiously, in view of the National Physics Laboratory's objection to the programming language named NPL, the Applied Physics Laboratory of Johns Hopkins University never made an issue, as far as I am aware, of IBM's joint use with them of the initials APL.

There is at least one other claimant to the initials. When the IBM Philadelphia Scientific Center closed in 1974, many of the APL people there moved across the continent to the San Francisco area, to work at an IBM language development location in Palo Alto. While this was going on, one of those moving picked up a copy of the San Francisco Chronicle which had the headline, "APL LEAVES SAN FRANCISCO". Since he had just pulled up stakes in the Philadelphia area, he was startled to see that the same thing was about to happen again in San Francisco. On closer inspection, however, it developed that the story concerned the departure of the facilities of the steamship company, American President Lines, from the docks of San Francisco to the docks across the bay in Oakland.

Eugene E. McDonnell
September 1981
Palo Alto

See also