PL/I(ID:185/pli001)Programming Language Onefor Programming Language One George Radin, 1964. Originally named NPL. An attempt to combine the best features of FORTRAN, COBOL and ALGOL 60. Result is large but elegant. One of the first languages to have a formal semantic definition, using the Vienna Definition Language. EPL, a dialect of PL/I, was used to write almost all of the Multics OS. PL/I has no reserved words. Types are fixed, float, complex, character strings with max length, bit strings, and label variables, no user-defined types. Dynamic arrays. Summation, multi-level structures, structure assignment. Untyped pointers, side effects, aliasing. Control flow goto, do-end groups, do-to-by-while-end loops, external procedures, nested procedures and blocks. Procedures may be declared recursive, or grouped into generic families. Controlled variables. Many implementations support concurrency ('call task' and 'wait(event)' amount to fork/join) and compile-time statements. Exception handling. Blocks have localised "undo" capabilities because of the revert command PL/I is still widely used, at IBM and elsewhere. The CFS file system used at Argonne to manage terabytes of data is written in PL/I. Used for implementing the System/A experimental Language at Watson Labs in 1971 general-purpose, used for solving problems in a variety of fields such as commerce, science (including mathematics, physics, chemistry), engineering (civil, electrical, aeronautics), medicine, and so on. It can also be used for system programming, and the facilities are such that it is rarely, if ever, to resort to machine-language or high-level programming to solve problems. The language of MULTICS, but not (as is sometimes said) its downfall. Structures: Significant use: Related languages
References: in [ACM] Proceedings of the 1965 20th National Conference 1965 , Cleveland, Ohio, United States view details The primary aim of the designers was clearly comprehensiveness. Within one language system, all possible applications were to be provided for, and yet no user was to suffer inconvenience by the claims and rights of others. The language w as to be machine- independent (though only, as the author is careful to add, "relatively"), and yet the programmer u as to be given 'full access to the machine." By means of a set of conventions called "default Options" the compiler would supply information omitted, inadvertently or deliberately, by the programmer; "reasonable meanings" would be attached "to as many combinations of symbols as possible." The account of the features of PI,/I is too short to indicate how far the language can fulfill its objectives. Very little, if anything, is mentioned which has not already appeared in a description of some earlier language; power and range have been achieved by bringing together features of a number of existing systems. The discussion of implementation is based very firmly on established traditional techniques and attitudes. There is no evidence of any radical approach, either to language design or to operation, and no concession to economy of structure. A full PL/I system will evidently be a massive and formidable thing. Whether it can support its own weight remains to be seen. PL/I must surely mark the end of tradition -- the time is already ripe for the whole question of the accessibility of computing power (which is what programming languages and operating systems are about) to be reconsidered from first principles. in ACM Computing Reviews 7(04) July-August 1966 view details in ACM Computing Reviews 7(04) July-August 1966 view details in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967. view details in Computers & Automation 16(6) June 1967 view details The family tree of programming languages, like those of humans, is quite different from the tree with leaves from which the name derives. That is, branches grow together as well as divide, and can even join with branches from other trees. Similarly, the really vital requirements for mating are few. PL/I is an offspring of a type long awaited; that is, a deliberate result of the marriage between scientific and commercial languages. The schism between these two facets of computing has been a persistent one. It has prevailed longer in software than in hardware, although even here the joining was difficult. For example, the CPC (card-programmed calculator) was provided either with a general purpose floating point arithmetic board or with a board wired specifically to do a (usually) commercial operation. The decimal 650 was partitioned to be either a scientific or commercial installation; very few were mixed. A machine at Lockheed Missiles and Space Company, number 3, was the first to be obtained for scientific work. Again, the methods of use for scientific work were then completely different from those for commercial work, as the proliferation of interpretive languages showed. Some IBM personnel attempted to heal this breach in 1957. Dr. Charles DeCarlo set up opposing benchmark teams to champion the 704 and 705, possibly to find out whether a binary or decimal machine was more suited to mixed scientific and commercial work. The winner led to the 709, which was then touted for both fields in the advertisements, although the scales might have tipped the other way if personnel assigned to the data processing side had not exposed the file structure tricks which gave the 705 the first edge. Similarly fitted, the 704 pulled ahead. It could be useful to delineate the gross structure of this family tree for programming languages, limited to those for compilers (as opposed to interpreters, for example). On the scientific side, the major chronology for operational dates goes like this: 1951, 52 Rutishauser language for the Zuse Z4 computer 1952 A0 compiler for Univac I (not fully formula) 1953 A2 compiler to replace A0 1954 Release of Laning and Zierler algebraic compiler for Whirlwind 1957 Fortran I (704) 1957 Fortransit (650) 1957 AT3 compiler for Univac II (later called Math-Matic) 1958 Fortran II (704) 1959 Fortran II (709) A fuller chronology is given in the Communications of the ACM, 1963 May, 94-99. IBM personnel worked in two directions: one to deriving Fortran II, with its ability to call previously compiled subroutines, the other to Xtran in order to generalize the structure and remove restrictions. This and other work led to Algol 58 and Algol 60. Algol X will probably metamorphose into Algol 68 in the early part of that year, and Algol Y stands in the wings. Meanwhile Fortran II turned into Fortran IV in 1962, with some regularizing of features and additions, such as Boolean arithmetic. The corresponding chronology for the commercial side is: 1956 B-0, counterpart of A-0 and A-2, growing into 1958 Flowmatic 1960 AIMACO, Air Material Command version of Flowmatic 1960 Commercial Translator 1961 Fact Originally, I wanted Commercial Translator to contain set operators as the primary verbs (match, delete, merge, copy, first occurrence of, etc.), but it was too much for that time. Bosak at SDC is now making a similar development. So we listened to Roy Goldfinger and settled for a language of the Flowmatic type. Dr. Hopper had introduced the concept of data division; we added environment division and logical multipliers, among other things, and also made an unsuccessful attempt to free the language of limitations due to the 80-column card. As the computer world knows, this work led to the CODASYL committee and Cobol, the first version of which was supposed to be done by the Short Range Committee by 1959 September. There the matter stood, with two different and widely used languages, although they had many functions in common, such as arithmetic. Both underwent extensive standardization processes. Many arguments raged, and the proponents of "add A to B giving C" met head on with those favoring "C = A + B". Many on the Chautauqua computer circuit of that time made a good living out of just this, trivial though it is. Many people predicted and hoped for a merger of such languages, but it seemed a long time in coming. PL/I was actually more an outgrowth of Fortran, via SHARE, the IBM user group historically aligned to scientific computing. The first name applied was in fact Fortran VI, following 10 major changes proposed for Fortran IV. It started with a joint meeting on Programming Objectives on 1963 July 1, 2, attended by IBM and SHARE Representatives. Datamation magazine has told the story very well. The first description was that of D. D. McCracken in the 1964 July issue, recounting how IBM and SHARE had agreed to a joint development at SHARE XXII in 1963 September. A so-called "3 x 3" committee (really the SHARE Advanced Language Development Committee) was formed of 3 users and 3 IBMers. McCracken claimed that, although not previously associated with language developments, they had many years of application and compiler-writing experience, I recall that one of them couldn't tell me from a Spanish-speaking citizen at the Tijuana bullring. Developments were apparently kept under wraps. The first external report was released on 1964 March 1. The first mention occurs in the SHARE Secretary Distribution of 1964 April 15. Datamation reported for that month: "That new programming language which came out of a six-man IBM/ SHARE committee and announced at the recent SHARE meeting seems to have been less than a resounding success. Called variously 'Sundial' (changes every minute), Foalbol (combines Fortran, Algol and Cobol), Fortran VI, the new language is said to contain everything but the kitchen sink... is supposed to solve the problems of scientific, business, command and control users... you name it. It was probably developed as the language for IBM's new product line. "One reviewer described it as 'a professional programmer's language developed by people who haven't seen an applied program for five years. I'd love to use it, but I run an open shop. Several hundred jobs a day keep me from being too academic. 'The language was described as too far from Fortran IV to be teachable, too close to be new. Evidently sharing some of these doubts, SHARE reportedly sent the language back to IBM with the recommendation that it be implemented tested... 'and then we'll see. '" In the same issue, the editorial advised us "If IBM announces and implements a new language - for its whole family... one which is widely used by the IBM customer, a de facto standard is created.? The Letters to the Editor for the May issue contained this one: "Regarding your story on the IBM/SHARE committee - on March 6 the SHARE Executive Board by unanimous resolution advised IBM as follows: "The Executive Board has reported to the SHARE body that we look forward to the early development of a language embodying the needs that SHARE members have requested over the past 3 1/2 years. We urge IBM to proceed with early implementation of such a language, using as a basis the report of the SHARE Advanced Language Committee. " It is interesting to note that this development followed very closely the resolution of the content of Fortran IV. This might indicate that the planned universality for System 360 had a considerable effect in promoting more universal language aims. The 1964 October issue of Datamation noted that: "IBM PUTS EGGS IN NPL BASKET "At the SHARE meeting in Philadelphia in August, IBM?s Fred Brooks, called the father of the 360, gave the word: IBM is committing itself to the New Programming Language. Dr. Brooks said that Cobol and Fortran compilers for the System/360 were being provided 'principally for use with existing programs. ' "In other words, IBM thinks that NPL is the language of the future. One source estimates that within five years most IBM customers will be using NPL in preference to Cobol and Fortran, primarily because of the advantages of having the combination of features (scientific, commercial, real-time, etc.) all in one language. "That IBM means business is clearly evident in the implementation plans. Language extensions in the Cobol and Fortran compilers were ruled out, with the exception of a few items like a sort verb and a report writer for Cobol, which after all, were more or less standard features of other Cobol. Further, announced plans are for only two versions of Cobol (16K, 64K) and two of Fortran (16K and 256K) but four of NPL (16K, 64K, 256K, plus an 8K card version). "IBM's position is that this emphasis is not coercion of its customers to accept NPL, but an estimate of what its customers will decide they want. The question is, how quickly will the users come to agree with IBM's judgment of what is good for them? " Of course the name continued to be a problem. SHARE was cautioned that the N in NPL should not be taken to mean "new"; "nameless" would be a better interpretation. IBM's change to PL/I sought to overcome this immodest interpretation. Extract: Definition and Maintenance Definition and Maintenance Once a language reaches usage beyond the powers of individual communication about it, there is a definite need for a definition and maintenance body. Cobol had the CODASYL committee, which is even now responsible for the language despite the existence of national and international standards bodies for programming languages. Fortran was more or less released by IBM to the mercies of the X3. 4 committee of the U. S. A. Standards Institute. Algol had only paper strength until responsibility was assigned to the International Federation for Information Processing, Technical Committee 2. 1. Even this is not sufficient without standard criteria for such languages, which are only now being adopted. There was a minor attempt to widen the scope of PL/I at SHARE XXIV meeting of 1965 March, when it was stated that X3. 4 would be asked to consider the language for standardization. Unfortunately it has not advanced very far on this road even in 1967 December. At the meeting just mentioned it was stated that, conforming to SHARE rules, only people from SHARE installations or IBM could be members of the project. Even the commercial users from another IBM user group (GUIDE) couldn't qualify. Another major problem was the original seeming insistence by IBM that the processor on the computer, rather than the manual, would be the final arbiter and definer of what the language really was. Someone had forgotten the crucial question, "The processor for which version of the 360? , " for these were written by different groups. The IBM Research Group in Vienna, under Dr. Zemanek, has now prepared a formal description of PL/I, even to semantic as well as syntactic definitions, which will aid immensely. However, the size of the volume required to contain this work is horrendous. In 1964 December, RCA said it would "implement NPL for its new series of computers when the language has been defined.? If it takes so many decades/centuries for a natural language to reach such an imperfect state that alternate reinforcing statements are often necessary, it should not be expected that an artificial language for computers, literal and presently incapable of understanding reinforcement, can be created in a short time scale. From initial statement of "This is it" we have now progressed to buttons worn at meetings such as "Would you believe PL/II?" and PL/I has gone through several discrete and major modifications. Extract: Introduction The family tree of programming languages, like those of humans, is quite different from the tree with leaves from which the name derives. That is, branches grow together as well as divide, and can even join with branches from other trees. Similarly, the really vital requirements for mating are few. PL/I is an offspring of a type long awaited; that is, a deliberate result of the marriage between scientific and commercial languages. The schism between these two facets of computing has been a persistent one. It has prevailed longer in software than in hardware, although even here the joining was difficult. For example, the CPC (card-programmed calculator) was provided either with a general purpose floating point arithmetic board or with a board wired specifically to do a (usually) commercial operation. The decimal 650 was partitioned to be either a scientific or commercial installation; very few were mixed. A machine at Lockheed Missiles and Space Company, number 3, was the first to be obtained for scientific work. Again, the methods of use for scientific work were then completely different from those for commercial work, as the proliferation of interpretive languages showed. Some IBM personnel attempted to heal this breach in 1957. Dr. Charles DeCarlo set up opposing benchmark teams to champion the 704 and 705, possibly to find out whether a binary or decimal machine was more suited to mixed scientific and commercial work. The winner led to the 709, which was then touted for both fields in the advertisements, although the scales might have tipped the other way if personnel assigned to the data processing side had not exposed the file structure tricks which gave the 705 the first edge. Similarly fitted, the 704 pulled ahead. It could be useful to delineate the gross structure of this family tree for programming languages, limited to those for compilers (as opposed to interpreters, for example). in PL/I Bulletin, Issue 6, March 1968 view details Extendible Compilers -- Basic Concepts Many attempts (starting with McIlroy [McI1 60]) have been made to embed macro features in compiler systems. One approach was to retain the macro syntax form but add a number of built-in features which are compiler-like. The SET system [Ben 64a] included a skeleton compiler with input-output, symbol manipulation, table handling, and list processing features. These built-in routines were combined with translation time operations (action operators) in the attempt to build a TWS. A more successful approach has been to use the structured syntax of high level languages as a basis for extension. Many existing compilers (including PL/I [IBM 66]) incorporate simple forms of macro expansion, the first probably being JOVIAL [Shaw 63]. The most primitive form is pure text replacement without parameter substitution. For example, in B5500 ALGOL one could define a macro with the statement: DEFINE LOOP 1 = FOR I ~ 1 STEP 1 UNTIL N and later write statements like LOOP 1 N DO A[I] ~ 0 which would be expanded into FOR I ~-- 1 STEP 1 UNTIL N DO A [I] ~-- 0. The next step is to allow a macro definition with parameters. This facility has been included in the AED-0 compiler [Ross 66], among others. In AED-0 one might define a macro with the statement: DEFINE MACRO LOOP (P1, P2) TOBE FOR P1 ~-- 1 STEP 1 UNTIL P2 DO ENDMACRO. In this case, one could get the same result as above with the shorter statement LOOP(I, N) A[I] ~-- O. These two simple macro forms would form a useful addition to any high level language, and one might imagine developing mechanisms which parallel more sophisticated macro techniques. Although AED-0 does permit arbitrary strings as parameters, and nested definitions, features like conditional assembly do not seem to have been widely used in high level languages. One reason for this is that compilers normally depend heavily on the structure of the text; the next two sections describe the complexities that arise in trying to extend compilers with macro techniques. in [ACM] CACM 11(02) (February 1968) view details Operating systems can be viewed as a very large number of very simple manipulations of a very complicated data structure. There are many tables of one kind or another in a system. Languages which have facilities for describing data structures like PL/I put us much closer to the problem because we can talk in terms of manipulating the entities in the table rather than shifting, masking, and extracting a certain field out of a word. In a PL/I program the structure of a table is described only once. All the details of the format, and how the data is going to be stored in memory are handled by the compiler. The user is unconcerned with them and unaware of them. He can think in terms of manipulating the entries in the table rather than pushing bits around. in [ACM] CACM 11(02) (February 1968) view details in [ACM] CACM 11(02) (February 1968) view details in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details This report summarizes all data collected in a survey of implementations of the PL/I language. An attempt was made to contact all people or groups known or rumored to be undertaking such a project. A fairly lengthy questionnaire was mailed out when a prospect was identified, beginning in August, 1967. The latest response was received in August, 1968. As is the case in most such efforts, it is likely that some projects were overlooked. In other instances, our attempts to contact people were met with no response at all, neither confirming nor denying the existence of the implementation involved. There were also a few cases in which one or more implementations did indeed exist; but their nature was proprietary and, therefore, the questionnaire was not completed. An in two cases, the individual contacted replied by stating that the supposed implementation had never existed. Only in the latter cases is the attempt at contact not included in the overall summary table. The data are summarized in four tables. The first contains the basic identification of all attempted contacts and the resulting response. The second table summarizes all questionnaires returned with respect to implementation data. The third and fourth tables relate responses to questions about the PL/I language and the dialect implemented. Responses from three questionnaires are excluded from these tables since, in the author's opinion, the dialects are more closely related to languages other than PL/I, itself. The third table summarizes restrictions found in the various dialects, while the fourth lists the extensions found in one or more dialects. This report suffers from the fact that the questions were somewhat general (e. g. , "Which features have you implemented in a manner at variance with C28-6571 -4? "), and the responses, therefore, reflect the interpretation imposed by the responder. An attempt has been made to normalize these aspects of the data, but it is clear that the result is far from ideal. in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details in [ACM] ACM Computing Surveys (CSUR) 2(1) January 1970 view details in [ACM] ACM Computing Surveys (CSUR) 2(1) January 1970 view details in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details The use of PL/I (in varying versions) for MULTICS at MIT is the outstanding example of the use of a higher level language for a large complex operating/time-sharing system on a machine with conventional (i. e. , not stack oriented) architecture. Its use is a complete refutation to people who say such a system can't or shouldn't be done that way, but also an illustration of the differences between evaluation of a language, evaluation of a particular implementation, and effectiveness of practical usage. PL/I was chosen because of the following advantages which were known or believed to exist at the time the selection was made in 1964: Modular object code, powerful data handling facilities, fairly machine independent, and potential wide support of the language. (This latter feature is the one which turned out to be the most invalid, but is gradually becoming true. ) in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.] in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details in [ACM] SIGPLAN Notices 6(10) October 1971 Proceedings of the SIGPLAN symposium on Languages for system implementation 1971, Lafayette, Indiana, United States; October, 1971 view details in [ACM] CACM 15(07) (July 1972) view details in Computers & Automation 21(6B), 30 Aug 1972 view details in [ACM SIGACT-SIGPLAN] Proceedings of the ACM Symposium on Principles of Programming Languages, Boston, October 1973. Association for Computing Machinery. view details in [ACM SIGACT-SIGPLAN] Proceedings of the ACM Symposium on Principles of Programming Languages, Boston, October 1973. Association for Computing Machinery. view details in ACM SIGPLAN Notices 8(5) May 1973 view details in ACM Computing Reviews 15(04) April 1974 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in ACM Computing Reviews 15(04) April 1974 view details in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details Introduction "Interactive PL/I" by M. Zelkowitz (1) describes two "deficiencies" in the PL/I language discovered while implementing an interactive compile and go PL/I system (PLUM) that operates under the EXEC8 time sharing system of the Univac 1108. The problems with stream output and the use of on units noted in that article are really defects in the operating system or the implementation. This note describes how the questions raised by Zelkowitz were handled in the implementation of the Multics PL/I compiler for the Honeywell 6180. Extract: Multics PL/I Multics PL/I Multics PL/I is a nearly complete implementation of the draft ANSI standard language. The first version of the Multics PL/I compiler was operational in the Fall of 1969; the current version became available in the Fall of 1972. Since PL/I is the principal language of the Multics system, even for systems programming, the Multics operating system provides the facilities needed by the PL/I language. Extract: Stream Output Stream Output Zelkowitz states that PL/I defines printed output as a continuous stream of characters, and that, in order to be printed, the stream of characters must be broken into fixed length records that serve as line images. A line is not printed until it is either full or is forced out by a SKIP option on a PUT statement. Zelkowitz claims that this mode of operation is tolerable in a batch environment but is unacceptable in an interactive environment, since output from a PUT statement might not beprinted when a subsequent GET statement is executed. The manner in which PL/I specifies that a line is printed need not cause any problems to an interactive implementation. PL/I does not require that the implementation wait until a line is full before the characters in it are printed. If the operating system does not allow the printing of a partial line, the defect is in the operating system and not in the PL/I language. Even if lines were printed only when full or when SKIP is specified, the pending line(s) could be printed when a GET statement is executed. Multics uses a device independent input/output interface in which I/0 streams are connected to the appropriate file or device by means of a software switch. One stream can be attached as a synonym for another stream, in which case an I/0 transaction on the synonym stream is forwarded to the stream to which it is attached. The PL/I file SYSPRINT, which is the default file for PUT statements, is normally attached as a synonym to the Multics stream "user_output", which, in turn, is normally attached to the user's terminal. The default attachment of a file can be changed by the use of a TITLE option in the declaration of the file or in the OPEN statement. The file attachment can also be changed by using Multics commands that manipulate I/0 stream attachments. If the user does not change the attachment of SYSPRINT, the statement put list("Hello there"); in Multics PL/I prints the string "Hello there" on the user's terminal and the terminal print mechanism is left sitting immediately after the last character typed. Output from a subsequent PUT statement begins in the next character position. This behavior is simply achieved by having the I/0 module that processes PUT statements empty the buffer associated with a file after each PUT statement. Extract: ON CONDITIONS ON CONDITIONS Zelkowitz claims that the PL/I condition mechanism is i l l suited for error detection purposes in an interactive environment and was therefore omitted from the PLUM system. When an error occurs, PLUM enters an interactive error routine. The user can then perform a number of actions such as o return to the exerting program at the point of the error or at some other point o symbolically inspect or alter variables in the program o set breakpoints In fact, all of these facilities can be achieved within the standard PL/I condition mechanism! In Multics, all errors detected by hardware and most errors detected by software are reported by means of the PL/I condition mechanism. Multics provides a default error on unit that is invoked if the user has no on unit established for the condition being signalled. In cases where there is a standard action specified for the condition, the standard action is taken and execution continues. In most cases, the default error handler prints a message that describes the error and calls the Multics command processor to read from the input stream. A debugging program, either written by the user or supplied by Multics, can be entered following an unclaimed signal resulting from an error. The stacked block activation records of the PL/I program are preserved, so the debugger can inspect the state and history of the program at the time of the error. All of the facilities desired by Zelkowitz are available, including the ability to investigate variables of the program before deciding on the corrective action to be taken. Extract: SUMMARY SUMMARY Zelkowitz has identified stream output and the condition mechanism as two aspects of the PL/I language that seem unsuited to an interactive implementation. We have shown that, given the proper support from the operating system, both facilities are easily implemented. This is not to say that there are no problems with PL/I stream output or the PL/I condition mechanism, but the problems that do exist are independent of an interactive implementation. in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details in SIGPLAN Notices 11(04) April 1976 view details in SIGPLAN Notices 11(04) April 1976 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 SIGPLAN Notices 11(04) April 1976 view details in Software — Practice and Experience 6(03) July-September 1976 view details in Software — Practice and Experience 6(03) July-September 1976 view details in Computer Languages 2(4) view details in Computer Languages 2(4) view details Although PL/I standards activities have been in process since 1965 (prior to the ANSI/ECMA cooperative effort) there is little evidence of the impact of the standard on vendors' systems. With respect to US government usage of the PL/I standard (p. 417), as of this date the ANSI document has not been accepted as a Federal Information Processing Standard (FIPS) and is not required to be adhered to by such groups as the US Army. However, it is expected and hoped that the ANSI standard will be the basis for any future US federal activities. One of the major difficulties of this definitional method (or its parent, VDL) is the use of the system as a question-answering device; that is, it is essential that the user have a detailed knowledge of the definition itself, as well as the medium, in order to phrase questions correctly. The means to ask such questions is not resolved by this paper. in ACM Computing Reviews 19(05) May 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 SIGPLAN Notices 14(07) July 1979 view details It was widely believed at the time that IBM intended PL/I to be a replacement for FORTRAN and COBOL, not simply another, better language. Radin alludes to a belief that part of the relative success of COBOL was the failure of PL/I to make the first release of OS/360. No doubt this was a factor, but there were certainly many others, such as the remarkably bad code the first PL/I compilers sometimes turned out, the large investment in COBOL programs, governmental requirements to produce applications in COBOL, etc. It would be a good project for someone to find out in a more than anecdotal way why those shops that moved to PL/I did so, why others did not, and why new programming shops choose to use COBOL over PL/I today when they have a choice. Programming now has a history long enough to provide lessons for current practitioners of what is still an art. More papers of this kind will make that history accessible to those willing to learn. in ACM Computing Reviews 21(05) May 1980 view details in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details PL/I (or NPL -- "New Programming Language" -- as it was first known) was designed under intense time pressure so that it would be ready for the first release of OS/360. (It wasn't.) Moreover, the non-IBM designers had great difficulty in getting information about OS/360, as discussant Bruce Rosenblatt pointed out. As Radin puts it, "NPL was a language designed too quickly. Its virtues resulted primarily from the combined intuitions ... of its definers." And indeed, the designers of PL/I did succeed in producing an extraordinarily useful and powerful programming language. Programming languages are creatures of their times. The 1960s were a time of expansiveness, optimism, a "do your own thing" attitude, and general permissiveness. PL/I reflects that spirit well. Its first design objective was "freedom of expression"; "if a particular combination of symbols has reasonably sensible meaning, that meaning is made official." The 1970s were a time of retrenchment and pessimism, with an emphasis on "back to basics," "small is beautiful," and evangelical religion. The languages of that decade, epitomized by PASCAL, were small, limited in their objectives, and emphasized such notions as strong typing. No wonder that PL/I seemed gargantuan and old-fashioned. Yet despite its unfashionableness it remains with us, an impressively effective language for doing work that needs to be done. in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue 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 in ACM Computing Reviews March 1982 view details The author is eminently qualified to have written this paper. She is a long-time employee of IBM, and has written many papers and a definitive book on the development of programming languages. Her account of the contributions of IBM to the development of programming languages is itself a contribution to the subject. in ACM Computing Reviews March 1982 view details It is a difficult book to review adequately. One must ask if it conveys the same message to that vast majority of information processing specialists who were not in the business at the time of the events recounted as it does to those of us who played an active role in some of the developments as they happened. Judicious inquiry of younger readers of the book suggests that rather more of the informal flavor comes through than one might suspect at first. In that sense the book "tells it like it was," although some of the text makes it quite clear that programming language designers have the same kind of selective and prismatic memories that other people have. The plan of the book is straightforward. Thirteen specific languages were selected by the conference organizers, and the book contains, for each language: a formal paper; a transcript of the presentation; a transcript of remarks by a designated discussant; a transcript of a subsequent question and answer session; the full text of all questions submitted; a biography of the authors. In addition there is the full text of the Keynote Address presented by Captain Grace Murray Hopper, itself required reading, and a series of appendices, including summaries of each language. As stated in the introductory material on the organization of the conference, the criteria for selection of the languages to be included were: "that the languages 1) were created and in use by 1967; 2) remain in use in 1977; and 3) have had considerable influence on the field of computing." The 1967 cutoff was to insure at least ten years perspective. The result of applying these criteria was: ALGOL 60 APL APT BASIC COBOL FORTRAN GPSS JOSS JOVIAL LISP PL/I SIMULA SNOBOL This general review cannot pursue the specific language chapters; that is a task for individual reviews elsewhere in CR. Some overall comments are in order, however. The formal papers are not simply personal recollections of the authors. An organized procedure was established to guide each author in preparing an account according to established historical practice, thus maximizing the archival value of the papers. It appears to have worked, for the authors systematically -- and in some cases, apparently, painfully -- searched for old records, letters, and memoranda. The vignettes that surface therefrom are fascinating. No one should be surprised that the accounts of the camel (designed by committee) languages, ALGOL 60 and COBOL, have a somewhat different flavor from the others. There is a gold mine for students of decision making processes in this book. The conference organizers are to be commended for providing two accounts of ALGOL 60, one from the American and one from the European point of view. The contrasting perceptions and the almost recursive discussion are both intriguing and delightful. This reviewer's one regret is that it was impossible to capture and document the conversations that occurred over the coffee cups and in the corridors. In summary, this is a superb book, a must for all computer professionals. It is also one of the very few records of a conference of any sort where the reader gets a feeling for what it was like to actually be there. This reviewer was there and reading this book almost four years after the conference brought back delightful memories with preternatural clarity. in ACM Computing Reviews March 1982 view details The particular interests of the authors show in the variety of organization and emphasis found in the papers. John Backus describes the background of the FORTRAN project, some of the design decisions, the documentation and implementation. Alan Perlis emphasizes the many people involved in the ALGOL design, from before 1958, through the Zurich and Paris meetings, culminating in ALGOL 60. Peter Naur concentrates on the design decisions made between the Zurich and Paris meetings. The disagreements which surface in appendices to his paper make for fascinating reading. Kristen Nygaard describes the many changes which the design of SIMULA went through from 1961 through 1971, from SIMULA I to SIMULA 67. The book is not a dry history -- many statements seem particularly surprising in hindsight. John Backus says of FORTRAN, "As far as we were aware, we simply made up the language as we went along. We did not regard language design as a difficult problem, merely a simple prelude to the real work of designing a compiler which could produce efficient programs." Jean Sammet stresses with regard to COBOL, "We were going to recommend a short range composite approach good for at least the next year or two." The history of the technical decisions is particularly well researched and presented. Many ideas were taken directly from other languages, such as the separation of the data description and executable statements in COBOL, deriving from FLOW-MATIC. Some seemed to occur almost casually, such as Thomas Kurtz commenting on the design of BASIC, "Around 1960 or 1961, after a visit to the PDP-1 time-shared computer at MIT, I can clearly recall John McCarthy saying, 'Why don't you guys do time sharing?' Shortly afterward I said to Kemeny, 'I think we ought to do time sharing.' Kemeny responded, 'OK.' And that was that!" Other decisions stemmed from deadlocks, as Alan Perlis described, when a European member of the ALGOL committee declared "No! I will never use a period for a decimal point." The proposal from Joseph Wegstein for three levels of language calmed the situation. The ALGOL paper and appendices by Peter Naur present different views of the same experience. Even a project consisting of only two people can produce its share of excitement. Kristen Nygaard describes the shock of a switchboard operator at overhearing a violent argument between two men in a hallway. She was reassured that it was just Dahl and Nygaard discussing SIMULA. One thing which emerges from many of the papers is the deep involvement which a language design can elicit from its designers. John Backus and Jean Sammet both describe many late, long hours. But this book is not just a series of papers by knowledgeable authors. It is itself a history of the History of Programming Languages Conference held in Los Angeles in 1978. Jean Sammet, the General Chairman, describes how the conference was put together. There are many valuable ideas here for potential conference organizers. The Conference Historian, Henry Tropp, provides a historical perspective and suggests archiving of design papers. The keynote address is by Grace Hopper. Its transcript captures the qualities of innovation and humor which make her talks such an experience. The author talks are based on the papers, so there is much redundancy of material. The main value to be gained by the duplication is the opportunity to discover the human side of the authors, which comes out in the more informal relation to the audience. Jean Sammet brings down the house with her lament that students are not given more than a passing exposure to COBOL before they receive their degrees in computer science. The question and answer sessions were often as interesting as the talks. The book gives John Backus's answer to the question why the letters I through N were chosen to designate integers. The readability of these sections attest to the effort which Richard Wexelblat put into the editing of this volume. The History of Languages represents a tremendous amount of effort from a great many people, and is a book which programmers as well as language designers will find both instructive and enjoyable. in ACM Computing Reviews March 1982 view details in ACM Computing Reviews March 1982 view details The language The Multics PL/1 language is the language defined by the IBM "PL/1 Language Specifications" dated March 1968. At the time this paper was written most language features were implemented by the compiler but the run time library did not include support for input and output, as well as several lesser features. Since the multi-tasking primitives provided by the Multics operating system were not well suited to PL/1 tasking, PL/1 tasking was not implemented. Inter-process communication (Multics tasking) may be performed through calls to operating system facilities. Extract: Design objectives Design objectives The project's design decisions and choice of techniques were influenced by the following objectives: 1) A correct implementation of a reasonably complete PL/1 language. 2) A compiler which produced relatively fast object code for all language constructs. For similar language constructs, the object code was expected to equal or exceed that produced by most Fortran or COBOL compilers. 3) Object program compatibility with EPL object programs and other Multics languages. 4) An extensive compile time diagnostic facility. 5) A machine independent compiler capable of bootstrapping itself onto other hardware. The compiler's size and speed were considered less important than the above mentioned objectives. Each phase of the original compiler occupies approximately 32K, but after the compiler bas compiled itself that figure will be about 24K. The original compiler was about twice as slow as the Multics Fortran compiler. The bootstrapped version of the PL/1 compiler is expected to be considerably faster than the original version but it will probably not equal the speed of Fortran. Extract: SUMMARY SUMMARY Our experiences both as users and implementors of PL/1 have led us to form a number of opinions and insights which may be of general interest. It is feasible, but difficult, to produce efficient object code for the PL/1 language as it is currently defined. Unless a considerable amount of work is invested in a PL/1 compiler, the object code it generates will generally be much worse than that produced by most Fortran or COBOL compilers. The difficulty of building a compiler for the current language has been seriously underestimated by most implementors. Unless the language is markedly improved and simplified this problem will continue to restrict the availability and acceptance of the language and will lead to the implementation of incompatible dialects and subsets. [7] Simplification of the existing language will make it more suitable to users and implementors. We believe that the language can be simplified and still retain its "universal" character and capabilities. The experience of writing the compiler in PL/1 convinced us that a subset of the language is well suited to system programming. This conviction is supported by Professor Corbat㠩n his report on the use of PL/1 as an implementation language for the Multics system. [8] Many PL/1 concepts and constructs are valuable, but PL/1 structures and list processing seem to be the principal improvement over alternative languages. [9] External link: History of Multics PL/1 in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details Resources
|