ALGOL 60(ID:1807/alg020)Algorithm LanguageA portable (international) language for scientific (mathematical) computations. ALGOL 60 is small and elegant. It is block-structured, nested, recursive, and free-form. It was also the first language to be described in BNF (Backus-Naur Form). There are three lexical representations: hardware, reference, and publication. The only structured data types are arrays, but they are permitted to have lower bounds and could be dynamic. It also has conditional expressions, it introduced =, if, then, else ; very general "for' loops, switch declaration. Parameters are call-by-name and call-by-value. It has static local "own" variables. It lacks user-defined types, character manipulation and standard I/O. Structures: Related languages
References: in [ACM] CACM 3(05) May 1960 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (2) 1961 Pergamon Press, Oxford view details in The Computer Journal 3(2) July 1960 view details in The Computer Journal 4(3) October 1961 view details in The Computer Journal 4(3) October 1961 view details Introduction The European ALGOL situation is a complicated one, made up of the influence of workers from about 25 institutions in ten countries. A brief account of the work done in all these places must emphasize certain developments and forget about others. However, even if in this way I run the risk of doing injustice to valuable work in one place or another, either from ignorance or because of the point of view I am going to present, I feel justified in attempting the present task because, after all, there is a great underlying unity of purpose in the European ALGOL effort. Differences of opinion that do exist concern the proper means of achieving the goal. About the goal itself there is hardly any disagreement. The plan of presentation of this paper is as follows: First I will try to describe the work done in certain distinguishable groups of centers, covering both historical development and the current emphasis within each group. When I have in this way covered the complete field I will try to single out the underlying basic points of view. This will bring me to my conclusion. Extract: The Central European Group (ALCOR) The Central European Group (ALCOR) The first group, both historically and with respect to the number of centers involved, is the central European one. It evolved around Zurich and Mainz and contains the roots of both ALGOL itself and of the whole idea of an algorithmic language. In fact, Rutishauser of Zurich is sometimes referred to as the "grandfather of automatic programming" in view of his work in this direction from about 1950.(1) Again the suggestion of a cross-Atlantic agreement in this field goes back to this group; of the four European members of the first ALGOL committee three came from these two places, namely Rutishauser from Ziirich and Bauer and Samelson from Mainz. The fourth was Bottenbruch from Darmstadt, a center which also belongs to the central European group.(2) It is, I think, worthwhile to notice that these four all come from universities, carrying a heavy load of mathematics and numerical analysis with them. Also, the machines they had available at the time when this work was begun were of moderate size and were used primarily for teaching and research. The meaning of the central European group cannot be understood, however, unless one knows about the idea of a more local, and far more rigid, collaboration which developed simultaneously with the international ALGOL deliberations. This idea again originated at Mainz and goes as follows: When implementing the common language on different computers it is likely that the details of the language will not be treated exactly alike. Consequently a direct interchange of programs will not work. In order to achieve strict interchangeability it is necessary to make the different translators essentially alike, not only with respect to the language they process, but also in their inner workings. This, then, is the idea of the so-called ALCOR group of computation centers: Within the group all members will make use of the translation algorithm developed in Mainz by Bauer and Samelson(3) and will have the actual matrix, which controls this algorithm, supplied from Mainz. In this manner complete uniformity of translation is assured. The ALCOR group (ALCOR stands for Algol COnverteR) at present consists of the following centers: Institut fur Angewandte Mathematik, Universitat, Mainz. Institut fur Praktische Mathematik, Technische Hochschule, Darmstadt. Zentral-Laboratorium, Siemens und Halske, Miinchen. Institut fur Angewandte Mathematik, Universitat, Bonn. Rechenzentrum der Technischen Hochschule, Munchen. Institut fur Angewandte Mathematik, Eidgenossische Technische Hochschule, Zurich. Institut fur Schwachstromtechnik, Technische Hochschule, Wien. Telefunken GmbH., Backnang. Standard Elektrik Lorenz, Stuttgart-Zuffenhausen. Zuse KG, Bad Hersfeld. Regnecentralen, Copenhagen. Oak Ridge National Laboratory, Oak Ridge, Tennessee. The ALCOR group was established in 1959 with the expectation that working translators would be completed within each of the centers within a year or so. However, the development of ALGOL 60(6) naturally caused some delay in the whole plan and the status of these centers with respect to the completion of actual compilers is as follows: Since the end of 1958 a translator for a subset of ALGOL for the machine Zuse 222 has been running. The subset excludes procedures. May 1961 saw the completion of an extended system conforming to the so-called ALCOR specifications. These include most of ALGOL 60, with the exception of recursive procedures and own. 2. SIEMENS UND HALSKE, MUNCHEN In November 1960 a translator for a modest subset of ALGOL for the Siemens 2002 was completed. The subset excludes procedures, arrays of variable size, and - own. A translator for the complete ALCOR specificstions for the same machine is well underway. 3. TECHNISCHE HOCHSCHULE, MUNCHEN Since February 1959 a translator for a small subset of ALGOL for the machine PERM has been working. By September 1961 a translator for a larger subset was completed. Work on an even more complete system is in progress. 4. ZURICH Since July I959 a translator for a small subset of ALGOL for the machine ERMETH has been working. During 1960 this was extended to include the complete ALCOR subset. This has, as far as I know, been working for some time. The work in Copenhagen will be described below. Oak Ridge falls outside the scope of this report. As to the remaining centers, I regret to say that up-to-date information has not been received. This successful construction of translators within the ALCOR group has nowhere been considered an experiment or a goal in itself, but has been the basic means of communication with the computer. Thus, at Mainz the teaching of the use of the machine and of numerical analysis has for several years been based exclusively on ALGOL. Some 400 people have taken courses in ALGOL, and all programs for the machine are written in this language. In fact, only one or two people in the center know the machine code of the Zuse 222. In this context it is also of interest that the Mainz translator for the Zuse 222 already has been distributed to eight other installations having this machine and that several dozen more are expecting it. As the last field of activity of the central European group, the Taschenbuch project should be mentioned. This project aims at the publication of a four-volume handbook of tested algorithms from the field of numerical analysis. The algorithms will all be written in ALGOL. In compiling this collection the collaboration of outstanding workers from all over the world has been sought. Also, it is intended that only algorithms which have been run successfully on at least two different computers will be included. Thus, hopefully, the handbook will present an all-round collection of algorithms which are sound both theoretically and practically. Summarizing, we see that the central European group has been busy in a wide field of practical implementation and use of ALGOL. Their translators have initially been modest; often quite heavy restrictions of the language have been tolerated. In this way the actual work of constructing the translators has often been kept very low. In fact, figures - the range from 1/6 to $5 man years are quoted. These figures of course do not include the general advisors of the group. At the same time the group has been very active in the international work of defining the language and is unquestionably responsible for a great deal of the basic characteristics of the language. Extract: The Dutch Group The Dutch Group All other European groups came into the ALGOL work when this was already well underway in central Europe. These groups include a Dutch group, a Scandinavian group, and some additional computation centers which do not fit into any grouping. Speaking of a Dutch group is perhaps going too far, since this would consist only of two centers: the Mathematical Center in Amsterdam and the Dr. Neher Laboratory of the Dutch Postal and Telecommunications Services in Leidschendam. These two centers, although keeping in close touch with each other's developments, do not have any formal arrangements between them. Even so, there is so great a similarity in the background and approach of these centers that it is convenient to pool them. Whereas the central European group is dominated by people with a background of applied mathematics and numerical analysis, the Dutch group takes its direction from people who have a taste for logic and formal analysis and who, in addition, have been directly concerned with the design of machines. Thus, van der Poel, at Leidschendam, is known for his analysis of the simplest possible computers and his contributions to the design of the ZEBRA, while the Mathematical Center at Amsterdam has been the cradle of both the ARMAC and the Electrologica X1. These characteristics have left their mark both on ALGOL 60 and on the translators designed by the groups. Both groups were very active in the work leading up to ALGOL 60, and van Wijngaarden from Amsterdam sat on the final thirteen-man committee.(6) In this work the Dutch would urge generality and removal of arbitrary restrictions in the language and also contributed several original features to the language. In the field of translator construction the group at Amsterdam has been singularly successful. In keeping with their general outlook they have strived to produce a translator which conforms absolutely with the official definition of the ALGOL 60 language, with as few restrictions as possible. This has brought about a new attitude towards the problem of processor constructions, the primary focus being the running program, while the actual translation process, the transformation of the input string, becomes a relatively minor matter.(4, 5) A system designed along these lines was constructed at Amsterdam by two people, Dijkstra and Zonneveld, and was first tested in June 1960, i.e., about 5 months after the language was defined. This is not only the first successful system that will handle the full generality of ALGOL 60 procedures, but probably remains the only one which will handle recursive procedures. The only restriction is dynamic arrays. At the Dr. Neher Laboratory an ALGOL system which goes to even higher degrees of conforming to the letter of the ALGOL 60-report is underway. To most people who have worked with implementation of ALGOL 60, the idea of a system that handles the complete language is likely to provoke the question: What about the efficiency? This is indeed one of the most freq;ent objections raised against ALGOL 60. It is too general, and therefore-inefficient and difficult to implement, people will say. In view of this reaction it is interesting to analyze the attitude and practical experience of the Amsterdam group. First, on the question of attitude, I want to cite some reflections made by Dijkstra(4). Dijkstra says that the approach taken will clearly cause some slowing down of the running program. However, as a scientific institution, the Mathematical center in Amsterdam prefers to work on a programming technique that will gain in importance in the immediate future. And there are good reasons to believe that the trend of machine design will be such that a proportionally greater number of machines will come into existence for which the cost of a very general approach is not excessive. As a second point Dijkstra considers that the increased flexibility and the removal of arbitrary restraints to be taken into account in will be found more and more valuable as time goes on. Indeed, for the utilization of the rapidly increasing machine capacity these points may well turn out to be decisive. On the practical side it should perhaps be said first of all that the computer at the Mathematical Center in Amsterdam, the Electrologica X1, happens to be rather well suited to the general approach taken. Even so, it is significant that the ALGOL system does not remain an academic exercise. On the contrary, the use of it has been taught to a great number of people and it is being used extensively for solving a wide class of practical problems. Extract: The Scandinavian Group The Scandinavian Group The Scandinavian group consists of three centers in Sweden, namely Matematikmaskinnamnden in Stockholm, FACIT in Gothenburg, and Svenska Aeroplan Aktiebolaget in Linkoping, and one center in Denmark, namely Regnecentralen in Copenhagen. The latter is my own institution. Of these institutions one is a machine manufacturer and service center, one is a user, while the remaining two are combined service centers, machine designing and building groups, and research institutions. It may seem strange that these rather different backgrounds should provide an incentive to close collaboration, and probably the close contact between our groups is due mainly to a general positive wish to share our results with any interested group. In 1954 the group at Stockholm very generously put the design of their machine BESK at the disposal of all of us. Like the Dutch group we came into the work only after the preliminary specifications of ALGOL had been settled, but early enough to become quite heavily engaged in the work of establishing ALGOL 60. Throughout this work our attitude has been that we would be willing to accept any feature in the language on which it would be possible to agree. In fact, we have felt that the language would in any case, be so much better than anything we could think up ourselves, and since we needed a language at the time ALGOL was first announced, we accepted it with glee. The fact that in addition ALGOL seemed to have a fair chance of becoming a widely adopted standard, of course, added to our satisfaction. With this attitude I believe it is only natural that we should want to help further the development in whatever area we could be most useful, and our work in trying to organize and facilitate free discussion and the interchange of ideas is one fairly obvious response to this desire. This work was started in March 1959 and was initially planned to cover only the communication within the ALCOR group. However, by June of the same year we had already agreed to act as a general clearing house for communications from any interested person in Europe. As some of you know, we have carried out this assignment through the medium of a series of duplicated notes known as the ALGOL Bulletin. These are circulated free of charge to anyone who is interested in getting them. The material in the Bulletin consists entirely of the contributions from the readers. So far, in fact, no material submitted has been rejected. At the same time a considerable amount of work on implementation has been going on, although so far with rather less success than in central Europe or in Holland. In fact, the first Scandinavian translators in Copenhagen and Gothenburg have only just started running. The one in Copenhagen has a power about equal to that of the ALCOR specifications, i.e., it will not handle recursive procedures or own arrays(7). The one in Gothenburg is somewhat more limited. Extract: Independent Centers Independent Centers Of projects falling outside the three groups I have described so far, I would like to mention developments at Zeiss, Jena, Germany, where they are working on a translator for the Zeiss-Rechen-Automat ZRA 1, and at English Electric, Kidsgrove, England, where a translator for a new machine, the KDF 9, is being developed. At this point I would also like to make clear that since this report covers only Europe the developments in Japan and Asian Soviet Union are not touched. Extract: General Trends General Trends Having now described the European ALGOL situation in a geographical and historical manner I would finally like to try to find some of the underlying trends and points of view. I think it is right to say, first of all, that throughout Europe ALGOL has been taken very seriously. People have put a great deal of thought, work, and faith into the whole idea. However, underneath this common general faith we can discern at least two different attitudes. These can perhaps be expressed as follows: in the one view ALGOL is seen as the final expression of existing trends and needs within the fields of numerical analysis and machine design. Where ALGOL goes further than these it is regarded with suspicion or rejected altogether. In particular, where ALGOL forces an inconvenient use of present machines it is restricted in the actual implementations. In the other view ALGOL is seen as an independent construction in its own right. Where it provides new mechanisnk for which no immediate use is apparent, this is understood as just a temporary state of affairs, the conviction being that these features will turn out to be important as soon as the learn to use them. Again, if ALGOL forces an inconvenient use of present machines, this is thought to be the fault of the machines. Indeed, it is felt that future machine design will be heavily influenced by ALGOL. If you ask for my opinion on these two attitudes, I must say that I think that they are both right and useful. Unquestionably there is a big job to be done in working out the best algorithms of numerical analysis in a common language like ALGOL, and for this purpose people probably can do without the most general features of the language, at least to start with. At the same time I feel that there is an urgent need for radically new impulses in the logical design of machines. Throughout the past decade machines have been designed according to roughly the same principles--or lack of principles. The machine coding aspect has always been in the foreground in spite of the fact that the inconveniences of present-day machine code are obvious and widely recognized. Previous languages, such as FORTRAN, have not brought about a change here, basically because these languages have themselves been designed with the computer in mind. Thus, they have only tended to perpetuate the present machine designs. This is of course fine, if one feels that it is right to spend, first, a great effort in building a machine which in a sense no one will use, and then another great effort in writing a system of 20,000 or 50,000 instructions necessaryto work with the thing. I feel that there is something utterly wrong here, and I am gratified to see that apparently the only incentive to changing this situation is corning from the ALGOL effort. Extract: Conclusion Conclusion In conclusion I think it is fair to say that within a significant part of the European computation centers the ALGOL effort has had a profound effect. It has inspired wide interest in the fields of computer languages and translation. It has furthered the contact between these computation centers. It has convinced a great many people that a common language is both desirable and possible. It has inspired new thought on the machine design problem. Finally, it has led to the completion, in many places, of processors of a high degree of generality and usefulness. in Proceedings of the 1961 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (2) 1961 Pergamon Press, Oxford view details The remaining papers in the Scientific section are "Interference with an ALGOL procedure," by H. Rutishauser, "MADCAP II" by D. H. Bradford and M. B. Wells, and "The ELLIOTT 803 Autocode, Mark II," by J. Pym and G. K. Findlay: the first of these describes a method of including monitoring in an ALGOL procedure while the other two are essentially programming manuals for the respective languages. The paper on MADCAP (the compiler for MANIAC II at Los Alamos) reveals some interesting features, notably the ability to include constants without generating any actual program, by statements like "C is 49-186," or "I is 18," the recognition of the customary notation for powers of a function (e.g. cos2 x), and the various elements of "tidying up" which are introduced into the compiled program. in The Computer Bulletin June 1962 view details The properties of data It is, of course. the available properties of the data which to a large extent determine the power of an automatic programming system, and distinguish commercial from mathematical languages. Consider the function of moving data within the internal store. In a mathematical language the problem is trivial because the unit which may be moved is very restricted, often to the contents of a single machine word. But in a commercial language this limitation is not acceptable. There, data units will occur in a variety of shapes and sizes. for example: i) Fixed Length Units (i.e. those which on each occurrence will always be of the same length) may vary widely in size and will tend not to fit comfortably into a given number of words or other physical unit of the machine. Generally the move will be performed by a simple loop. but there are some awkward points such as what to fill in the destination if the source is the smaller in size; ii) Static Variable Length Units (i.e. those whose length may vary when they are individually created but will not change subsequently) are more difficult to handle. Essentially the loop will have two controlling variables whose value will be determined at the moment of execution. There are again awkward points such as the detection of overflow in the destination (and deciding what to do when it occurs, since this will only be discovered at run time); iii) Dynamically Variable Length Units (i.e. those which expand and contract to fit the data placed in them) are even more difficult. They have all the problems of (ii), together with the need to find and allot space when they expand. It is clear, therefore, that a simple MOVE is less innocuous than it might seem at first. Actually the above remarks assumed that it was not possible to move data between different classes of units. The absence of this restriction, and the performance of editing functions during the process, can make the whole thing very complicated for the compiler indeed. The properties of data will have a similar influence on most of the other operators or verbs in the language. This has particular significance when the desired attribute is contrary to that pertaining on the actual machine. Thus arithmetic on decimal numbers having a fractional part is thoroughly unpleasant on fixed-word binary machines. Nevertheless, despite these difficulties considerable progress has been made toward giving the user the kind of data properties he requires. Unfortunately this progress has not been matched by an improvement in machine design so that few, if any, of the languages have achieved all of the following. (a) The arbitrary grouping of different classes of unit, allowing their occurrence to be optional or for the repetition in variable-length lists. (b) The input and output of arbitrary types of records, or other conglomerations of data units. having flexible formats. editing conventions and representations (c) The manipulation of individual characters, with the number and position of the characters being determined at run time. (d) The dynamic renaming or grouping of data units. Yet users do need these facilities. It is not always acknowledged that getting the main files on to the computer, before any processing is done, may constitute the largest single operation in many applications. Furthermore. these files will have a separate independent existence apart from the several programs which refer to them. Progress has also been made in declaring the data properties in such a way as to imply a number of necessary procedures to the compiler. For example, if one declares both the layout of some record to be printed, and the printed record, the compiler may deduce the necessary conversion and editing processes. It is here, in the area of input and output, that some languages have approached the aim of being problem-orientated. Extract: ALGOL ALGOL Finally, in this section some mention might be made of the work done towards extending ALGOL for commercial purposes. Nobody now seems very interested in this effort, but for myself, and I had some hand in it, I still believe it could be valid and hope it will soon be published. ALGOL is a really elegant tool for programming, or would be if those responsible for it would stop squabbling long enough to complete it. There is no reason why the language should not be extended to provide a unified system for both business and mathematical purposes. The difficulty of notation for business users could be removed quite trivially, by including an alternative "English" word form. Furthermore, ALGOL is the only existing language in which the processes of compilation could be described with the precision that is necessary if we are ever going to achieve a real compatibility across different machines. in The Computer Journal 5(2) July 1962 view details The CORC Language We sought a language with which a usable facility for simple problems could be taught as rapidly as possible and which could be readily recalled to service after considerable periods of disuse. This clearly required a language with simple structure, few rules and special conventions, and a high degree of compatibility with common English and algebraic usage. We began by examining our experience in teaching Algol and Fortran to determine just what topics took the most time and provided the most difficulty. Secondly, we attempted to summarize and characterize the mistakes most frequently encountered in student programs written in these languages. We translated our general criteria into a set of specific design rules: 1. There should be as few different types of statements as possible. 2. All statements should be executable-?there should be no compiler-controlling declarations. 3. Ordinary decimal numbers should be used. There should be no explicit distinction between numbers with and without a decimal point. 4. Special programming forms would be used which would be highly restrictive, but largely self-explanatory. Their layout and labelling could reduce the number of rules and restrictions that would have to be elsewhere stated. 5. There should be few rules, and even fewer exceptions. In considering where teaching time is spent it is clearly evident that the trouble spots are in input-output and the treatment of subroutines. The input-output problem was quickly "solved" by specifying a rigid format. Input is by a read statement which simply lists the variables to be provided with values. The data is provided, one word per card with format dearly indicated on a special printed form. Output is by means of a write statement in which the desired variables are listed. The names and values of these variables are displayed in a standard format, easily read by someone who has never seen the particular program or heard of CORC or a computer. A title statement allows the programmer to further label his results. The treatment of subroutines was the subject of much deliberation and the solution represents probably the most unique aspect of CORC. It offers significant simplification compared to other algorithmic languages, but concomitant limitation in power. The solution is the concept of a "repeatable block" of statements. In simple and restrictive manner this provides the basic iteration statement of the language (corresponding to Fortran's do statement) as well as the subroutine or procedure. A sequence of statements is identified as a "block" by being preceded by a begin statement and followed by an end statement. The begin and end are clearly related to each other by bearing identical labels. These blocks are properly closed subroutines. They can be located anywhere in the program and one cannot "fall into" a block by encountering its begin statement in the normal sequential execution of the program. (The program would continue with the statement following the block end just as if the block did not exist.) The block may be entered only by means of a repeat statement which has one of three forms: REPEAT block-label E TIMES REPEAT block-label UNTIL EloE2 REPEAT block-label FOR V = E1 , E2, ¦ ¦ where E is an arithmetic expression, p is a relational operator and V is a variable. The block need not be contiguous to the repeat statement-?many repeat statements may refer to the same block. In each case the identity and limits of the block are evident from the labelling. This admittedly requires more writing than Algol or Fortran, particularly for cases where the blocks are short and directly following the controlling statement, but the simplicity of rules and the clarity with which a strange program can be followed are more than sufficient compensation. The blocks provide a rudimentary subroutine ability. The programmer is spared the relatively difficult concept of a dummy variable (and of course denied the power of the concept) as all variables are free and open to the entire program. A one-variable subroutine may be effected by using the repeat . . . for statement to substitute a variable with the reservation that the "dummy" variable cannot be carelessly duplicated elsewhere in the program. We believe that complex subroutine structures are infrequently encountered in the type of service for which CORC is intended. When they are encountered they represent a tremendous source of confusion and error and the neophyte might be better off with the tedious but straightforward CORC procedure. All numbers will be carried in floating point form in the program, truncated to word length as necessary. (Our truncation points are different in the 10-digit 220 and the 48-bit 1604.) The programmer may use integers and decimals as in common practice without special convention or distinction. CORC provides for subscripted variables, with a maximum of two subscripts, but with an unlimited number of levels. (Expressions including subscripted variables may appear in subscripts.) Desirous of eliminating the "array" or "dimension" declaration, and being unwilling to specify a standard dimension we make a virtue out of necessity and require a "preliminary dictionary of variables." All variables to be used-?not just those with subscripts-? nmst be listed on a special printed form. A space for dimension declaration is provided and initial values may also be given. While an experienced programmer would certainly regard this as an unnecessary and onerous burden it is a ve~T worthwhile discipline for a beginner. (This dictionary also allows some interesting opportunities in the compiler, which will be discussed below.) The assignment statement is conventional except for the prefatory word LET; i.e. LET X = Y. The word LET emphasizes the fact that the statement is a command and not an equation, and it permits a rule without exception that every statement starts with a "reserved" word. It also provides a measure of redundancy that is used to good advantage in the compiler. The IF statement is a two-way branch on a true or false condition: IF ElpE2 THEN GO TO label 1 ELSE GO TO label 2 In summary, the language consists of just nine types of statements (written one to a line, with FORTRAN-type continuation): LET GOTO IF REPEAT (BEGIN, END) READ WRITE TITLE NOTE (program comment) STOP Although a long and complete manual is available and used for initial presentation, the rules for the language can be succinctly but completely written on one page, and in fact are printed on the reverse side of one of the programruing forms. Extract: A field test of CORC A field test of CORC CORC has been operating at the Cornell Computing Center since September, 1962. A procedure is used in which students deposit their programs at the Center, written on the special CORC forms. The personnel of the Computing Center key-punch the programs (without verification) and make the initial computer run. Card decks, original programs and computer output are then returned to the students in a large work room where card files, work tables, desk calculators, and key punches are provided. The students are responsible for making corrections in the card decks as necessa~T and placing these in a re-run drawer. The work is handled on a first-come-first-served basis and no attempt is made to segregate the problems by course. Except for a few times when the key-punching load peaked drastically a 24 hour turnaround time has been provided. Often a program submitted before 9 AM would be ready in late afternoon. As of this writing almost 4000 programs have been submitted by more than 300 students in 20 different courses. The average number of passes to achieve acceptable operation is slightly more than two (somewhat more than 4000 reruns have been submitted). Equally significant, about half of the programs ran acceptably on the first pass. In interpreting these results one should bear in mind that for the majority of these students, instruction in CORC was an incidental inclusion in a mathematics or engineering course and that the instructor was simultaneously experiencing his first contact with automatic computation. In addition some reruns were occasioned by key-punching errors that were no fault of the students', and during the first weeks of operation reruns were occasionally required fox" programs that revealed residual faults in the compiler. On the whole the language and the operating system have been most satisfactory. Students, faculty and the Computing Center seem satisfied with the performance. We expect to put the present system into full-scale service next Fall, which will involve about 1000 new programmers each year, with a total of perhaps 3000 students making intermittent use of the system. This would provide an average load of 150-200 programs per day. We are aware that Fortran and Algol can be taught to large numbers of students in relatively short periods of time and can be used in a closed-shop operation such as the one we have described. Cornell has used the Burroughs Algol extensively in this manner in prior years. We are also aware that there are pedagogical techniques such as programmed learning and filmed lectures which can make this instruction efficient and economical. But we are entirely convinced that given the same competence of instructor and students and comparable instructional methods a CORC-like language can be significantly more rapidly taught and learned than Fortran or Algol and is a much more practical computing vehicle for the occasional programmer. Although changes in the source language may be made from time to time we intend to resist the pressures and temptations to snake seemingly innocent additions which could in time erode the basic objective of the project. The implementing compilers are a different story altogether and we hope to see them undergo continual improvement. In particular we believe that much more elaborate and effective error-correction than we currently provide can be practically accomplished. We confidently expect that CORC will be used at Cornell for some years to come. We are willing to export the language but we do not intend to measure the success of the project by the number of other centers which adopt its use. CORC was constructed to serve a practical and local need at Cornell and to prove a point: it is possible to construct a language and a compiler that will make some of the benefit of automatic computation more readily available to an unskilled programmer by shifting more of the burden of the process onto the computer. CORC is only a start in this direction and we expect that others, more knowledgeable of the computing art than we, will produce systems which serve these goals much better. We think it is clear that a single algorithmic language will not adequately serve the needs of both professional and amateur programmers. Once this proposition is accepted and compromise solutions abandoned both groups can take better advantage of the computing power that is available today. in [ACM] CACM 6(06) (June 1963) view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details in The Computer Journal 5(4) January 1963 view details in The Computer Journal 5(4) January 1963 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details The paper contains some detailed description of the problems involved in data handling in commercial translators with emphasis on the need for more flexibility than presently available. The author, as have many before him, again questions the value of attempting to create languages "any fool can use" at the cost of efficiency and flexibility, when even these languages will not prevent the fool from having to debug his programs. On existing commercial translators, the author lists and compares briefly COBOL, FACT, COMTRAN and several English efforts which "are either not working, or not on a par with their American equivalents." The paper concludes with some not so new but nevertheless appropriate recommendations to computer manufacturers and standards committees, and the expectation of the universal acceptance of COBOL as He commercial language. in ACM Computing Reviews 4(01) January-February, 1963 view details in The Computer Journal 5(4) January 1963 view details The author briefly sets forth the history of the ALGOL effort and lists a number of processors for subsets of ALGOL 60. Three main points are then made: 1) ". . . notwithstanding the progress in constructing mechanical metalanguages, the natural languages remain our ultimate metalanguage." 2) the distinction between defining reports and secondary reports in documentation should be maintained. 3) the use of special metalanguages as a part of defining reports is recommended, following the success of the Backus notation for describing most of the syntax of ALGOL. The investigation of new metalanguages is encouraged, but the prospects for such tools to define the "semantics" of programming languages are not assessed. in ACM Computing Reviews 4(01) January-February, 1963 view details in [ACM] CACM 6(03) (Mar 1963) view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (4) 1964 Pergamon Press, Oxford view details JW Backus, FL Bauer, J Green, C Katz, J McCarthy, P Naur, AJ Perlis, H Rutishauser, K Samelson, B Vauquois, JH Wegstein, A van Wijngaarden and M Woodger The report gives a complete defining description of the international algorithmic language ALGOL 60. This is a language suitable for expressing a large class of numerical processes in a form sufficiently concise for direct automatic translation into the language of programmed automatic computers. The introduction contains an account of the preparatory work leading up to the final conference, where the language was defined. In addition the notions reference language, publication language, and hardware representations are explained. In the first chapter a survey of the basic constituents and features of the language is given, and the formal notation, by which the syntactic structure is defined, is explained. The second chapter lists all the basic symbols, and the syntactic units know as identifiers, numbers, and strings are defined. Further, some important notions such as quantity and value are defined. The third chapter explains the rules for forming expressions, and the means of these expressions. Three different types of expressions exist: arithmetic, Boolean (logical), and designational. The fourth chapter describes the operational units of the language, known and statements. The basic statements are: assignment statements (evaluation of a formula), go to statements (explicit break of the sequence of execution of statements), dummy statements, and procedure statements (call for execution of a closed process, defined by a procedure declaration. The formation of statements, for statements, compound statements, and blocks. In the fifth chapter the units known as declarations, serving for defining permanent properties of the units entering into a process described in the language, are defined. The report ends with two detailed examples of the use of the language, and an alphabetic index of definitions. External link: Online copy in The Computer Journal 5(4) January 1963 view details in [ACM] CACM 6(04) April 1963 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details (i) Strings can be assigned as values of variables. (ii) Strings can be used as operands of the relational operators: "=" and "~". Examples: color := 'black'; if color = 'black' then'" ; A description of the exact syntactical changes necessary in the language is given at the end of this paper. The equivalent of the additions is already built into such algebraic languages as IT and GAT. Variables having strings as value would be declared as being of type "string", and string arrays and string procedures (i.e. function designators of type string) would be allowed. It would be natural to have input procedures to assign strings as values of variables and output procedures to print string variables. It might be a practical necessity for fixed-word-length machines to restrict the length of strings to one wordlength. Restrictions somehow do not seem to be in the spirit of the ALGOL 60 report (to the exasperation of translator writers) but, of course, there are implicit restrictions on the size of integers and real numbers; so a restriction on the length of strings is not too unreasonable. Note that the additions do not provide for a way to decompose strings within the language. However, "packing" and "unpacking" routines could be added to a system which would respectively break a string down and store it symbol by symbol in a string array, and perform the reverse operation. A large class of symbol manipulation problems can be performed efficiently by splitting input strings into a nmnber of strings consisting of one symbol each and storing these in an array. The following advantages would be gained by incorporating the additions. (i) Simple string manipulation programs could be written in ALGOL. Programs have been written in GAT, which is a subset of ALGOL aS extended, to formMly differentiate, prove theorems, transpose music, and perform other such functions. ALGOL could be a very powerful language for writing such nonnumeric programs. (ii) It would be possible to output variable alphabetic information, for instance information input as data. This is not possible in ALGOL aS it stands. (iii) Algorithms involving multiple branching and sentinels could be better expressed. Consider the situatiou when a variable or its value can be in three or more possible states (for instance, the value of an integer variable being prime of form 4n+l, prime of form 4n--l, or non-prime, or, to take an example from an algorithm to be used in our ALGOL translator, the type of a variable being real, integer (or string) or Boolean). At one point in the program the state is found and later the program branches according to this state. At present a numerical indicator must be used for the state, for example, taking the values 0, 1 or 2. A branching statement might read in present notation : if type = 0 then "" else if type = 1 then "" else "'" ; The meaning of this statement could be appreciated much more readily if it were written using the additions: if type = ' r e a l ' then ? ? ? else if type = 'integer' then ? ? ? else ? " ? ; In addition, anywhere a sentinel (i.e. a numerical variable whose value is meaningless as a number but is used to convey information) is used, it would be useful to make it a string variable. When a sentinel has only two values a boolean variable (e.g. one named "number is prime") can be used. This is primarily an improvement to ALGOL in its role as a publication language for algorithms. We think it would cost virtually nothing to build our additions into a translator. Presumably, on encountering a string a translator encodes it into the internal alpha- numeric representation used by the machine concerned, and then stores it in a fixed location in a constant pool. There will be a similar routine for numbers, except that the conversion process will be different. Our additions only involve "transmits" and "equality jumps," which are not only independent of machine representation of constants but also of the type of variable used as operands provided that both operands have the same type. That is, if the translator is written so that statements such as: weather : = 'foggy'; if weather = 'foggy' then "" ; are first translate(/[ into: variable "a" := constant "b"; if variable "a" : = constant "b" then ? ? ? ; then, at least for most nmchines, these statements could be treated exactly as if variable "a" and constant "b" were integers. Thus a translator might consider integer and string as synonymous. (This is essentially what is done in GAT and IT). If, however, a thorough syntax check is made to detect such meaningless statements as color := 'black' X 'red'; number print ('red') ; where "number print" is a numerical output routine, the translator must differentiate between integer and string until the syntax check is completed. In fact, in the interpretation of ALGOL for some machines it might be reasonable to allow a string almost anywhere an integer is allowed, and then certain arithmetic operations might be used to effect string manipulation (e.g., multiplication by 26 might effect shifting). Obviously this could not be built into the general language as it would be impossible to define any semantics. in [ACM] CACM 6(04) April 1963 view details in The Computer Journal 5(4) January 1963 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details General Information Pegasus and Sirius are the names of computers made by Ferranti Ltd., of Manchester. Pegasus is a medium-sized, medium-speed machine with a magnetic drum store of 8192* words capacity, working in fixed-point binary arithmetic, with a word length of 39 binary digits which corresponds to 11 decimal places. Sirius is a more compact machine, working in decimal. The store is normally 4000 words but is extendable to a theoretical maximum of 10000 words, a word holding 10 decimal digits. Both machines use paper tape as their input and output media, using the code given in the Appendix. The autocodes used for the two machines are practically identical and everything in this chapter applies to both unless otherwise stated. in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details A preliminary section discusses the fact that a process description is in practice always incomplete, and relative to some assumed level of detail of analysis, in the sense that it indicates a sequence of subprocesses (such as arithmetic operations) to be carried out in a particular order, but stops short of the description of how each subprocess effect is achieved. The essential features of the use of names for reference to stored information are reviewed. Next, some characteristic features of ALGOL 60 are mentioned, and detailed suggestions are made as to how they may be generalized and unified so as to reduce the number of anomalies in that language and consequently to reduce the number of separate ideas which have to be assimilated in order to understand it. The principle adopted in this generalization is to observe what facilities have already to be provided for the correct handling of ALGOL 60 as source language, and to allow the free use of these facilities. One important feature is the use of lists of quantities as values of variables, assignable as a whole, as the result of evaluating expressions of type list (i.e., vector) or list list (i.e., including matrix). A second important feature is the use of names (identifiers) in general as permissible values of variables of type name. The avoidance of generating program at run time, as in ALGOL 60, is maintained -- an expression or statement may not be produced as value of an expression and assigned to a variable, although it may be associated with a name by appearing in a declaration. in ACM Computing Reviews 5(05) September-October 1964 view details 1) In ALGOL variables have types. The author wants to eliminate type declarations and also array declarations. It is not necessary to set array sizes since they are determined at run time by which subscripts are actually used. 2) In ALGOL 60, procedures, statements and labels cannot be assigned to variables in assignment statements. 3) Proposals have been made to eliminate side effects and to eliminate or require special declaration for recursive procedures. The author believes that compilers can recognize enough special cases in which the full generality is not used to allow compilation of efficient . code. He also tolerates declarations that may help the compiler but insists that they be optional. I have three comments: 1) The author does not try to show that enough special cases can be recognized to produce efficient code. I have some doubts particularly in systems which allow separate compilation of procedures, e.g. FORTRAN. 2) The process of generalizing a language can always be carried further at the cost of further difficulty in recognizing special cases. Unless some criteria are given for resisting further generality, the language will get beyond anyone's ability to write a compiler for the most powerful machine in existence. 3) To me, the author's desire that the order of evaluation of primaries be defined by the language in order to make side-effects definite is especially dubious. First, the type of procedures possess few of the mathematical properties a functions. Second, efficient compilation for multi-processor machines and even for machines like the CDC 6600 require maximum flexibility in scheduling the parts of a computation. Finally, I would like to express the belief that languages can be devised that allow easy expression of complex processes that allow fast compilation of efficient programs, and that an mathematically elegant. No one of these criteria can be al lowed to dominate without producing a distorted result. in ACM Computing Reviews 5(03) May-June 1964 view details in Sass, M. and W. Wilkinson, eds. Computer Augmentation of Human Reasoning Spartan Books, Washington, D.C., 1965 view details The preface states that "this book is intended to serve as an introduction to the programming of automatic computers." The first 24 pages present such an introduction, apparently assuming that this is the reader's first contact with a stored-program digital Computer. Part II, which makes up about 60 percent of this short volume, consists of three chapters, each of which describes a different autocode. The word "autocode" as used in England corresponds roughly to "compiler language') in the United States. The authors apparently consider an autocode to be machine-dependent, in contrast to a "universal computing language" like Algol, which is machine independent. The three autocodes discussed are for the Pegasus-Sirius, the Elliott 803, and the Ferranti Mercury. The machines themselves are not described here in any detail. They are all rather small machines, and are not of very great general interest. Unfortunately, the Same is true of their autocodes. The Mercury autocode is treated at greatest length and in greatest detail. It is an interesting system, but its interest is now mostly historical, illustrating some of the early work of Brooker and his colleagues at Manchester. Most of the material in this book will be of interest only to the devoted specialist and perhaps to the historian in the field of computer languages. A final section of the book presents a 14-page discussion of Algol. It is a good but very brief resume of the language. in Sass, M. and W. Wilkinson, eds. Computer Augmentation of Human Reasoning Spartan Books, Washington, D.C., 1965 view details in Sass, M. and W. Wilkinson, eds. Computer Augmentation of Human Reasoning Spartan Books, Washington, D.C., 1965 view details in Sass, M. and W. Wilkinson, eds. Computer Augmentation of Human Reasoning Spartan Books, Washington, D.C., 1965 view details The ALGOL purist, however, will object to this book on two counts. First, ALGOL appears in the book on a hardware representation for the General Electric 625/635, rather than in the reference representation of the ALGOL60 Report. While this is not a major disadvantage, it will present a problem to the casual reader who, becoming inspired, turns to the Algorithms Section of the ACM Communications to inspect some live ALGOL programs, only to discover that they look very unfamiliar. At the least, I would have hoped for a transliterative appendix. Second, there is the perduring question of input/output. Again, the solution chosen for this book (and more clearly stated than that of the representation) is to pick the input/output system for an extant compiler and use it as an example. As a minimal explanation, there should appear a reference to the two sets of input/output conventions which are incorporated in the proposed standard ALGOL. These criticisms are, however, comparatively minor; the book, as a whole, is an excellent one. in ACM Computing Reviews 8(06) November-December 1967 view details in ACM Computing Reviews 8(06) November-December 1967 view details Abstract: The need for implementation models in understanding languages, Algol 68 in particular, is stressed. The model is used to demonstrate the new concept of necessary environment of a procedure. Extract: THe necesary environment This new concept of necessary environment may be applied to other languages which have procedure values treated as general values, and in which the non-locals are bound as in Algol 60 or 68. In some of these languages such as GEDANKEN [Reynolds] and OREGANO, which this author is developing, the non-locals are kept as long as the procedure value still exists . The usual implementation technique is to save the entire binding time environment . However, saving only the necessary environment would insure correctness while conserving storage. in SIGPLAN Notices 5(09) September 1970 view details in SIGPLAN Notices 5(09) September 1970 view details in [ACM] CACM 15(07) (July 1972) view details There was a tremendous number of ideas floating around at the time. Around that rime, Al Perlis had come through RAND and talked about how to really do all this. He stimulated a lot of people to at least think about it if not do something about it. I got deeper and deeper into the whole mystique of language design and compiler construction, and began to follow the first international effort?IAL?rather closely. RAND, SDC and some other organizations decided that the International Algebraic Language, which was eventually called ALGOL 58, was something of interest. Even though it had some flaws and ambiguities in it, at least it looked like a reasonable improvement over FORTRAN. From it came JOVIAL at SDC. [...] ALGOL 58 came along and excited a lot of people, but neither ALGOL 58 nor ALGOL 60 was really accepted in this country, because by that time FORTRAN was really rolling down the road. SHARE had promoted, or helped promote FORTRAN II rather heavily and then along came FORTRAN III which in retrospect was a rather idiotic attempt. [...] So FORTRAN III was born and it allowed you to do much of what JOVIAL did, dropping into assembly language by adding a statement that allowed you to pop in and out of assembly from FORTRAN, which everybody knew was a disaster. [...] I have the strong recollection that FORTRAN III actually saw the light of day, but it died. [13] It just didn't have it?there were people who were much closer to FORTRAN because I had begun to move away from FORTRAN per se and pursue other language oriented things. I was looking at the SDC's JOVIAL. I was trying to build some small compilers for open shop languages at RAND at the time and then I got involved in the SHARE ALGOL effort in '58-'59. [...] Well, there was a letter written by, I believe it was Rudishauser, to possibly Al Perlis through the ACM[15], and said the world was going off in a thousand different directions with this language stuff. Maybe we ought to get together, the Europeans and the Americans, and design one internationally based language that we would all agree upon, and maybe we will solve some of the world's nastier problems, particularly in program communications, if we have a common source language. We may end up getting real power in the world of commonality, usability, and things like that. [...] I have to back up. I just remembered something. There was another effort going on in SHARE called UNCOL: Universal Computer Oriented Language, which I got my fingers into. As a result of that, the ACM appointed a group, and I don't know whether Perlis was the chairman of the group, but I believe he was. I know John Backus was a member of the group. And I am trying to remember who the others were. Joe Wegstein may well have been a member. I know he was on ALGOL 60. I don't know whether he was on '58. Anyway, the group met in Zurich and sat down and designed a language. What they came back with was ALGOL '58. And they had done it very, very swiftly. Everyone came with their own ideas; there was an awful lot of argument and compromise. But it wasn't a terribly bad language. It had some ambiguities and some holes, e.g., they completely left the I/O out, so that was up to the implementer to decide how he had to do it on his local computer. It may not have been a full quantum improvement over FORTRAN, but it was an improvement. It incorporated an awful lot of things which you couldn't express or only expressed with great difficulty in FORTRAN. In IAL or ALGOL it was reasonably straight forward. [...] There were a lot of us, including me, who sat around and looked at ALGOL and realized that it had a lot of faults. There are notational things that could be cleaned up. There are things that they forgot to put in which could be easily added. There are ambiguities that really had to be straightened out. It didn't have any I/O. And it is not all that easy to get common implementation because there are these vagaries of interpretation about what certain things meant. And I can't remember whether ALGOL 58 was a block structured language or not, but there were some misunderstandings about the scope of variables and all the other things that you run into when you start putting together rather complex language structures. After some early and some aborted attempts to implement ALGOL 58, which is when I got really involved with ALGOL through SHARE. We decided that ALGOL was a good thing and that SHARE was going to implement ALGOL 58, or at least convince IBM to help us. We would help specify how it was to be done, and IBM would do the implementation. Bob Bemer, Julian Green and several other people at IBM were building something called XTRAN, which was a tool that would help them implement almost any language, but in particular ALGOL. Things go to the point where it was clearly understood that ALGOL had to be cleaned up. And so the [original] group [that produced IAL] was to reconvene in late '59 or early '60. Their report came out in early '60, which is why it was called ALGOL 60, although they actually met in '59. Perlis was the chairman of the group that went to Paris to clean up IAL. That is when the name ALGOL was invented. [16] The earlier effort was designated ALGOL 58 because the new one was designated '60. I know Joe Wegstein was there. I know Julian Green was there. I know John Backus was there because that is when Backus Normal Form (before it became Backus Naur Form) was invented. I don't know whether it is apocryphal or what but the story goes that John finally figured out [how to represent the syntax of a programming language in a formal notation] on the plane over to Paris. I don't quite believe that, knowing John. He works very long and hard and maybe he had an of inspiration [on the plane] but the [representation problem] had been brewing as a result of '58. And the difficulties they had trying to get a syntax description pushed him into working that problem very hard. There were thirteen people [at the Paris meeting] in all. Seven from Europe and six from the United States, but I can't remember any of the rest of the six. The seventh U.S. representative was killed in an automobile accident just before he was supposed to go. I can't remember who that was [William Turanski]. [...] They [the U.S. committee] came back and Julian Green showed up at the SHARE meeting in March following the ALGOL 60 meeting, and he quietly presented me [as Chairman of the SHARE ALGOL Committee] with a draft copy of the report written in Backus NORMAL FORM. I looked at the thing and had a hemorrhage, because we had all been working very hard on the supposition that they were going to go away and fix ALGOL 58 and make it useful and wonderful and clean and beautiful and unambiguous. What they had done was gone away and thrown ALGOL 58 out the window and started clean again. They came up with a whole new completely incompatible language. People who had implemented ALGOL 58 in any shape or form really had thrown their money away because that was no longer going to be the international language, ALGOL 60 was. The compatibility was just not there. I got very, very upset. I wrote Dr. Perlis, who was then at Carnegie Tech, a rather harsh and nasty letter about dereliction of duty and a few odd things like that. I'm sure there is a copy of it somewhere in RAND. I couldn't get it [mailed] out of the building first time I tried. There was a lady who controlled all outgoing mail from the RAND Corporation. Her primary job was to see that no classified information was sent out without proper protection and was going to the recipient who knew how to handle it. She was also the guardian of the corporate morals, ethics and language and my letter was rather harsh. I had gone to Paul Armer and said, "I am going to send this very nasty letter. Be warned. Apparently, he saw it and said, "If that is what you want to say, okay, that is what you want to say." The next morning when I came in the letter hadn't gone out. We had a minor battle inside RAND convincing them I had every right to say what I was saying, both as a member of the RAND Corporation staff and representing my chairmanship of the SHARE ALGOL Committee. Finally, it got out the door. And I will never forget Perlis' answer scribbled on the bottom of my original letter that said in essence, "Go away, you bother me or you don't bother me." But I think that was the death knell for ALGOL 60 and for the concept of ALGOL in this country. MAPSTONE: Maybe the death knell of any kind of universal language. BERNSTEIN: The basic problem was you can't get thirteen guys together and in six days invent the world. And it wasn't the right flavor of people. The mix was all wrong. I have yet to be able to plow through the wondrous and glorious [latest] ALGOL report. But it is probably a major improvement. It is far more consistent, has far fewer ambiguities, and many well be one of the most powerful and delightful programming languages in the world. If you could only understand the description. It is a terribly, terribly complex thing and you must spend many hours studying it in order to get any appreciation out of it. But it was done by a fairly small group over a long period of time who really honed and worked the problem. Julian Green, Joe Wegstein and I had a rather uproarious session which I didn't find very uproarious. I got rather upset when I heard the stories of how ALGOL 60 was created. It was like putting a piece of legislation through Congress rather than a bunch of scientists getting together and saying, "What's best? What's cleanest? What's purest? What really is scientifically or technologically the best possible thing, the apotheosis of our skill and our knowledge." Instead, what they did was barter as in, "If you will let me put this in, I will let you put that in. No, no. I am not going to vote for your thing if you are going to argue with me about that thing." Joe Wegstein was sitting there telling me that when things got out of order he would slam his hand down on the table and bring everybody to silence by shaking them up. It doesn't sound to me the way you design a language. You go away and the think about it for a while. Think through the problems: What is the objective of the whole thing? Who are we trying to get to use it? How would you like them to be able to use it? Are there any implementation aspects that you might take into account? Can this thing be implemented at all on the existing computer? Must it wait for the next generation? Things like that. That wasn't the kind of considerations that they made. Now they may have had all those considerations in the back of their mind. And maybe I am being over-critical, but I believe they blew it. They just destroyed whatever first, good step they had taken by not going after ALGOL 58, as impotent as it may have been in their two year further down the pike view of the world. Who cared if it didn't have "own" variables. Nobody really understood what they were all about anyway. They probably represent one tenth of one percent of the utility of a true language. The decision that all procedures had to be recursive was an interesting concept, but not something you lay on the world before they are thoroughly and completely educated in the value and use and the need, and where you may or may not want to get into things like that. And they just came out with all this beautiful, gorgeous?not terribly pragmatic?inconsistent language. And then they did other wondrous and glorious things. They said, we will have the publication language and we leave to the implementer the hardware representation. And that is where we had great fun in SHARE. I must have spent sixty or seventy hours sitting in on arguments, chairing a committee, trying to satisfy all the diverse points of view about a SHARE hardware representation for ALGOL 60. Up to this time SHARE had a resolution which blessed the whole thing. And it was subsequent to that that I became completely disenchanted with the whole thing. The deeper I got into it, the angrier I got, and finally introduced a resolution that SHARE withdraw its original resolution and castigate the idiots who had done that, rather soundly. It didn't get that strongly worded, but we withdrew our original commendation at ACM and the [other] parties involved were going off on various crusade to create an ALGOL international language. MAPSTONE: What was the SHARE resolution? BERNSTEIN: I think it ended up just withdrawing SHARE's original resolution. It said: We no longer bless it, we don't care. SHARE no longer has any interest in ALGOL?particularly ALGOL 60. MAPSTONE: But the language did go on, and is still extant today? BERNSTEIN: ALGOL 60: yes, people still talk about it. It may be used in a few universities. MAPSTONE: Is there not a language called ALGOL which is in use today? BERNSTEIN: Yes. In fact, there is still some ALGOL 60 compilers around. How much of ALGOL 60 they really cover is not clear to me. SHARE actually did eventually, after I gave up, produce [a compiler]. This was a SHARE effort. We decided that we didn't have much of a chance to convince IBM [to implement ALGOL]. IBM was completely antithetical to ALGOL by this time. They had gotten turned off and put most of their interest in FORTRAN. We had essentially been told was that IBM was not going to implement an ALGOL processor as an IBM supported language. They said, "If you guys want to do something, build your own compiler with blessings. We'll even help you." Julian Green and Rex Franciotti were two guys that I interfaced with from IBM, who were trying to build certain pieces of the ALGOL compiler for us. I had given up on trying to keep a cooperative effort going. I had worked rather hard building one piece with a guy at Lockheed in Sunnyvale. We would get together occasionally and check out code to get this and that going. And then somebody would turn up and hadn't done their job, so by that time I got sick and tired of the whole thing and said, "To hell with you guys." I thought that the whole business of trying to get a cooperative ALGOL compiler produced was an abortion. But some people stuck by it, particularly people at Oak Ridge and I can't remember where the other guy was from. I guess he was at Rocketdyne and had a certain personal dedication to the whole thing. Marjorie Lisky and he eventually put together an operable ALGOL compiler which she offered to distribute through SHARE. I don't know how many people took her up on that and I don't know if it ever really worked. It took umpteen thousand passes and probably worked reasonably well. It created at least one social upset. As a result of Julian Green and Marjorie Lisky working so closely together on ALGOL, both divorced their spouses and married each other. MAPSTONE: Well, that means they worked well together. in [ACM] CACM 15(07) (July 1972) view details in [ACM] CACM 15(07) (July 1972) view details in [ACM] CACM 15(07) (July 1972) view details in [ACM] CACM 15(07) (July 1972) view details in [ACM] CACM 15(07) (July 1972) view details in [ACM] CACM 15(07) (July 1972) view details Extract: Introduction Introduction There are several areas where traditional high-level languages are notably less efficient than hand-coding. Two of these areas are accessing array elements and calling procedures. Although in the former case much research has been done to improve the efficiency (resulting in the ALCOR and FORTRAN H2 compilers), little work has been published on calling procedures. In many scientific computations procedures are not called very frequently but this is not true in non-numeric work. Since modularisation by means of procedures is one of the most powerful programming tools in structuring complex problems, an inefficient calling mechanism can be very detrimental. In recent years there has been an increased use of high-level languages as assembler replacements ? the so-called 'System Implementation Languages'. Such languages must achieve a high degree of object code efficiency if their use is to become more widespread. The purpose of this paper is to compare the procedure calling mechanism of traditional high-level languages with both system implementation languages and machine-code. Extract: Ackermann's function Ackermann's function In view of the paper by Sundblad [1], a reasonable test case for study seemed to be the evaluation of Ackermann's function. This function has the advantage of being very short and not requiring large integer values for typical cases, yet being complex enough to be a significant test. The figures given in Sundblad's paper also provided a basis for comparison before many values had been obtained. Following Sundblad, we calculate Ackermann (3,n) for increasing n, in accordance with the complete program listing below. Three figures are determined from the test, the average execution time per call, the number of instructions executed per call and the amount of stack space required for each call. Although the average time per call can be determined from running the program, the other two figures cannot be found so easily and indeed, in many cases the figures are not available. [1]Y. Sundblad, The Ackermann function. A theoretical, computational and formula manipulative study. BIT 11 (1971), 107119. Extract: Acknowledgements Acknowledgements This work has been inspired by the International Federation for Information Processing Working Group 2.4. The desire of the group to obtain information on the performance of system implementation languages has led to tests such as this. It would not have been possible to write this paper without the active help of the following persons in running the test: ? Mr. L. Ammeraal (Mini-ALGOL 68), Dr R. Backhouse (B5500), Dr J. G. P. Barnes (RTL/2), Dr D. A. Bell (PL516), Dr H. Boom (Cyber 73 ALGOL 68), Mr P. Klint (C-UNIX), Mr R. Conradi (MARY, CYBER 74, 1108, CDC3300), Mr W. Findlay (PASCAL 1906A & machine code), Mr W. B. Foulkes (PASCAL 370/158). Professor G. Goos (B6700), Mr. V. Hath-way (BCPL MOD 1), Mr M. Healey (PL/I OPT), Professor J. J. Horning (Sue 11), Mr B. Jones (ALGOL 60, Dclft 370/165), Dr M. MeKeag (PASCAL & ALGOL 60, 1906S), Mr Z. Mocsi (R10), Dr J. Palme (DEC10 SIMULA & machine code), Mr M.J. Parsons (PALGOL), Dr M. Richards (BCPL), Professor J. S. Rohl (Manchester 1900 ALGOL), Mr P. D. Stephens (IMP), Dr P. Wetherall (ALGOL 68-R), Professor N. Wirth (PASCAL), Professor D. B. Wortman (370/165 machine code) and Professor W. A. Wulf (Bliss 10, Bliss 11 & machine code). Extract: Results of tests (altered to include authors where known)
Program listing begin integer i, j, k, k1; real t1, t2; integer procedure Ackermann(m, n); value m, n; integer m, n; Ackermann := if m = 0 then n + l else if n = 0 then Ackermann(m -1,1) else Ackermann(m - 1, Ackermann(m, n - 1)); k:= 16; k1 := 1; for i := 1 step 1 until 6 do begin t1 := cputime; j : = Ackermann(3, i); t2 := cputime; if j = A;-3 then outtext(1, 'WRONG VALUE'); outreal(1, t2 ? t1); comment Now output time per call; outreal(1, 3 x (t2 - t1)/(512 x k1 - 15 x k + 9x i + 37))); k1 := 4 x k1; k := 2 x k end end Extract: Properties of the algorithm Properties of the algorithm To determine the execution characteristics of the test one needs the following properties of the algorithm (which can be easily proved by induction). The number of executions of each leg of the algorithm in calculating Ackermann (3, n) is: first leg: (64x4|n- 72x2|n + 6xn + 26)/3 second leg: ( 24 x 2 | n - 3 x n - 12)/3 third leg: (64x4|n- 72x2|n + 6xn + 23)/3 total no. of calls = (128 x4|n- 120x2|n + 9xn + 37)/3 Hence for large n, the average number of instructions per call is half the number of instructions in the first and third legs. Both legs contain the procedure entry and exit overheads and the third leg includes two unsuccessful tests for equality with zero. So the number of instructions executed per call can be found by examining the machine code produced by the compiler. Unfortunately this is not always easy and sometimes almost impossible. To provide an approximate comparative value, an estimate has been made from the time using a Gibson mix value [2] to extrapolate from a similar machine. In a few cases, the instructions executed arc known but the time has not been measured. In these cases, an estimate for the time is given based upon published instruction times. The amount of stack space required by the program is determined by the maximum depth of procedure calls. This is given by Sundblad as Ackermann(3, n) - 1 = 2 | (n + 3) - 4 and occurs when the third leg is being evaluated at all but the last of those levels. Hence the amount of stack space required doubles when n is increased by one. For a more detailed discussion on the storage requirements and the definition of the 'maximum depth of recursion' see [5]. To measure this space, Sundblad observed the maximum value of 11 for which Ackermann (3, n) could be calculated using 26K words of store (which he called the 'capability'). Although this measurement is easy to take, it only provides a rough estimate of the space needed per call. Examination of the machine code of the third leg of the algorithm gives the precise value. In fact, the number of words per call is the difference in the address of 4m in the inner call to the address of the parameter in the routine. It is not easy to calculate this value from the code, and so a post-mortem print may be the easiest way to find the value. Rather than give the capability, the number of words per call is listed with the results. If only the capability is known, bounds can be given for the number of words per call by assuming that between 3K and 10K words are needed out of the 26K store for the program and run-time system. Extract: Notes on the results and Factors influencing the execution speed Notes on the results Estimates of missing values are included in the table in brackets and have been calculated in the manner described above. The program listing in all cases has followed the coding given very closely. The only exceptions are 1) the machine code examples, 2) the PASCAL and SUE systems which have no conditional expressions, and 3) PL516 which follows the hardware of the machine in not supporting recursion (stacking is performed by subroutines). Factors influencing the execution speed Factors influencing the call of a recursive procedure vary from inherent problems with the architecture of the machine to purely software problems on the design of the procedure calling mechanism. Against each of the results above is a sequence of letters and digits which describes the principle characteristics governing the execution performance. Recursion. On most modern machines with a few base registers and indexing facilities, the basic overhead of recursion is very small indeed. A few minicomputers do not have adequate base registers or addressing facilities to support recursion. The Honeywell DDP5l6 is of this type, hence with the high-level assembler PL516 stacking must be performed explicitly. On some machines, although the addressing logic is available an additional time penalty occurs by addressing via pointers. On the Modular 1 implementation of CORAL 66, recursion is an option. In fact the code produced with recursion is more efficient than that without recursion. The reason for this is that the short address length of the Modular 1 means that base registers must be loaded to access the variables of another procedure. This is a larger overhead than that incurred using a single stack register which only needs to he incremented and decremented by a small amount. Without recursion, the number of instructions is increased to 19.5 (30% more). Storage allocation. In order to execute this program, a stack storage scheme is necessary. It is sometimes possible on conventional hardware to use an area in the store as stack without performing an explicit software check for stack overflow. One can then rely upon a hardware address violation which should permit the output of a suitable diagnostic. Such systems are marked by an N, whereas C denotes a software stack overflow check. Languages such as ALGOL 68, PL/I and SIMULA require more than a simple stack and hence must perform an overflow check in a manner which allows a recovery to perform some garbage collection. Systems like this arc marked with an H. PASCAL permits additional storage apart from the stack but without garbage collection. Although no garbage collection is involved, PASCAL is marked with an H. Only SIMULA requires an actual garbage collection during the execution of this test. The method used to administer the stack is partly a matter of language design and partly a matter of implementation. For instance, although ALGOL 68 requires a heap, the ALGOL 68-R implementation will run a stack only if the program does not require the heap. The difference, shown above, is that an additional subroutine is called on procedure entry to check that adequate stack space is available. Complete display. Block structured languages in general require a base pointer for every block whose variables can be accessed at the relevant part of the program. This facility is marked with a D. Languages such as BCPL and Burroughs B5500 ALGOL restrict access to local and global identifiers only, permitting a significant economy in pointers. These languages are marked with an L. The actual method of implementing the display can vary independently of the language. For instance, ALGOL W and IMP have every base pointer in a register, the PASCAL implementations above backchain the display (from the local procedure) and ALGOL 68-R keeps a copy in core of the full display in the local block. In almost all cases, there will be small variations in the calling overhead depending upon the relevant positions (in the display) of the call and the procedure. Dynamic stack storage. In ALGOL 60, the sizes of arrays are not, in general, known until program execution. This facility, implemented with second order working store, requires a small overhead on the administration of stack storage even when no arrays are being used, as in this test. Languages requiring such storage are marked with a 2 whereas systems allowing only storage whose size can be determined at compile time are marked with a W. PALGOL and RTL/2 are LW languages and hence require only one stack pointer (and one pointer for static storage depending upon the addressing structure). Parameter handling. The most expensive mechanism is marked with a T which denotes a 'thunk' that is required to implement the ALGOL 60 call by name [4]. A thunk can be avoided with this test by performing all parameter checking at compile time and using only the value mechanism (V). The KDF9, B5500 and Atlas ALGOL compilers all use the value mechanism. The use of the thunk mechanism by the other ALGOL 60 compilers is caused by the problem of handling the call of formal procedures whose parameters cannot be specified [3]. With value parameters, the ICL 1900 ALGOL compiler uses a simplified thunk mechanism but the Manchester ALGOL compiler uses the value mechanism. The PL/I systems use call by address which is marked with an A. With recursion, the addresses of parameters are dynamic and in consequence this method is less efficient than call by value. Open code or subroutines. Systems which handle this test entirely by open code are marked with an O, whereas the use of subroutines is marked with an R. The PL/I optimising compiler generates a subroutine call, but it is not invoked unless insufficient stack space is given (which did not happen in this case). Extract: Conclusion Conclusion. Ackermann's function provides a simple method of comparing the efficiency of the procedure calling mechanism of a language permitting recursion. The results show a very wide variation in performance even for languages containing no inherent complications. Additional instructions required in ALGOL 68, PL/I and PASCAL to check for stack overflow are quite insignificant compared to the hundreds of extra instructions executed by the inefficient implementations of ALGOL 60. There is no doubt that 'System Implementation Languages' give very much better results on this test without reducing the facilities to the programmer. Machine independence seems to be realised in this case without any measurable cost as BCPL shows. Does Ackermann s function represent a good test for a system implementation language? Unfortunately no statistical information is available to the author on the use of procedures in operating systems and compilers etc. Hence it is not known if, for instance, two parameters is typical. The large amount of stack space used is certainly not typical and can result in pathological situations. For instance, stack space is claimed in 64 word units under George 3 on a 1906A, but is not released. Hence during the first part of the algorithm when the stack is being increased a large operating system overhead occurs. During the second part when the stack is rarely increased beyond its previous maximum, there is no significant overhead. The computational part of testing for the equality with zero, jumping and adding or subtracting one seems very typical of non-numeric work. On the 360 computer, the fact that the the algorithm is very short ( <4K bytes) results in a small saving, but on the IMP compiler which can take advantage of this the speed was only the increased by 3%. From the better figures produced by system implementation languages, the code for Ackermann is roughly divided as follows: instructions subroutine entry and exit 2 stacking return address 1 setting up environment 3 checking for stack overflow 2 (if check made) restoring old environment 3 (on procedure exit) setting parameters 2x1=2 body of Ackermann 8 Total 21 in [ACM] CACM 15(07) (July 1972) view details in [ACM] CACM 15(07) (July 1972) view details in [ACM] CACM 15(07) (July 1972) view details in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details in SIGPLAN Notices 13(11) Nov 1978 view details in Computer Languages 4(3-4) view details During the period, August 1962 to October 1966, I attended every meeeting of the IFIP ALGOL working group. After completing our labours on the IFIP ALGOL subset, we started on the design of ALGOL X, the intended successor to ALGOL 60. More suggestions for new features were made and in May 1965, Niklaus Wirth was commissioned to collate them into a single language design. I was delighted by his draft design which avoided all the known defects of ALGOL 60 and included several new features, all of which could be simply and efficiently implemented, and safely and conveniently used. The description of the language was not yet complete. I worked hard on making suggestions for its improvement and so did many other mambers of our group. By the time of the next meeting in St Pierre de Chartreuse, France in October 1965, we had a draft of an excellent and realistic language design which was published in June 1966 as "A Contribution to the Development of ALGOL", in the Communications of the ACM. It was implemented on the IBM 360 and given the title ALGOL W by its many happy users. It was not only a worthy successor of ALGOL 60, it was even a worthy predecessor of Pascal. At the same meeting, the ALGOL committee had placed before it, a short, incomplete and rather incomprehensible document, describing a different, more ambitious and, to me, a far less attractive language. I was astonished when the working group, consisting of all the best-known international experts of programming languages, resolved to lay aside the commissioned draft on which we had all been working and swallow a line with such an unattractive bait. This happened just one week after our inquest on the 503 Mark II software project. I gave desperate warnings against the obscurity, the complexity, and over-ambition of the new design, but my warnings went unheeded. I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late. So it was with the ALGOL committee. Clearly the draft which it preferred was not yet perfect. So a new and final draft of the new ALGOL language design was promised in three months' time; it was to be submitted to the scrutiny of a subgroup of four members including myself. Three months came and went, without a word of the new draft. After six months, the subgroup met in the Netherlands. We had before us a longer and thicker document, full of errors corrected at the last minute, describing yet another, but to me equally unattractive, language. Niklaus Wirth and I spent some time trying to get removed some of the deficiencies in the design and in the description, but in vain. The completed final draft of the language was promised for the next meeting of the full ALGOL committee in three months' time. Three months come and went - not a word of the new draft appeared. After six months, in October 1966, the ALGOL working group met in Warsaw. It had before it an even longer and thicker document, full of errors corrected at the last minute, describing equally obscurely yet another different, and to me equally unattractive, language. The experts in the group could not see the defects of the design and they firmly resolved to adopt the draft believing it would be completed in three months. In vain, I urged them to remove some of the technical mistakes of the language, the predominance of references, the default type conversions. Far from wishing to simplify the language, the working group actually asked the authors to include even more complex features like overloading of operators and concurrency. When any language design project is nearing completion, there is always a mad rush to get new features added before standardization. The rush is mad indeed, because it leads in to a trap from which there is no escape. A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later. At last, in December 1968, in a mood of black depression, I attended the meeting in Munich at which our long-gestated monster was to come to birth and receive the name ALGOL 68. By this time, a number of other members of the group had become disillusioned, but too late: The committee was now packed with supporters of the language, which was sent up for promulgation by the higher committees of IFIP. The best we could do was to send with it a minority report, stating our considered view that, "...as a tool for the reliable creation of sophisticated programs, the language was a failure." This report was later suppressed by IFIP, an act which reminds me of the lines of Hilaire Belloc, But scientists who ought to know, Assure us that it must be so. Oh, let us never, never doubt What nobody is sure about. I did not attend any further meetings of that working group. in [ACM] CACM 24(02) February 1981 view details in [ACM] CACM 24(02) February 1981 view details in [ACM] CACM 24(02) February 1981 view details After introductory remarks, Jean Sammet, the Conference and Program Committee Chairman, introduces the keynote speaker and "the third programmer of the first large scale digital computer, Mark I," Capt. Grace Hopper of the US Navy. Capt. Hopper describes the very early history -- combining personal recollections and technical observations. It is an excellent historical talk, precisely establishing the milieu existing in the 1940s and early 50s, when the concept of using a computer to create programs was just emerging. The FORTRAN presentation by John Backus emphasizes the importance of object efficiency for FORTRAN acceptance. He states that language design was never considered a problem; the real problem was to consistently produce object programs as efficient as hand-coded ones. The presentation captures the clear and unwavering focus of Backus's original team on that goal: a focus and dedication which characterized the direction of one of the most significant software projects in the history of computers. The controversies in the committee designing ALGOL 60 are re-enacted in miniature on these tapes. Alan Perlis describes the American contributions, concluding that ALGOL has Influenced all languages since that time. "It's the mother's milk of us all." Peter Naur describes the European contributions and the origins of recursion in the language. A lively floor discussion involving John McCarthy, John Backus, and Fritz Bauer ensues. The Algol 60 committee got involved in "academic log rolling" according to McCarthy who also points out that the committee decision not to consider implementation led to a language which was not implementable as a whole. It was assumed that "everyone was a gentleman and none would propose something he didn't know how to implement. However there was no guarantee the combination was implementable." The excerpt on the LISP lecture by John McCarthy emphasizes the features of the language and is an excellent description of its intellectual sources. Jean Sammet in presenting COBOL also clearly defines the influences on the language and how and why the choices were made in a series of committee meetings. These choices were very much colored by the decision to take "a short range composite approach good for at least a year or two." The tapes show how differently some of these important languages developed. According to Douglas Ross, APT evolved out of application requirements; by contrast, the major features of JOVIAL were developed in a few minutes, relates Jules Schwartz, its sole designer. Geoffrey Gordon tells how GPSS also grew from feedback from application users. SIMULA, developed by Kristen Nygaard and Ole-Johan Dahl, didn't even start as a programming language. Charles Baker discusses the development of JOSS, and Thomas Kurtz, BASIC -- intended to make learning to program analogous to learning to drive a car: by doing it. PL/I was the largest language represented at the conference. According to presenter, George Radin, much of the complexity and size is due to the necessity of defining the result of all operations on mixed types and to implicit typing. The excerpts of the presentations on SNOBOL by Ralph Griswold and APL by Kenneth Iverson establish the specific motivations for those languages: in both cases conserving human resources was considered very important. The conference banquet tapes contain anecdotes by the conference speakers and by master of ceremonies Bernard Galler. These entertaining historical asides and footnotes sometimes give more insight into the how and why things happened than the more scholarly analyses. For example, George Radin's story about the PL/I committee's ordering pizza -- the pizza had everything anyone wanted -- says a great deal about how the committee functioned when designing the language. These tapes constitute an important historical record. Unfortunately, the quality of the tapes is less than desired. They were not professionally produced and the picture quality is often quite poor. Still-photos by Robert McClure and Richard Wexelblat are used where the videotape is inadequate. However, the excerpts have been well selected by J.A.N. Lee, Jean Sammet, and Henry Tropp. In his summary Fred Brooks says that "the best thing about this conference is the character set." He also points out that the presentations on the languages designed by a committee emphasized the process, whereas the presentations on single-author languages emphasized technical issues. These tapes capture the factors that have made the history: the personalities, the process, and the technology. They are interesting now and will be invaluable to future historians of the pioneering period of language development. in ACM Computing Reviews March 1982 view details It is probably also fair to say that the defining report would never have been what it is without the extraordinary efforts put into it by its editor Peter Naur. We are now fortunate to have an account by its editor of how it all grew and took shape. Naur does not tell the whole story: he was not involved in the ALGOL committee until early 1959. It is actually only one year that he recounts in detail. But that year was a very important one, and Naur's editorship of the ALGOL Bulletin makes him very well informed. One can follow how during this year ALGOL 60 took shape. One can also see how the most important concepts (blocks and procedures) involved last-moment decisions, or even decisions made after the final committee meeting (recursion by, to quote Bauer, "the Amsterdam plot"). The fact that Naur was one of the participants in the history he narrates, makes the paper subjective. How subjective is very clear from some of the other committee members's reactions, both in the appendices (Bauer and Samelson) and in the transcripts of the questions posed at the conference (McCarthy). The actual history recounted makes the paper very interesting. The different interpretations of this history, as revealed through the reactions, make the paper fascinating to read. in ACM Computing Reviews March 1982 view details The formal paper is followed by the more informal transcripts of both the author's paper and that of Peter Naur on the European side of ALGOL, which include several summary tables, fragments of ALGOL programs, and about a dozen photographs, mostly taken at ALGOL meetings. These are followed by a transcript of the question and answer session and brief biographies of Perlis and Naur. A brief summary of the language appears in Appendix A of the text. Those readers who like pithy quotations will like Perlis' statement that " [ programs ] are articles of commerce in a society of users and machines" and that of an unnamed computer scientist in the language summary that "ALGOL was indeed an achievement: it was a significant advance over most of its successors." ALGOL is one of the most important programming languages because of its wide use, its influence on the design of other languages, and the stimulus it gave to the formal definition of languages. Alan Perlis has written a worthy account of one aspect of its history. His polished style and quiet humor have added immeasurably to the content of his paper. in ACM Computing Reviews March 1982 view details in TOPLAS 6(4) October 1984 Lecture Notes in computer science Vol. 174 view details Introduction In the late 40s and early 50s, there were a few groups in the USA, in England, in Continental Europe and other countries that started to construct computers. To be precise they constructed the computer hardware. The computing machine in the modern sense had to replace desk calculators which were slow, had limited capabilities and lacked automatic performance of complex tasks. In 1936, Alan Turing described the functioning of a computer in a theoretical way with the aim to create a sound basis for a definition of the concept of computable numbers. Turing's computer of 1936 would have been terribly slow if it had been constructed. However, Turing did not construct it at that time. Then Konrad Zuse, John Presper Eckert and John W. Mauchly and a few others constructed computer hardware with relays or even with vacuum tubes and they had to master immense difficulties of engineering nature. Their products were often clumsy since the main problem of the hardware designers was to make their machines function in the first place. Furthermore, they had to make compromises with respect to available technologies. Zuse's first outlines around 1934 ("Vom Formular zur Programmsteuerung") showed for example a machine that used non-erasable storage and thus was much closer to functional programming than his later designs. However, he had to give up this approach and came to the solution of using erasable storage with appropriate writing and reading mechanisms. Extract: How did software arise? Heinz Zemanek has put it this way: "Software started with the translation of algebraic formulas into machine code." Thus, the Plankalkul of Konrad Zuse in 1945, the Formelubersetzung of Heinz Rutishauser and of Corrado Bohm in 1951, the Algebraic interpreter of Alick E. Glennie in 1953, the Programming Program of E. Z. Ljubimskii and Sergej Sergeevich Kamynin in 1954 and of Andrei Ershov in 1955 stood at the beginning of software, soon followed by Remington-Rand's Math-Matic (1955) and IBM's Fortran (1956). All these advances were made before the word 'software' came into wider use in 1960, 1961 or 1962. Now I will describe how we started to construct software in Munich and Zurich in the 50s, we being Klaus Samelson (1918-1980), Heinz Schecher (1922-1984) and myself in Munich and Heinz Rutishauser (1919-1970) in Zurich. Extract: Early Work in Munich and Zurich Early Work in Munich and Zurich In Munich, we were part of a group, under the supervision of the engineer Hans Piloty and the mathematician Robert Sauer, that constructed a computer. Our specific task was, to see to it that the computer under construction could perlorm the calculations it was intended for. Our group started in 1952, well-informed about the von Neumann report. Our first challenge was the ESDAC book of Wilkes-Wheeler-Gill, published in 1951. We learned from this book that we had to develop tools to make the programming job easier and more reliable. Only as a first step we decided to consider the subroutine technique advocated by Maurice V. Wilkes. We also were aware of Rutishauser's publication 'Uber automatische Rechenplanfertigung bei programmgesteuerten Rechenanlageri in ZAMM 1951, where the idea to use the computer in order to write its own program was exemplified. For this reason first personal contact to Rutishauser was established in November 1952. Apart from our daily work of fabricating subroutines for Sauer and checking the engineers' design, we started modestly to think about such simple tools as a supervisory program, while Rutishauser wrote a program for his relay computer Z4 performing the automatic generation for his relay of a linear sequence of machine instructions from a loop. In accordance with Rutishauser, we were convinced that 'automatic programming' was the direction we had to follow. Rutishauser knew that he could not use the Z4 for the realization of his 1951 ideas. Piloty's PERM in Munich was slightly ahead in time compared to Speiser's ERMETH in Zurich, so we aimed at constructing a practicable tool for 'automatic programming' as soon as our Munich machine was ready; in the meantime we followed closely the development in 'automatic programming' in the USA and in other countries, but we were not satisfied with the idea of constructing a 'compiler' that simply piled up prefabricated subroutines. Under the influence of Wilhelm Britzelmayr, our logic professor in Munich, we became more linguistically-oriented (when FORTRAN appeared in 1956, we were dissatisfied). Nevertheless, we now knew that we had to look for a better solution. We had several ideas how to achieve this aim. The PERM machine was ready for tests in 1955 (it was completely usable in 1956), so we could actually proceed. Extract: The Kellerprinzip The Kellerprinzip In 1955, when STANISLAUS was under construction, Samelson and I discussed how we would proceed with translating arithmetical formulas into machine code and suddenly we came to the conclusion that besides the 'Zahlkeller', that was used in Polish notation to postpone the intermediate results, we had to use an 'Op-I'l'alioiiskcllcr' in a similar way for postponing operations when dealing with pa-renlheses or implicit precedence. Soon, we found out that the functional principle we had discovered (we called it Kellerprinzip) "postpone operations that you can not yet evaluate and evaluate Iliem as soon as possible" was not only suitable for the evaluation or translation of parenthesized formulas, but for any constructs that show a parenthesized, interlocked structure.' Samelson in particular used the Kellerprinzip to make storage allocation efficient and when we designed step by step the programming language that we wauled lo use for 'automatic programming,' we structured the language accordingly. It became known as Chomsky-2-language. Rutishauser in particular showed how to use the Kellerprinzip in parameter transfer, bringing the spirit of the Lambda notation of formal logic into programming. Our efforts finally led in 1958 to ALGOL and made ALGOL a well-structured, very safe programming language. As usual, when freed from the restrictions hardware implies, more elegant, more flexible, more versatile solutions can be obtained. in "History of computing: software issues" Hashagen, Ulf; Keil-Slawik, Reinhard; Norberg, Arthur L. eds Proceedings of the international conference on History of computing: software issues 2002, Paderborn, Germany April 05 - 07, 2000 Springer 2002 view details Britzlmayr and Angstl The idea of what I later called the stack principle came into my mind before I became seriously acquainted with what was dubbed program-controlled calculators at that time. In the academic year 1948-1949 I was sitting in a class of Wilhelm Britzlmayr's, logician and honorary professor at the Ludwig-Maximilians-Universitat in Munich (his regular occupation was director of a bank). One day he spoke on the syntactic aspects (but this terminology was not used at that time) of the parentheses-free notation that was advocated by Jan Lukasiewicz [1]. Something stirred my interest, and thus I was not completely lost when on June 27, 1949 in Britzlmayr's seminar a man by the name of Kon-rad Zuse, while giving a survey of his Plankalkul [4], used the checking of the well-formedness of a propositional formula written in parentheses-free notation as an example for a Plankalkul program (a Rechenplan, as he called it). The discussion between Zuse and Britzlmayr brought to light that it was an algorithm Zuse had learned from his colleague Hans Lohmeyer, a mathematician working, like Zuse, at Henschel-Flugzeug-Werke in Berlin. The algorithm originated in 1943 from the Berlin logician Karl Schroter [3], based on the 1938 work by the Viennese logician Karl Menger [2]. While Zuse wanted to sell his Plankalkul, Britzlmayr was interested only in the algorithm as such, and most of the discussion took place in two different jargons, which was rather confusing. Extract: Influence by Shannon I did not like [Angstl's] solution with the wooden apparatus, and influenced by the 1949 paper by Claude Shannon [6], The Synthesis of Two-Terminal Switching Circuits, I started to look for a relay realization for the formula, which was to be typed in directly. At the same time, this allowed a direct evaluation of the propositional formula for true or false instantiations of the variables; the test for well-formedness turned out to be a byproduct of such a formula-programmed relay calculator for parentheses-free propositional formulas. Around the turn of the year 1950/51, during a stay in Davos, Switzerland, I made the wiring diagram for the relay calculator; in honor of the Polish school of logic I dubbed it STANISLAUS Extract: sequential formula translation A Software Patent for the Stack The Stack Principle In 1955, Samelson and I had quite a different motivation with respect to the STANISLAUS design. In February 1952, I had visited Heinz Rutis-hauser in Zurich and had seen the Z4 working; since the fall of 1953, I had had close contact with him, mainly in questions of numerical mathematics, which was my main duty under Sauer and also the field where I hoped to obtain my habilitation. Naturally, I did not neglect to take notice of Rutishauser's germinative publication [9] [10] of 1951, Uber automatische Rechenplanfertigung bei programmgesteuerten Rechen-maschinen, dealing for the first time with the translation of a mathematical formula language into machine programs by a Superplan in Rutishauser's terminology, a "programming program", as Andrei Ershov called it later. Samelson and I both had in mind to realize this Formel-ubersetzung for the PERM. When in mid-1955 we had time to start it and could expect a speedy finish to the construction of the PERM, it soon came to our attention that STANISLAUS solved a similar, but simplified task. Its "cellar" contained stored intermediate yes-no values; in the case of arithmetic formulas this would be a "number cellar". [...] The translation algorithm turns out to be superior to Rutishauser's method [9] inasmuch as it avoids the Rutishauser Springprozession; the effort is only proportional to the length of the formula and not, as with Rutishauser, to the square of the length. In Rutishauser's terminology it amounts to the decomposition of the parenthesis mountain from the first pair of peaks in the first chain of peaks, so it was sequential. Correspondingly, in the publication the method was characterized as "sequential formula translation". Extract: Recursion and the cellar principle Hardware Stacks We gave a report on our results to Sauer and Piloty. Piloty remarked that the German Research Council (Deutsche Forschungsgemeinschaft) had a tendency to make sure that patents were obtained for the projects it supported; he urged us to examine whether this would be possible in our case. We agreed, and he offered the prospect of providing the successor machine of the PERM with a number cellar and operation cellar in hardware. This must have been in the summer or fall of 1955. For the patent application we had to disguise our method as hardware, and for this purpose had to become engineers. The elaboration of the patent application therefore brought a lot of work and was fun, too; on the other hand it meant that publication of our results was paralyzed. Samelson therefore reported at the Dresden meeting at the end of November 1955 [13] with great caution. Both Rutishauser and Heinz Billing in Gottingen, who was building the G3 computer, were in on the secret The German patent application [14, in the following partly reprinted] was finally filed March 30, 1957 (Auslegeschrift 109472019, Kl.42m), the U.S.-American one [15] March 28, 1958 within the priority time limit. A Software Patent for the Stack While the U.S.-American application contained an abundance of and and or gates, the German patent law allowed quite functional descriptions of methods, thus the German application stayed free of drawings for electrical circuits; it was possible to design from it immediately a program with programmed cellar structures, later called stacks. Our patent can therefore be considered as an early case of a software patent The actual writing of a machine program for the PERM, which in the meantime was operating, was delegated in mid-1957 to the assistants Manfred Paul and Peter Graeff; the program was ready for tests after a few months. At first, an interpreting machine program was written; then the transition to a generating translator (a compiler) meant simply, instead of immediately executing say (as above) inserting into the program the corresponding instruction The hardware stacks, the building of which Piloty had suggested, were not realized in Munich, since the PERM II project was not supported by the German Research Council. Billing, however, equipped his G3 computer with the hardware for a number stack. thus particularly well suited for efficient translation, which was a main concern of the impoverished European side. In Zurich, Samelson had particularly stressed the point that the block structure of storage allocation (Cellar Principle of State Transition and Storage Allocation, [30]), following so naturally from the cellar principle and becoming so typical in the later development, became the dominant organization principle of the programming language. Storage allocation with complete parentheses structure should be organized in a dynamic stack, which without further complications allowed mastery of recursive definitions. The compromise that was achieved in a struggle with the U.S.-American side did not reflect this issue in the published report; thus, later the implementation of recursive situations was reinvented by some people not present at the Zurich meeting. Extract: arrival of Algol The Preliminary ALGOL Report The goals attempted by the ZMD group, to create a language widely following mathematical notation, readable without much ado, and suitable for publications and for mechanical translation, had been largely reached. The publication was completed in 1959 in the first issue of the new journal Numerische Mathematik of Springer-Verlag under the title Report on the Algorithmic Language ALGOL Extract: Mainz 22 and algol 58 When in 1958 I moved from Munich to Mainz, with Samelson soon following me, the ZMD group was widened to the ZMMD group. Emphasis was on finishing compilers for ALGOL 58. The common basis was the method of a stack automaton developed in Munich, which was extended without any difficulty to a full algorithmic language including statements, declarations, block structure, indexed variables, and so on. It was published in 1959 in the newly founded journal Elektronische Rechenanlagen [..] and in 1960 in Communications of the ACM [...]. Manfred Paul, who had done most of the preparatory work, finished a compiler for the Mainz Z22 towards the end of 1958. Soon afterwards, H.R.Schwarz and P.Lauchli followed in Zurich for the ERMETH and G.SeegmuIler in Munich for the PERM. Extract: ICIP, BNF, stack notation ICIP Conference A lot of work was caused by the preparations for ALGOL 60. At the International Conference on Information Processing (ICIP), arranged in Paris, |une 15-20, 1959 by UNESCO, John Backus [24] made a famous proposal for the formal description of the syntax. The Backus notation (Backus Normal Form), soon generally accepted, allowed one to attach in an elegant way the semantics of the programming language to the syntax of a context-free language. Manfred Paul, in his 1962 dissertation, clarified how from this description the transition matrix for the stack automaton could be derived formally. Extract: British hostility and absence, ZMD excellence The Zurich Meeting In the summer of 1957, Bottenbruch became initiated in the Munich Sequential Formula Translator method [16], and at the Zurich meeting the ZMD group not only presented a draft [17] for the language, which at first was called International Algebraic Language, but also had a completed compiler design in the bag. Some U.S.-American delegates had experience with working compilers (Backus with FORTRAN, Perlis with IT, Katz with MATH-MATIC). An open discussion of the technical problems of programming language translation into machine code was left out, as there would not have been enough time. Technically speaking, the state of the art within the ZMD group was far more advanced: FORTRAN used the method of parentheses completion, introduced by P.B.Sheridan [18] and discussed as early as 1952 by Corrado Boehm [11] in his Zurich dissertation, a method that like Rutishauser's required an effort proportional to n2; IT [12] used pure comparison of neighboring operators, enforcing an oppressive limitation to operator precedence grammars. This situation led from time to time to a paralysis of the discussion, which was basically oriented towards progress. On the whole, ALGOL, as it was called in the publication [19b], was an incarnation of the cellar principle […] Christopher Strachey, who—inadvertently—had not been invited to the Zurich meeting, went into the trouble of criticizing ALGOL 58 and produced not only considerable stir, but also a lot of public attention. Thus, it was not too difficult to convince the International Federation for Information Processing, founded in Paris, to organize a conference for the "final ALGOL", later called ALGOL 60. The preparations were this time much more intensive; a European pre-conference was held in November 1959 in Paris; it nominated seven European delegates, who met again in December 1959 in Mainz. The U.S.-American side nominated its delegates in November 1959. This time, representatives from Great Britain, France, the Netherlands, and Denmark, besides representatives from the U.S.A., Germany, and Switzerland, were invited. Extract: Paris Conference Paris, 1960 The ALGOL conference took place in Paris, January 11-16, 1960 under the patronage of the newly founded IFIP. It led to consolidations and completions of the Preliminary Report. Characteristically, the introduction to the report [25a, b] says "The present report represents the union of the committee's concepts and the intersection of its agreements". In this way, contradictions could remain here and there and solutions were omitted. What made me particularly angry was that Samelson, who in 1958 regarding the question of the block structure could not win against Alan Perlis, in 1960, when acceptance of recursion was no longer an issue, was given no credit for the block structure; the editor Peter Naur, who was not present in Zurich, was not aware of this. In the short period of six days we also did not succeed in formalizing, next to the syntax which now was formalized in BNF (Backus Normal Form), the semantics as well; it was still explained rather verbally, leading later to exegetic quarrels. Heinz Zemanek tried, with the IFIP Technical Committee 2 Working Conference Formal Language Description Language, held in 1964 in Baden near Vienna, to compensate for this lack. Peter Landin [29] gave a complete formal description of ALGOL 60, but it lacked the blessing of the authorities. Extract: The ALCOR Group The ALCOR Group After the ICIP Congress, June 1959 in Paris and particularly after the publication of the ALGOL 60 report, the ZMMD group decided to widen its membership and invited interested institutions in Europe and North America to participate in the efforts for propagation of ALGOL through the construction of ALGOL compilers for various different machine configurations; the documents of the previous ZMMD group were made available for this purpose. The offer was accepted by scientific institutions (among the first were Regnecentralen Copenhagen, Bonn University, Zemanek's Mailiifterl group in Vienna, Oak Ridge National Laboratory, Neber Laboratory Leidschendam) as well as by some computer companies (Siemens and Halske AG for the 2002, Telefunken for the TR4, Standard Elektrik Lorenz AG, IBM Germany). The resulting multitude of concrete implementations was unavoidable because of the differences in the machines involved, but it was useful in its scientific aspects. For example, Albert A. Grau, Oak Ridge, introduced the concept of syntactic states and described the compiler as a system of mutually recursive subprograms [31]. Peter Lucas in Vienna went his own way [32] in generating, like Paul in Mainz [33,34], the compiler from the syntax in BNF. Jurgen Eickel and Manfred Paul, in 1964, studied the parsing and ambiguity problem for Chomsky languages in general [39]. Extract: Algol 58 and the death of Algol After my return to Munich in 1963, the build-up of computer science there became my main obligation, leaving less time to be spent on the further development of ALGOL. The way it went became more and more of a nightmare, leading to ALGOL 68 and to the ruin of the ALGOL idea. One after another, people left the IFIP Working Group 2.1 on ALGOL: Peter Naur, Niklaus Wirth, Tony Hoare, Edsger Dijkstra, Brian Randall, Gerhard Seegmiiller, Wlad Turski, Mike Woodger, Hans Bekic, and Fraser Duncan. in Software Pioneers: Contributions to Software Engineering, Bonn, 28-29. 6. 2001 eds Broy, Manfred and Denert, Ernst Springer 2002 view details Rutishauser gave a seminal lecture entitled ”Automatische Rechenplanfertigung bei programmgesteuerten Rechenmaschinen“ at the GaMM meeting in Freiburg in Breisgau, at the end of March, 1951, which I missed—I was still assistent of Fritz Bopp, the University of Munich Theoretical Physicist, successor of the famous Arnold Sommerfeld. I became aware of the lecture when it was published mid-1952 as an ETH-Mitteilung. Therefore, when I met Heinz Rutishauser in February 1952 for the first time, I was absolutely ignorant about his success, and we did not talk about the subject. It just happens that we met on February 19, 1952; tomorrow it will be 50 years ago. Extract: Rutishauser’s way to Stiefel Rutishauser's way to Stiefel When Rutishauser'started his academic studies, he could not yet knowthat it would lead him to computers. Born on January 30, 1918, son of the headmaster of the thurgauische Kantonsschule in Frauenfeld, he lost his father in 1931 and his mother in 1934. Heinz Rutishauser and his younger brother and sister found a new home at the house of their uncle. In 1936, Heinz earned his Matura and was (I quote from the curriculum vitae) "befahigt zum Studium an der ETH, das er, mit Unterbrechungen durchWehrdienst bei der Festungsartillerie im Gotthardgebiet, 1942 mit dem Diplom alsMathematiker abschloß". Subsequently, he was for three years assistent of professor Walter Saxer at the ETH. During this time, he also acquired the doctors degree with a dissertation "summa cum laude" in the field of the theory of complex functions. After the end of the war, Rutishauser became a mathematics teacher at the gymnasiums in Glarisegg and in Trogen; in 1948 he became, together with Ambros Speiser, an assistent at the newly founded "Institut fur angewandte Mathematik" of the ETH. Thus, he entered the sphere of influence of Eduard Stiefel, a topologist who had before the war written a sensational paper on homology classes and had a high reputation, but now had changed his field. Following his stay in the United States, Rutishauser aimed for "Habilitation". This led to the already mentioned work on "Automatische Rechenplanfertigung" that followed the vague traces of Zuse's Plankalkul, but was concrete and, compared with the "Programmator" of Zuse (published in 1952), more realistic. Extract: Stanislaus, Klammerausdrücke, ALGOL STANISLAUS, a Formula-programmed Relay Calculator and Rutishauser's "Automatische Rechenplanfertigung" My interest in Rutishauser's "Automatischer Rechenplanfertigung" was established by my little relay calculator for formulas of propositional logic in Polish (parenthesis-free) notation, which I had baptized with the name of the Polish saint STANISLAUS. Under the influence of the 1949 paper by Claude Shannon, The synthesis of Two-Terminal Switching Circuits, I had started to look for a relay realization of a device for evaluating a well-formed formula, which was to be typed in directly. This allowed a direct evaluation of a propositional formula for instantiations of the variables by "true" or "false"; the test for well-formedness turned out to be a byproduct of such a "formula-programmed relay calculator for parentheses-free propositional formulas". Around the turn of the year 1950/51, during a stay in Davos, in Switzerland, I made the wiring diagram for the relay calculator. Then I started to collect material for the construction of the device. In October 1951 I entered into a consulting contract with the Siemens company in Munich; now from time to time I could help myself from the surplus bin of the Siemens & Halske AG Central Laboratory in the Munich Hoffmannstraße, where relays and keyboards were to be found. Again and again, my former Munich logic professor Britzlmayr urged me to start with the actual construction, but I had too many other obligations. It was only in 1954 that I started, under the attentive eyes of my colleague and friend Klaus Samelson and helped by Heinz Schecher, to wire the first segments. Then, after having seen how it would work, my interest waned, and it was only after very urgent admonition from Britzlmayr that in 1956 STANISLAUS was finished. It was shown on December 3, 1956 at a colloquium in Munster and presented on January 8, 1957 to the Munich academic public; it met with the delight of Britzlmayr. Samelson and myself did not think so highly of the apparatus: in the meantime we had greater joy with the PERM computer. STANISLAUS is now exhibited in the Deutsches Museum, Munich. Rutishauser's seminal Habilitationsschrift of 1951 gave the evidence that the "Automatische Rechenplanfertigung" for a given, sufficiently flexible computing machine could be carried through with just the same machine (Andrei Ershov coined for this the expression "programming program"). Rutishauser had no chance to do it immediately on the Z4. However, progress in building the PERMinMunich was such that we could start in 1955 programming a "formula translator", based on the so-called "cellar principle" of my Formelrechner STANISLAUS. This translation method was an essential improvement over the Rutishauser method of 1951, as it was much faster. Moreover, external circumstances had the effect that I filed in March 1957 jointly with Klaus Samelson a patent application for a formula-controlled computer with hardware realizing the cellar principle. Rutishauser, on the other hand, with the experience he had already made on the Z4, programmed a run-time organization for the ERMETH, in particular the treatment of subroutine returns - a "last in, first out"-type organisation, i.e. the cellar principle applied to program structure. (Fortunately, the German Patent Office did not find out about this, which even could have been traced back to Turing and van der Poel.) The ERMETH, by the way, was ready about one year after the PERM. Hence, it was natural that Rutishauser, Samelson (who extended the cellar principle to storage allocation) and I did intensify more and more our cooperation in the area of what became called compiler-building. This had the consequence that we were forced to agree on language constructs, and again the lead of four years in practical programming Rutishauser had, thanks to the Z4, was his great asset. Rutishauser's reputation also had the effect that his appeal at theGaMM-meeting in 1955 to create a common programming language found the support of the GaMM president; within the "Fachausschuss Programmieren" a working group with Zurich, Munich and later Mainz members was established that pushed the language creation. Rutishauser was not less active than Samelson and myself: the first larger working meeting of the group that meanwhile called itself ZMD-Gruppe (D for Darmstadt: Hermann Bottenbruch) took place in autumn 1957 in Lugano, organized by Rutishauser. At that meeting it was decided, in the name and with the approval of the GaMM, to approach the US-american ACM and the British Computer Society with the proposal of a joint conference for the creation of an internationally-based programming language for scientific computation. Unfortunately, the BCS did not react; the ACM, however, under its president John Carr III was cheerful and it came to a one-week ACM-GaMM conference in May 1958 at the ETH Zurich, thanks to the support Eduard Stiefel had given. While the English working title was IAL (International Algebraic Language), the name Algorithmic Language ALGOL was already chosen in the publication, edited by A. J. Perlis and K. Samelson, in the newly founded Springer journal "Numerische Mathematik", Vol 1 (1959). The further course of development of ALGOL saw Heinz Rutishauser also taking part in the conference held January 11-16, 1960 with thirteen experts from the USA, Germany, Switzerland, Netherlands, England, Danmark, and France in Paris. It produced ALGOL 60, a milestone. Rutishauser's share was more than a thirteenth. Extract: Algol 60 and 68 With ALGOL 60, the 60's had opened, the Golden Years of Programming had gone. Rutishauser took part in the further developments within the frame of the IFIP Working Group 2.1 ALGOL; however because of his health no longer with full activity. In particular, he did not dare to travel by airplane to the USA. He also disliked (like Samelson and myself) several faux pas that occured mainly in the attempts to create ALGOL 68. The fiasco of ALGOL 68 is to be blamed on others. Rutishauser prefered to concentrate on the description of standardized numerical algorithms in ALGOL 60; this led to a good part later to the LINPACK and EISPACK collection. He also wrote Volume I, Part A "Description of ALGOL 60" of the Handbook for Automatic Computation" published by Springer, that contained many representative examples of algorithms. in Latsis Symposium 2002 on the 50th Anniversary of the Conjugate Gradient Algorithm view details MAD was developed at the University of Michigan in 195960 for the IBM 704. It was very widely used on the IBM 7090 and 7094, the Philco 2000, and UNIVAC 1100 computers during the 1960s for the purpose of teaching programming to college students. Michigan published a reference manual, but most students learned MAD from the MAD PRIMER, written by Elliott Organick of the University of Houston and distributed by Ulrichs Book Store of Ann Arbor, Michigan. Organick also wrote a more widely used FORTRAN PRIMER. The MAD compiler for the UNIVAC 1100 computers called RALPH was developed at the University of Maryland. The name RALPH is an acronym of sorts: Reentrant Algorithmic Language Processor with H just for the H of it. (The explanation of the acronym is supplied by George Baltz, formerly at the University of Maryland.) The RALPH processor could compile either FORTRAN or MAD, depending on the option selected. MAD is perhaps most famous for the line printer picture of Alfred E. Neumann which was printed when an attempted compilation had too many errors. Underneath the picture it printed the caption: See this man about your program--He might want to publish it. He never worries--but from the looks of your program, you should. MAD faded from the scene in the 1970s. A very simple MAD program follows: INTEGER A START A = 1 WHENEVER A .G. 0 PRINT COMMENT $ A GTR 0$ OTHERWISE PRINT COMMENT $A LEQ 0$ END OF CONDITIONAL PRINT COMMENT $ END $ END OF PROGRAM The WHENEVER OTHERWISE END OF CONDITIONAL is equivalent to an if-else statement External link: Online copy at UNISIS History in Latsis Symposium 2002 on the 50th Anniversary of the Conjugate Gradient Algorithm view details in Latsis Symposium 2002 on the 50th Anniversary of the Conjugate Gradient Algorithm view details Resources
|