APL(ID:5466/apl007)Automatic Programming Languagefor Automatic Programming Language US Army project to develop compiler compilers etc U.S. Army Signal R&D Lab, Fort Monmouth, NJ 1959 Related languages
References: Thus far we have attempted to describe what we are talking about when we say "Automatic Programming Language (APL)." It should be obvious that a great deal of effort must be expended in order to produce such an aid to the programmer. Before going into the Signal Corps efforts in this area, we will take a minute and give a capsule version of one philosophy for development of automatic programming aids and one example of how an automatic programming capability is being developed by a very large computer manufacturer. Later we will contrast this approach to that of the Signal Corps. This company had determined through experience that the work on programming aids is best handled by a centrally located group. However, they feel that the equipment for which they are presently preparing automatic programming aids falls into several natural groupings, and that the highest efficiency can be obtained by having a small group of people produce the necessary programs for each group of machines. These working groups are apt to overlap or start off on tangents if they are allowed to work too independently, therefore the company has set up a programming systems group which coordinates and directs the individual efforts toward a final system. Each group then starts from machine instructions, develops an assembly routine which is usually a one-to-one symbolic programming system, proceeds to an extended assembly routine which handles some of the housekeeping details in addition to the assembly work, and eventually develops machine associated macro-instruction generators. These generators are specialized subroutines to perform certain specific recurring jobs such as finding the square root, sine, or cosine, etc. Machine independent macro-instruction generators are also possible since many machines can perform jobs such assort, merge, or extract in the same general way. These machine independent macro-instructions generators tend to be produced by the programming systems group since they pertain to several of the machine groups. The systems group then provides an automatic computational program ruing language and an automatic business-type program ruing language which it has been working on and toward which it has directed the efforts of the machine associated groups. To give a better idea of the over-all picture, the organization is shown in figure 1. It should be noted that even the highest level languages are usable only if you have one of the specified machines. The amount of effort needed to produce these program ruing aids is quite large, greater in fact than the effort re- programming scheme required to completely hand code a business type of problem. One might ask why go to all this work when with the same amount of effort you could write several programs in standard machine instructions. This may well be true for some of the programs which are needed right now however, the objective is to spend some effort now to saw many times that amount of effort in the future. For example, the DA/CONARC ADPS study group~ are now in the process of making detailed analyses of any where from 54 to 106 different areas of prospective field applications of Automatic Data Processing equipment. A CONARC officer has estimated that this number may b~ extended into the thousands within the next 1.0-20 years These studies are similar in many respects to commercial ADP problem areas, except that they are more extensive( and varied than any commercial group has come to[ against thus far. However, the basic similarity of problems indicates that an approach similar to that of the large( computer manufacturer just covered, but avoiding some of the pitfalls and dead ends which he encountered, will produce an Automatic Programming System to meet, the, Army's needs. Sometime in the next several years the, USAEPG at Ft. Huachuca will have to provide running programs for a number of these applications. Most of you are undoubtedly aware of the shortage of experience programmers, and for the Army to gather together the necessary hundreds of programmers required to write these programs in machine language would be almost impossible. Not only that, but the coordination of this large a group of programmers as well as the testing of the (.completed programs would be a gigantic undertaking. Since debugging can be done at the APL level, the time and effort required in this area is greatly reduced. In addition, with the computer doing the long tedious job of coding the program into machine language, the writing of the programs will be greatly simplified. Secondly, even if the Army could get enough programmers and enough time to write all the programs in machine language, for which computer should they be written? [n order to check out the programs, they should be written for a machine which is available today, but in order to be of use to the Field Army, they will have to run on the i MOBIDIC and in later years on any successor to MOBIDIC. Difficulty is even encountered in writing programs for a seemingly stable application such as the USA Signal Supply Agency in Philadelphia. Although this Agency presently has an IBM-705, it may be desirable in the future to change to an IBM-7XX, a Remington Rand UNIVAC XXVI, a Philco TRXNSAC 4000 or some other as yet undesigned future machine. Moreover, if a hot war were to develop, it might be desirable to move the Signal Supply Agency from Philadelphia to the mountains where a tactical machine such as the Moraine could take over the job in a short time. Any of these changes would at present require many man-years of reprogramming involving hand translation of existing programs. If the programs for the Supply Agency were written once in the Military APL under development they could be translated in a very short time for use on any computer desired. Extract: R & D programming effort R & D programming effort Finally, if (or I should say when) it is desired to make minor changes in the running programs because of a change in proeeedure or the cancellation of an existing report, the ease with which the subject program can be retranslated into an optimized object program makes it possible to start from scratch each time and produce the best possible running program, even after many such changes have been made. Under present methods, and this is actually the situation at a large computer installation today, so many changes have been made to the original program by exiting to the new portion and then returning to the exit point, that a large amount of the available storage area is used up creating a patch work quilt of useless unconditional transfers. The patched-up program becomes so complex that no one could possibly trace through it to find an error if one should occur. Although this is not an exhaustive list of the advantages of using the Automatic Programming Language for all Army programs, we hope it points out the immediate need for such a language. The Signal Corps R & D efforts are centered mainly in two areas, with a major side interest in the area of information storage and retrieval. This is shown in figure 2. The first of these two areas could be called the machine associated area. This corresponds roughly to the lower portion of the chart of the commercial approach. Under the guidance of personnel in the second area, which could be eMled the machine independent area. the machine associated group will provide the necessary arithmetic, tape supervision, housekeeping, program diagnostic and format control subroutines, along with a simple one-to-one symbolic assembly routine. The U. S. Army Signal Research and Development Laboratory is preparing program diagnostic and other routines such as simulation of MOBIDIC on the REPAC computer as internal efforts, however, the greatest amount of effort is being supplied by Sylvania Electric Products, Inc., operating under contract DA-039-sc-78111 for the development of MOBIDIC and other similar machine associated programming aids. Other field computer developers such as Philco, which is constructing the BASICPAC computer, will also contribute to this effort as part of their equipment development activities, but. necessarily to a lesser degree. Complementing the activities of the machine dependent group will be the less conventional activities of the machine independent group which aims at a major advance in programming techniques. Among the chief investigators involved in this effort are Professor A. J. Perlis of Carnegie Institute of Technology, Professor Saul Gorn of University of Pennsylvania and Messrs. A. Holt and W. Turanski of Remington Rand. This group is specifying common standards definitions and systems of notation for use in both their own future work and that of the machine associated group. It will assist in the specification of the work to be done by the machine dependent group in order to assure maximum compatibility and cross-usefulness of the two efforts. However, its main activity is to develop the basic techniques needed to implement the Automatic Programming Language (APL). In conjunction with this it will prepare a "Compiler to write Compilers" and representative limited compilers prepared by this technique to demonstrate the feasibility and effectiveness of approach. It will also provide detailed guidance in the last project of the machine associated group, that of writing a limited compiling routine. This compiling routine will accept a problem stated in a more-or-less "universal computer code," and, utilizing all the other subroutines already available, produce an efficient object program for a specific machine or class of machines. In order to make the APL most convenient to the largest number of users, tile language itself will consist of many subsets which might be called "technical jargons" in the same sense that chemists or plumbers or artists use a "technical jargon" which is merely a subset of the English language. The Automatic Programming System itself will provide an automatic method of translating from any "technical jargon" to some "universal" language in which all problems can be expressed and which any computer can understand when provided with a limited compiler routine as mentioned earlier. Unlike the commercial set-up, the input to this compiling routine will not necessarily be in a form which is designed exclusively for Maximum convenience of human programmers. The primary source of programs at this stage of translation will not be humans, but rather will be the Automatic Programming System itself and they can therefore be written in a machine convenient form. Getting back to the work of the machine independent group, it is anticipated that in order to make the APL completely versatile and expandable a large number of these so-called "technical jargons" will be required, and it must be possible to introduce and modify additional jargons in the future without disturbing the language or the translating system. In other words the APL must be capable of orderly growth and development as conditions and requirements change. In order to make this possible, tile machine independent group will not attempt to specify a closed vocabulary and then write a super-compiler to translate statements written with this vocabulary into the "universal machine code." What this group will do is to establish a set of guide lines, formats and procedures. These will be accompanied by the necessary running programs to enable the following to take place: A small select group can be assembled for a short period of time. This group would be made of people who are intimately familiar with a specific area for which a "technical jargon" as described earlier is desired. These people will be assisted by an ADPS consultant who is familiar with the Army Automatic Programming Language. This group then receives several hours indoctrination on the APL and then proceeds to formulate the special vocabulary which is best, suited to the needs of their special field. Then, using the programs provided, they will go to a computer and produce a "special purpose compiler" which will translate programs written in their "technical jargon" into the "universal" language mentioned earlier. Very happily, tile DA/CONARC ADPS Study groups in many areas constitute this small select group of experts which will be needed to specify these "technical jargons" and the Signal Corps will be able to provide the ADPS consultant to complete tile team. The sum total of all these special purpose languages, with their special compiling routines (which were written by a compiling routine itself), then go to make up the Army Automatic Programming System. Since all problem solving programs will be reduced to the same "universal" language, by retaining this intermediate translation it will be possible in an extremely short. time to produce an object program for not, only your own machine, if your running programs are destroyed, but for any other computer which might be available should your computer itself be destroyed. Not only this, but since the entire translation is done by special purpose compilers (one for your problem area, followed by one for your machine), changes can be made in the original statement of the problem which can then be quickly and cheaply recompiled into an object program that has the same degree of efficiency as the original program and is not all chopped up by useless unconditional transfers. Lastly, since we have in effect a compiler which writes compilers, new "jargons" or technical languages can be added to take care of future applications areas not even thought of at this time with an absolute minimum of effort and necessarily only a small fraction of the 50-100 man-years required today to produce an efificient computational business type compiler for one of the many large scale computers being produced by the industry. In conclusion, let me emphasize that we are not attempting to produce a super-compiler which will handle an extremely large vocabulary put together in almost any kind of a sentence, this type of system would be only an incremental advance over systems available today and in addition would have serious limitations such as its use by technical specialists outside the programming field, being good for only certain linfited classes of machines at best, and possible obsolescence in the near future as new areas open up for the application of large scale digital computers. What we are providing is a fast, cheap and efficient means of producing specialized compilers to handle special, easy-to-learn technical vocabularies with a strong common language basis. These compilers will translate programs written in the language used into an object program for any computer desired. Extract: Introduction A well-designed general purpose digital computer is potentially capable of solving a wide variety of problems. However, before it can actually solve any particular problem it, must be provided with a set of instructions, known as a program, which tells the computer a procedure to follow in order to solve the problem. Until it is provided with an appropriate program, the computer can do no useful work. A key element in the design of a computer is the assurance that it can be simply and effectively instructed or programmed to perform desired tasks. Unfortunately, human beings and computers do not naturally use the same kind of language. A human being who analyzes a problem would prefer to use his native language, or more accurately, a version of his language somewhat formalized and restricted in vocabulary to assure clarity and conciseness. He prefers to describe the solution of a problem in terms of the broad generalizations on which he thinks, rather than to break down every operation of the solution process into its finest detail. The computer, on the other hand, prefers to receive its instructions in a "language" of binary bits. These bits form instructions which describe, in very precise detail, a large number of simple basic steps which should be performed in order to solve the problem. Unless special provisions are made to help the human being instruct the computer, in preparing the program he must perform a long, detailed manual operation called coding. In coding, the human being does the essentially clerical task of breaking down the various operations which must be performed into fantastically large numbers of individual, finely detailed, rigidly formalized instructions for the computer. The amounts of time and effort involved in this process frequently become unbelievably large. This places a serious limitation upon the applicability of computers to many tasks because of the labor costs and delays involved, not to mention the fact that persons trained for this task may not be available, particularly under field army conditions. It has been the experience of most computer users that the cost of providing a large scale computer with the instructions it needs to perform a specific task (for example, stock control in a depot) is typically greater than the cost of the computer itself. The obvious solution to the difficulty of computer programming is to build computers which will accept instructions in the form that the human being would like to prepare them rather than in the form that present day computers are designed to accept. Unfortunately, this is not simple. Providing special hardware for accomplishing this task would be so expensive that no computer manufacturer would dare to consider doing it. How then can the difficulty be solved? A plan of attack is suggested by noting that the coding process is essentially a clerical operation and that computers (when provided with appropriate programs) are well suited to the automation of clerical processes. Consider a procedure one might use to take advantage of this situation. A special translation program can be written and used on a computer to perform the clerical tasks of translating from instructions convenient to human beings into instructions convenient to the computer. The human being who tells the computer how to solve a particular problem can write the instructions in a form convenient to himself, then use the special translation program in the computer to translate these instructions into a form which the computer can interpret and act upon. Normally the program which performs the translation will also perform miscellaneous functions to relieve the programmer of some of the clerical activities involved in programming, such as the Mlocation of mernory loctions in the computer. DOI in [ACM] CACM 2(02) February 1959 view details in [ACM] CACM 3(07) July 1960 view details Fieldata Programming During this entire period, internal rivalry was growing between the communications and computer people at Fort Monmouth. The communications faction was wedded to teletype and felt that computers were a temporary fad. They thus attempted to redirect any computer I/O funding for use on teletype equipment. While Luebbert managed both computer and communications R&D, he was able to control this to some degree. He did not have an entirely free hand on how the funds should be spent, however, or what programs would receive emphasis. Though he felt that more should be done both with I/O equipment and programming, he was unable to get enough funds for either more I/O development work or for programming. Bill chose to emphasize programming with the limited additional funds he was allowed (Luebbert 1985) a number of programming development; contracts were let to Sylvania for basic software which included an assembler, some mathematical routines, and a set of utility programs. Development of a COBOL compiler was started in 1959 (Sammet 1985; USASRDL undated), but Sylvania did this work on its own without army funding. The Signal Corps also supported work on the systems and programming concepts for the Fieldata family of computers at the Moore School of the University of Pennsylvania. The six task areas involved systems, human factors, data transmission, common languages, new devices, and codes. The common language effort, led by Saul Gorn, focused on the feasibility of standardized coding methods for families of computers (Sammet 1985; Gorn and Parker 1960). As part of this effort, the Automatic Code Translation System (ACT) addressed the problems of writing programs that could be compiled and executed on families of different computers (Holt and Turanski 1960a). A basic tenet of Fieldata was the need for any type of problem to be run on almost any one of the machines. The farsighted nature of the ACT work is best indicated by the statement in their final report (Holt et al. 1960b): "that the overwhelming majority of Army personnel concerned with these problems will not be computer programming experts . . . and that the efficiency of the entire Fieldata system hinges primarily on the speed of problem solution -- i.e., the total "lapsed time" from problem statement till solution delivery." The people who worked primarily on ACT were Anatol W. Holt, William J. Turanski, and E. J. Parker and they envisioned a system of three parts. The first was an allocation interpreter that coordinated a family of small stored subprograms. The second was a library of basic translation functions, and the third was a general translation library with content that varied depending on the application. Various other results of this University of Pennsylvania work were the development of techniques for detailed two-dimensional microflowcharting of machine instructions, significant theoretical work on formal languages by Gorn, exploration of optimizing techniques for information retrieval using list processing, and human factors studies of computer console design. The Signal Corps contract at the Carnegie Institute of Technology was under the leadership of Alan Perlis (Perks 1961). It concentrated on the general area of programming languages and translators and produced, for example, the concept of the threaded list. in Annals of the History of Computing, Spring 1987 view details |