History of Programming Languages-II Edited by THOMAS J. BERGIN, JR. and RICHARD G. GIBSON, JR. The American University Washington, D.C.
ACM Press N e w York, N e w York
VV Addison-Wesley Publishing Company Reading, Massachusetts • Menlo Park, California • N e w York Don Mill, Ontario • Wokingham, England • Amsterdam • Bonn Sydney • Singapore • Tokyo • Madrid • San Juan • Milan • Paris
This book is published as part of ACM Press Booksma collaboration between the Association for C.omputing (ACM) and Addison-Wesley Publishing Company. ACM is the oldest and largest educational and scientific society in the information technology field. Through its high-quality publications and services, ACM is a major force in advancing the skills and knowledge of IT professionals throughout the world. For further information about ACM, contact: ACM Member Services 1515 Broadway, 17th Floor New York, NY 10036-5701 Phone: 1-212-626-0500 Fax: 1-212-944-1318 E-mail:
[email protected] ACM European Service Center 108 Cowley Road Oxford OX41JF United Kingdom Phone: +44-1865-382338 Fax: +44-1865-381338 E-mail:
[email protected] URL: http://www.acm.org
Library of Congress Cataloging-in-Publication Data History of programming languages / edited by Thomas J. Bergin, Richard G. Gibson. p. cm. Includes biblio[;raphical references and index. ISBN 0-201-89502-1 1. Programming languages (Electronic computers)--History. I. Bergin, Thoma:~ J. II. Gibson, Richard G. QA76.7.H558 1!)96 95-33539 005.13'09--dc20 CIP
Copyright © 1996 by ACM Press, A Division of the Association for Computing Machinery, Inc. (ACM). All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the publisher. Printed in the United States of America. 1 2 3 4 5 6 7 8 9 10-MA-009989796
CONTENTS
Editors' Introduction General Introduction Development of the HOPL-II Program Acknowledgments
vii ix xi xvi
The Opening Session CONFERENCE CHAIRMAN'S OPENING REMARKS, John A. N. Lee LANGUAGE DESIGN AS DESIGN, Frederick R Brooks, Jr. FROM HOPL TO HOPL-II (1978-1993): 15 Years of Programming Language Development, Jean E. Sammet MAKING HISTORY, Michael S. Mahoney
16 25
ALGOL 68 Session A HISTORY OF ALGOL 68, C. H. Lindsey Transcript of Presentation, C. H. Lindsey Transcript of Question and Answer Session Biography of C. H. Lindsey III
Pascal Session RECOLLECTIONS ABOUT THE DEVELOPMENT OF PASCAL, N. Wirth Transcript of Disscussant's Remarks, Andrew B. Mickel Transcript of Question and Answer Session Biography of Niklaus Wirth
IV
27 84 95 96
97 111 117 119
Monitors and Concurrent Pascal Session MONITORS AND CONCURRENT PASCAL: A PERSONAL HISTORY, Per Brinch Hansen Transcript of Question and Answer Session Biography of Per Brinch Hansen
121 171 172
iii
CONTENTS V
Ada Session ADAmTHE PROJECT: The DoD High Order Language Working Group, William A. Whitaker, Colonel USAF, Retired Transcript of Discussant's Remarks, John B. Goodenough Biography of William A. Whitaker, Col. USAF, Ret.
VI
Lisp Session THE EVOLUTION OF LISP, Guy L. Steele Jr.and Richard P. Gabriel Transc~ript of Presentation, Guy L. Steele Jr. and Richard P. Gabriel Transc~ript of Discussant's Remarks, John Foderaro Transc;ript of Question and Answer Session Biographies of Guy L. Steele Jr. and Richard P. Gabriel
VII
369 413 426 427
FORMAC Session THE BEGINNING AND DEVELOPMENT OF FORMAC (FORmula MAnipulation Compiler), Jean E. Sammet Transc~ript of Presentation, Jean E. Sammet Transc~ript of Discussant's Remarks, Joel Moses Transc=ript of Question and Answer Session Biography of Jean E. Sammet
iv
331 352 364 366 366
Discn~te Event Simulation Languages Session A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES, Richard E. Nance Transc~ript of Presentation, Richard E. Nance Transc~ript of Question and Answer Session Biography of Richard E. Nance
IX
233 309 326 328 329
Prolog Session THE BIRTH OF PROLOG, Alain Colmerauer and Philippe Roussel Transc~ript of Presentation, Alain Colmerauer Transc~ript of Discussant's Remarks, Jacques Cohen Transc~ript of Question and Answer Session Biographies of Alain Colmerauer and Philippe Roussel
VIII
173 229 231
429 456 465 468 468
CONTENTS
X
CLU Session A HISTORY OF CLU, Barbara Liskov Transcript of Presentation, Barbara Liskov Transcript of Question and Answer Session Biography of Barbara Liskov
Xl
Smalltalk Session
THE EARLY HISTORY OF SMALLTALK, Alan C. Kay Transcript of Presentation, Alan C. Kay Transcript of Discussant's Remarks, Adele Go/dberg Transcript of Question and Answer Session Biography of Alan C. Kay Xll
599 622 623
Forth Session THE EVOLUTION OF FORTH, Donald R. Co/burn, Charles H. Moore, and Elizabeth D. Rather Transcript of Presentation, Elizabeth D. Rather Transcript of Question and Answer Session Biographies of Elizabeth Rather, Donald R. Colburn, and Charles H. Moore
XIV
511 579 589 596 597
Icon Session
HISTORY OF THE ICON PROGRAMMING LANGUAGE, Ralph E. Griswold and Madge T. Griswold Transcript of Question and Answer Session Biographies of Ralph E. Griswold and Madge T. Griswold Xlll
471 497 508 510
625 658 668 669
C Session
THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE, Dennis M. Ritchie Transcript of Presentation, Dennis Ritchie Transcript of Question and Answer Session Biography of Dennis M. Ritchie
671 687 696 698
CONTENTS XV
C++ Session A HISTORY OF C++: 1979-1991, Bjame Stroustrup Transcript of Presentation, Bjarne Stroustrup Transcript of Question and Answer Session Biography of Bjarne Stroustrup
XVI
vi
699 755 764 769
Forum ,on the History of Computing (April 20, 1993) ISSUES IN THE HISTORY OF COMPUTING, Michael S. Mahoney ARCHIVES SPECIALIZING IN THE HISTORY OF COMPUTING, Bruce H. Bruemmer THE ROLE OF MUSEUMS IN COLLECTING COMPUTERS, Gwen Bell (with additional editing by Robert F. Rosin) THE ANNALS OF THE HISTORY OF COMPUTING AND OTHER ,JOURNALS, BernardA. Galler AN EFFECTIVE HISTORY CONFERENCE, Jean E. Sammet UNIVERSITY COURSES, Martin Campbell-Kelly DOCUMENTING PROJECTS WITH HISTORY IN MIND, Michael Marcotty ISSUES IN THE WRITING OF CONTEMPORARY HISTORY, J.A.N. Lee FORUM CLOSING PANEL Transcript of Question and Answer Session
772
Appendix A: What Makes History? Michael S. Mahoney
831
Appendix B: Call for Papers
833
Appendix C: List of Attendees
849
Appenclix D: Final Conference Program
851
Index
857
782 785 789 795 799 806 808 810 825
EDITORS' INTRODUCTION
In 1978, the ACM Special Interest Group on Programming Languages (SIGPLAN) sponsored a Conference on the History of Programming Languages (HOPL). Papers were prepared and presentations made at a Conference in Los Angeles, California. The Program Committee selected thirteen languages that met the criteria of having been in use for at least 10 years, had significant influence, and were still in use. The languages were: ALGOL, APL, APT, BASIC, COBOL, FORTRAN,GPSS, JOSS, JOVIAL, LISP, PL/I,SIMULA, and SNOBOL. The results of that conference were recorded in History of Programming Languages, edited by Richard L. Wexelblat [New York: Academic Press, 19811. The Second ACM SIGPLAN History of Programming Languages Conference (HOPL-II) took place on April 20-23, 1993 in Cambridge, Massachusetts. The papers prepared for that conference form the basis of this present volume, along with the transcripts of the presentations, a keynote address "Language Design as Design" by Fred Brooks, a discussion of the period between HOPL and HOPL-II by Jean Sarnmet, and a talk on "What Makes History" by Mike Mahoney (the conference historian). There was also a banquet, hosted by Bernie Galler, and a closing panel of six language developers, chaired by Mike Mahoney. Unfortunately due to page limitations, the transcripts of the banquet, Forum, and the closing panel are not included in this volume. It is our hope that they can be published elsewhere. The Conference was preceeded by a Forum on the History of Computing, chaired by Bob Rosin, and the papers presented at the Forum complete this volume. The Program Committee for HOPL-II decided to have both invited and submitted papers, and we believe that the range of languages and the quality of presentation will make this volume a classic in the history of programming literature. The languages at HOPL-II were: Ada, A L G O L 68, C, C++,
CLU, Discrete Simulation Languages, FORMAC, Forth, Icon, Lisp, Monitors and Concurrent Pascal, Pascal, Prolog, and Smalltalk. The majority of this volume is the material on the individual languages, with a chapter devoted to each language, as follows: • a paper by each author; • a transcript of the author's presentation; • a transcript of a discussant's remarks (not all languages); • a transcript of the question and answer session; • biographies of the authors. It should be noted that some authors' presentations closely followed their papers, and since the book is oversized, the transcripts of these presentations were omitted, with the kind permission of the authors. All papers were published as preprints in ACM SIGPLAN Notices, Vol. 28, No. 3 (March 1993). The papers are reprinted here with the permission of ACM and of the authors. In some cases changes have been made by the authors to correct typographical or factual errors. In some cases additional material has been added, with an appropriate notation by an author or editor.
vii
EDITORS' INTRODUCTION
Jan Lee, Jean Sammet, and Bob Rosin, in their various capacities, have identified the numerous people who worked so long and hard on the Conference; however, we would like to identify the people who assisted us in the production of this volume: Betty Henderson patiently transcribed 24 hours of difficult computer jargon, and put it on diskettes so Rick and I could begin editing; We are especially grateful for the support of the National Science Foundation for providing partial funding for the conference and for the preparation of this book, under grant CCR -9208568 and to Nora Cortes-Comerer of ACM Press who secured the additional funding necessary for the completion of the project. In addition to sponsoring the conference, SIGPLAN and its current Chair, Barbara Ryder, provided additional funding for the preparation of photographs for this volume; Alan Rose of Multiscience Press, Inc. (New York, NY) served as our producer, and Lauralee B. Reinke of Context Publishing Services (Sausalito, CA) formatted all of the material; without their expertise, the technical details of preparing a book of this size would have overwhelmed us; Special thanks go to Anita LaSalle, Chair of the Computer Science and Information Systems Department at The American University for casettes, diskettes, thousands of pages of photocopies, and FedEx charges to send materials around the globe; and to Sandy Linden, Mark Davidson, and Maureen O'Conneil who provided us with administrative support; And last, but not least, a special thanks to Dick Wexelblat who started this book project; he was always there to share his experience and to give advice when asked. We are especiallly indebted to those individuals whose presentations were deleted from this volume due to page limitations, colleagues who gave of their time and talent without the reward of seeing their efforts in print. Our families de:serve our sincere appreciation, since efforts of this magnitude naturally intrude on family life: Diane, John and Jeannine, Michael and Kathleen Bergin, and a special thanks to Karen and Gibson.
baby
Finally, we would be remiss if we did not thank Jean Sammet, who has spent much of her professional life preserving the history of programming languages. There is no way to thank her adequately for inspiring the conference or for almost two years of campus visits, telephone conversations, telephone reminders, e-mail messages, and other support that she willingly gave us during the preparation of this book. Without her single-minded devotion to her profession, our discipline would be missing the incredibly rich history captured in this volume. Tim Bergin Rick Gibson
viii
GENERAL INTRODUCTION
We are indeed pleased to provide this introductory material for this book. The book is the culmination of work on a 1993 conference (HOPL-II) whose development started in 1990; HOPL-II in turn was a follow-on to the first HOPL, held 15 years earlier (1978).
First HOPL Conference In order to put this conference in perspective, it is useful to provide some information about the first conference of this type that was held. In 1978 ACM SIGPLAN sponsored a History of Programming Languages Conference (HOPL) with Jean E. Sammet as General Chair and Program Chair, and John A. N. Lee as the Administrative Chair. That conference was composed of invited papers for the 13 languages that met the following criteria: "(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."
[History of Programming Languages, Richard L. Wexelblat, ed., Academic Press, ACM Monograph Series, 1981), page xviii.] (The cutoff date of 1967 was chosen to provide perspective from a distance of at least ten years.) The languages chosen by the Program Committee as meeting those criteria were: ALGOL, APL, APT, BASIC, COBOL, FORTRAN, GPSS, JOSS, JOVIAL, LISP, PL/I, SIMULA, and SNOBOL. A key person involved in the early development of each of those languages was invited to write a paper according to very strict guidelines and with numerous rewrites expected. That conference was deemed a great success by its attendees. The final proceedings, edited by R. L. Wexelblat, is now the definitive work on the early history of those particular languages. Several people asked at that time why a conference was held rather than simply having people prepare the papers and publish them in a book. We felt initially--and this was confirmed by the actual occurrence--that the audience discussion after each presentation would provide greater insight into the history of the events and decisions that led to the definition of the languages in their early forms. Some of the "cross talk" publicly and privately among the attendees--many of whom participated in the creation of several languages--provided significant insights into the early developments.
Second HOPL Conference The first HOPL conference was intended to be only the beginning, and not the end of any consideration of programming language history. As a result, not long after the end of that conference, we began thinking about a second HOPL Conference, with the intent of building on what we learned fi'om the first conference, and expanding its scope and coverage. Due to the pressure of other activities, it took many years before we were able to focus on a second conference. During that time period, a cadre of our colleagues was developed that also strongly promulgated the need to study the history of ix
GENERAL INTRODLICTION
computing. In fact, the establishment of the journal Annals of the History of Computing, to be published by AFIPS, was announced at the end of the first HOPL Conference with Bernard A. Galler as Editor-in-Chief. Since 1987, John A. N. Lee has been the Editor-in-Chief, and in 1992 the IEEE Computer Society became the publisher. In January 1996, Michael R. Williams took over as the third Annals Editor-in-Chief. ACM has also sponsored several other history conferences, covering the fields of scientific comptaing, medical informatics, and personal workstations. Finally, we developed a proposal in 1990, and the ACM SIGPLAN Executive Committee authorized us to proceed 'with this Second History of Programming Languages Conference (HOPL-II). We then called back to voluntary duty several members of the original conference-organizing committees and many of them were happy to join us in this new endeavor. In addition, we made a conscious effort to bring in newer/younger people who also have an interest in examining the past. But organizing a history conference is by no means as simple as organizing a technical conference dealing with current or recent research in which all the papers are to be contributed and for which there is tremendous competition to participate. This is primarily because most professionals in the computer field prefer to concentrate on current and future work rather than looking backward to what they have accomplished. A detailed description of how the final program was created is given in the next section of this introduction. The study of va~rious aspects of computing history is not merely an intellectual exercise; it shows us how we reached our current condition, indicates effective approaches as well as past errors, and provides perspective and insight for the future, and a surer sense of how to get there. The conference itself was held April 20 to 23, 1993, in Cambridge, Massachusetts with preprints issued as the March 1993 issue ofACM SIGPLANNotices (Volume 28, Number 3). This book contains an enormous amount of material not included in the preprints, including some revised papers as well as transcripts of the talks, the Forum papers, the keynote address, and other material that provide a record of what occurred during the conference. We regret that space limitations prevented the inclusion of the transcripts of the banquet, the closing panel and the Forum. We hope that they can be published elsewhere. We appreciate the hard work done by all the people who helped organize and run the conference. We are particularly grateful to Tim Bergin and Rick Gibson who unexpectedly took on the enormous task of preparing this book for publication. John A. N. Lee (Conference Chair) Virginia Polytechnic Institute and State University Jean E. Sammet (Program Chair) Programming Language Consultant (IBM, Retired)
DEVELOPMENT OF THE HOPL-II PROGRAM
The success we tried to achieve in this conference is due to an extremely hard-working and dedicated Program Committee and equally hard-working authors and numerous other volunteers. This section explains hownand to some extent why~the program was developed.
MEMBERS OF PROGRAM COMMITTEE The Program Committee consisted of the following people, and almost all of them carried out a major task in addition to his/her standard role on a program committee. The affiliations shown are those at the time the conference was held. Chair: Secretary: Conference Historian: Forum Chair: Other members:
Jean E. Sammet (Programming Language Consultant) Thomas J. Bergin (American University) Michael S. Mahoney* (Princeton University) Robert E Rosin (Enhanced Service Providers, Inc.) Jacques Cohen (Brandeis University) Michael Feldman (The George Washington University) Bernard A. Galler* (University of Michigan) Helen M. Gigley (Naval Research Laboratory) Brent Hailpern* (IBM) Randy Hudson (Intermetrics) Barbara Ryder* (Rutgers University) Richard L. Wexelblat (Institute for Defense Analyses) *Chair of a Program Review Committee (as described below)
APPROACH TO CREATING THE PROGRAM In order to appreciate the papers presented at this conference and the accompanying Forum on the History of Computing, it is important to understand how the program was developed. Three fundamental decisions were made at the beginning: 1. there would be invited and contributed papers, 2. the scope of the conference would include papers on the early history of specific languages--as in the first HOPL conferencenand papers on (a) evolution of a language, (b) history of language features and concepts, and (c) classes of languages for application-oriented languages and paradigm-oriented languages, 3. the conference was not intended to honor anyone.
xi
DEVELOPMENTOF THE HOPL-IIPROGRAM Invited Speakers, For the invited speakers, the Program Committee used the same types of criteria used for the first HOPL conference, as indicated in the preceding section, but changed the cutoff date to require that "preliminary ideas about the language were documented by 1982 and the language was in use or being taught by 1985." We issued six invitations for people to prepare papers because these languages met the three indicated criteria, that is, compliance with the date, were still in use, and had influence on the computing field): Aiain Colmerauer Jean Ichbiah Alan Kay Dennis Ritchie William Whitaker Niklaus Wirth
Prolog Ada (technical development) Smalltalk C Ada (project management) Pascal
Each of these people was deemed a key person in the early development of the language; all of them accepted the invitation/request to prepare detailed papers, but subsequently Jean Ichbiah was unable to prepare a paper within the specified conference schedule due to the pressure of other responsibilities and withdrew his participation.
Guidance to Authors and Paper Submission The Program Committee followed the earlier successful plan from the first HOPL Conference by providing authors with detailed questions to guide them in writing their papers. We used the original questions for early history from the first HOPL Conference, and then developed three new sets of questions to deal with the three new types of papers we expected. Randy Hudson coordinated and edited those four sets of questions; they appear in this book as Appendix B. A call for papers was issued in December of 1990 (Appendix B) with notification to potential authors that their papers would go through two rounds of refereeing with a major rewrite probably needed between them. Dick Wexelblat served as submissions coordinator, and provided administrative support for the Call for Papers, the distribution of manuscripts (twice), and hosting two Program Committee meetings. In his role as editor of the preprints (Volume 28, Number 3, March 1993 issue ofACM SIGPLAN Notices), he also developed the format guidelines used by the authors.
Program Review Committees Because of the complexity of the paper processing and refereeing, we established four Program Review Committees (PRCs), each serving essentially as a subcommittee of the Program Committee but with additional people serving on each PRC. The PRC scopes corresponded approximately to the types of papers we expected. The chairs of those PRCs were responsible for most of the interaction with the authors and referees on each specific paper. The PRC chairs were: Early History Evolution Features & Cla:~ses Invited Papers
xii
Brent Hailpern Bernard A. Galler Barbara Ryder Michael S. Mahoney and Brent Hailpern
DEVELOPMENTOF THE HOPL-II PROGRAM
Each of the PRC Chairs also recruited additional people to help with the refereeing and selection. While I would like to list their names, as is often done for conferences, it is not appropriate to do so here because almost all of them were selected because of knowledge of specific language(s) so it would be too easy for the authors to identify their referees! Paper Selection
In September 1991 the Program Committee gave "conditional acceptance" to some of the contributed papers. The authors were given referees' comments and told that if they complied with a reasonable number of those suggestions the paper would be accepted (i.e., they would not be in competition with one another). In August 1992 the Program Committee decided which contributed papers met the standards for the conference, and those are printed here, along with the invited papers, which also underwent a similar process of rewrites. Guidance to Authors on Historiography
In addition to other steps taken to try to achieve high quality, we asked Michael S. Mahoney, a professor with significant expertise and experience in historiography--and specifically the history of computing--to provide guidance to the Program Committee and the authors. He reviewed all the papers and provided specific assistance to any author who requested it. His paper "Making History" appears in Chapter 1; another paper, "What Makes History?", was sent to prospective authors and is included as Appendix A. Language Experts To assist the authors, each PRC chair assigned a technical expert in the subject to help each author with the paper by reviewing the various drafts. In some sense, these experts are the unsung heroes of the conference, and so it is appropriate to list and thank them.
Language~Topic
Expert
Language Summary
Ada ALGOL 68 C C++ Clu Concurrent Pascal FORMAC Forth Icon Lisp
Anthony Gargaro Henry Bowlden William McKeeman Jerry Schwarz John Guttag Narain Gehani James Griesmer Phil Koopman David Hanson Gerald Jay Sussman
Pascal Prolog Simulation languages Smalltalk
C.A.R. Hoare Fernando Pereira Philip Kiviat Adele Goldberg
Anthony Gargaro Henry Bowlden William McKeeman Jerry Schwarz John Guttag Charles Hayden James Griesmer Phil Koopman David Hanson Gerald Jay Sussman, Guy L. Steele, Jr., and Richard P. Gabriel Peter Lee Fernando Pereira Philip Kiviat Tim Budd
xiii
DEVELOPMENTOF THE HOPL-II PROGRAM Language Descriptions We wanted the authors to concentrate on writing a history paper and not on describing the language. Therefore we asked knowledgeable individuals to provide a very short introduction to each language and these "langua~;e summaries" appeared in the preprints. Unfortunately, space limitations prevented our including them here. The authors of these language summaries are listed above; the preparation and editing of these language descriptions was coordinated by Michael Feldman. Reasons for Some Language Absences
In examining the list of papers accepted for this conference, the reader might well wonder about the absence of some obvious subjects. For example, since FORTRAN and COBOL were included in the first HOPL Conference--and remain as major languages---one might have expected papers on their evolution to appea~r in this conference. The Program Committee decided to invite only papers dealing with the early history of the major languages developed since the first HOPL conference. Therefore, the omission of the.se subjects, and numerous others, is due to the policy of having contributed as well as invited papers; if people did not submit acceptable papers on an important topic it could not be included in this conference. FORUM ON THE! HISTORY OF COMPUTING Many SIGPLAN Conferences precede the main paper sessions with a day of tutorials. The Program Committee adapted that practice to provide an afternoon and evening devoted to a Forum on the History of Computing. The intent of the Forum was to sensitize computer scientists to issues and challenges in the history of computing, and to entice some of them to become involved in this work. The Forum activity was chaired by Robert E Rosin, who assembled a committee to help organize the topics and sessions;, invite the participants, and review written material. An introduction by Robert Rosin, the written papers prepared for the Forum, and a transcript of the closing panel are included in this book. Unfortunately, there was not enough room in this volume to include transcripts of the presentations. The Forum Committee operated under the general guidance and approval of the Program Committee, and consisted of the following people, whose affiliations at the time of the conference are shown: Chair: Members:
Robert E Rosin Thomas J. Bergin Michael S. Mahoney Michael Marcotty Tom Marlowe Jean E. Sammet
(Enhanced Service Providers, Inc.) (American University) (Princeton University) (General Motors; now a consultant) (Seton Hall University) (Programming Language Consultant)
PERSONAL COMMENT It is not common fi~r the Program Chair of a conference to have a paper included in that conference. The Program Committee decided initially that it was reasonable for me to submit a paper, but in order to maintain objectivity and fairness I was kept completely separated from any refereeing or decision
xiv
DEVELOPMENT OF THE HOPL-II PROGRAM
process on my paper, and I don't know any more than any other author as to who the referees were or what general evaluation comments were turned in.
CONCLUSION The entire Program Committee and its supporting subcommittees have spent literally hundreds--and in some cases thousands---of hours preparing this conference. I am personally very grateful to Tim Bergin and Rick Gibson for the hundreds of hours they have spent in preparing this book. We hope you will find it valuable initially and in the future. Jean E. Sammet Program Chair
XV
AC KN OWLE DG M ENTS
My special thanks go to Jean Sammet, Program Chair, who coincidentally moved from full-time work to consultancy just about the time the intense effort on the development of the program started. Over the past five years she has spent an immense amount of time on this task, and without her drive, enthusiasm, and high standards, we would not have the high quality of historiography represented by the papers in this volume. Michael Mahoney, Conference Historian, led the program committee in learning and applying the techniques and methods of historical research. At least one program committee member was heard to say that he or she never realized before how difficult historical research was. In fact, the whole program committee deserves our thanks for developing an outstanding, high quality program. The preparation of the preprints was more complicated than usual due to the size and variety of material. The efft~rts by Dick Wexelblat and Janice Hirst in preparing the preprints are greatly appreciated. The work to prepare this book was enormous, and the willingness of Tim Bergin and Rick Gibson to unexpectedly assume this task is greatly appreciated. The organizing committee worked for approximately one year before the conference. A very visible aspect reflects the work of Dan Halbert, Publicity Chairman. Many of the attendees would not have known of the conference without his efforts; his patience in providing numerous drafts of publicity items satisfied our demands for high standards of presentation even in the ancillary materials. The results of the efforts of many members of the organizing committee was best seen during the conference itself, though some, like Richard Eckhouse, Conference Treasurer, remained unseen to participants. Our thanks to them all.
Members, Organizing Committee: Program Chair: Treasurer: Local arrangements: Publications: Recordings: Registration: Book exhibits: Publicity:
Jean E. Sammet Richard Eckhouse Peter S. Mager Richard L. Wexelblat Mary van Deusen Karen Lemone James P. Bouhana Dan Halbert
(Programming Language Consultant) (University of Massachusetts, Boston) (Perception Technology Corporation) (Institute for Defense Analyses) (IBM) (Worcester Polytechnic Institute) (Performance International) (Diqital Equipment Corporation)
Our thanks also go to the National Science Foundation which provided support for speakers, students, and this final book under grant #CCR-9208568. John A. N. Lee General Chair
xvi
I The Opening Session
CONFERENCE CHAIRMAN'S OPENING REMARKS, John A. N. Lee "LANGUAGE DESIGN AS DESIGN," Frederick P. Brooks, Jr. "FROM HOPL TO HOPL-II," Jean E. Sammet "MAKING HISTORY," Michael S. Mahoney CONFERENCE CHAIRMAN'S OPENING REMARKS J.A.N. LEE: Welcome to the Second History of Programming Languages Conference. My name is Jan Lee; I ' m the general chairman of this conference. We started thinking about this conference in 1978; that was the year of the first History of Programming Languages Conference (HOPL-I), chaired by Jean Sammet. It had been enormously successful and we were enthused enough at that time to begin thinking about our next history conference. We had many suggestions, perhaps the most serious of which was to consider the history of operating systems. In fact, we even had a name for it, HOOS. But it was obvious that the history of programming languages was continuing to happen, even in 1978 as we held that meeting. Pascal had begun to replace FORTRAN as the language of choice in computer science education, and the Department of Defense was talking about an all-purpose new language. There were programming developments that we left out of that meeting simply because there was not enough time to cover them. There were already things happening that would clearly be on the agenda of the next meeting. In the history of computing we generally choose to observe past events from a viewpoint of fifteen years; thus, 1993 was the obvious date not only to hold a second conference, but to regard that original meeting itself as a historical event. Jean Sammet and I have always known there would be another meeting. And in 1990 we convinced ACM and SIGPLAN to support that next meeting. Jean then recruited an impressive program committee who have worked very hard, as have the authors they selected, for almost three years. Most recently, we recruited a team of organizers to arrange the physical arrangements for you. Jean will introduce her committee to you at a later time and I will introduce the administrative volunteers. Similarly, Jean will relate to you the history of programming languages between the two conferences. My colleagues in academia believe there are three signs of senility in a prot~ssor--when his dreams turn lightly to thoughts of education, or to ethical considerations, or to history. However, in our profession I feel it's a sign of maturity when we have concerns for these aspects of the science. ACM started in about 1968 to concern itself with education and curricula. Prior to that it had introduced one of the first codes of professional conduct. In the mid-1970s we were concerned about the
CONFERENCE CHAIRMAN'S OPENING REMARKS
preservation of our history as, regrettably, we began to lose some of our pioneers. We are still concerned with cu~rricula. We've recently updated the code of professional conduct. And we continue to have concerns about preserving our heritage. ACM and SIGPLAN agreed to support this conference three years ago and the National Science Foundation agreedt to provide additional support to our invited speakers. NSF also provided funding for scholarships for students, and was joined by SHL System House Inc., the employer of one of our 1978 scholarship winners, for support of a fifth student. Of course the major sponsors of our conference are the employers of our volunteers, who provide the time and funding for their participation. You will meet all of our speakers later in the meeting, but let me now introduce and congratulate our student scholarship holders and ask them to stand. From the United Kingdom, Ross Hamilton, University of Warwick. From Norway, Jan Rune Hoimevik, University of Trondheim. Close to home, Stephen P. Masticola, Rutgers University; Rajeev Pandey, from Oregon State University; and Patficia A. Summers from Virginia Polytechnic Institute and State University. In 1978, the time of HOPL-I, there had been two earlier major history projects. The AFIPS/Smithsonian projects on history and the National Science Foundation sponsorship of a great reunion of pioneers of Los Alamos National Laboratory. In 1978, we knew about two proposals, one to establish a computer history institute, which would be sponsored by a then anonymous donor, and the anticipated publication of an AFIPS journal to be called Annals of the History of Computing. In that year also, Ken Olsen approached Gwen Bell to ask whether the TX-0 could be faithfully recreated at Marlboro. That gave her the impetus to establish a collection of artifacts and set her on the road to establishing a museum. That was 1978. In the past 15 years, the awareness of computing as a historical event has grown. Part of that awareness is due to The Computer Museum, which we will visit tonight; the transmogrification of that original digital museum at Marlboro is now a museum of international standing. It's not just a collection of must), artifacts. It has become, under Gwen Bell's leadership, a learning place about the past, the present, a~ndthe future of computing. In the 1960s, the Smithsonian had created a gallery in the National Museum of American History which included artifacts from the ENIAC and the Whirlwind. But more recently, the Institution has opened galleries in both the National Air and Space Museum and the Museum of American History, which emphasize computers and information technology. The Charles Babbage Institute was established at the University of Minnesota by Erwin Tomash. CBI has become our primary document archive and research institute. Recently, the IEEE center for the history of electrical engineering has also become a new center for the study of the history of computing at Rutgers University. In Great Britain, the Science Museum at Kensington recently completed the great work of Charles Babbage, on the bicentenary of his birth, by building his Difference Engine. Dorin Swade, the curator, accomplished what Babbage and Clemment had been unable to do in the 19th century and proved that Babbage's design was both correct and constructable still using 19th century tooling techniques. Apart from a couple of obvious oversights in the drawings that any professional engineer would have found, Babbage's Engine---different from most of our software--worked the first time. Building on the work of Konrad Zuse, The Deutsches Museum in Munich has created a gallery that includes not only a construction of his Z-3 machine, but also Fritz Bauer's Stanishlaus machine. Next year, Europe will commemorate the D-Day landing in Normandy, which led to the end of World War II. One of the contributions of that success has got to be the work of the code breakers at Bletchley Park. Recently the Bletchley Park Trust has been created and has raised £1,000,000 to preserve the park and its significant buildings, and to create a museum to memorize COLOSSUS, Alan Turing, Telecommunication, and Air Traffic Control. We wish them luck.
2
CHAPTER I
INTRODUCTION OF FREDERICK R BROOKS, JR.
In the aftermath of HOPL-I, ACM organized three history conferences on workstations, medical informatics, and scientific computation. There have been conferences in Europe, including, in 1991, a magnificent bicentennial conference on Babbage and Farraday at St John's College, Cambridge. The French conference will have its third instance this year. During this period, we've also seen the development of a number of organizations. The IFIP working group on history will have its first meeting later this year and is attempting its first pioneer day, following the concept of the AFIPS pioneer days, which will be held in Hamburg next year. We've seen many things happen; the history of computing has come a long way in 15 years. It involves many more interested and interesting people, several archival institutions, textbooks, and publications, one electronic bulletin board, an annual computer trivia game---~he Computer Bowl--and a TV series which won the 1992 Peabody Award for Journalism. It is also changing; we are finally beyond the phase of merely collecting and preserving our heritage. We have to work seriously on analysis, evaluation, and application. We have come a long way since 1978. Let's get on with it; let's have a conference.
Editor's Note: Due to space limitations, welcoming remarks by Gwen Bell President of ACM, and Stuart Feldman, Chair of SIGPLAN were deleted, as were the remarks of the Program Chair, Jean E. Sammet.
INTRODUCTION OF FREDERICK P. BROOKS, J R . PROGRAM CHAIR,JEANE. SAMMET: The Program Committee thought long and hard about selecting a keynote speaker. We wanted someone who had been around for quite a while [audience laughter]--you may interpret that phrase any way you want; but since most of us on this platform have been around for quite a while it seems allright to say that. We also wanted somebody who had a very broad background in the general field of computing (not necessarily limited to programming languages), but we did want somebody with significant work in software. Fred Brooks has had a very distinguished career and I can only indicate some of the highlights. He received a Ph.D in 1956 in Applied Mathematics from Harvard University, and his advisor was the legendary Howard Aiken. (If there are any of you in the audience who are young enough not to know who Howard Aiken is, then perhaps that is a good reason for you to go and study something about the history of the hardware.) Dr. Brooks founded the Computer Science Department at the University of North Carolina at Chapel Hill in 1964, and served as its chair for 20 years. He remains on the faculty there. He worked at IBM from 1956 to 1964. While he was there, he served in two major capacities. One was as the manager of the IBM System/360 hardware development and the corporate processor manager for the System/360. So he was largely the technical guiding light behind the S/360. His second major capacity at IBM was as manager of the OS/360 development. So he really handled the 360 from both the hardware and software sides. Prior to his work on the 360, he participated in the development of STRETCH and HARVEST at IBM; they were pioneering computers to push the state of the art in several directions. Dr. Brooks has received numerous honors--far too many to list all of them. Among others, he received the National Medal of Technology, the AFIPS Harry Goode Memorial Award, the IEEE Computer Society McDowell Award, the ACM Distinguished Service Award, the DPMA Computer Sciences Man-of-the-Year award, election to the National Academy of Engineering, and just recently, the John von Neumann medal from the IEEE.
THE OPENING SESSION
3
FREDERICK P. BROOKS, JR.
Dr. Brooks has served on numerous advisory boards and boards of directors. He has authored or co-authored over 70 papers or book chapters. Probably his best known publication is his book The MythicalMan-Month: Essays on Sof~are Engineering. He is going to talk here on "Language Design as Design."
KEYNOTE ADDRESS: LANGUAGE DESIGN AS DESIGN
Frederick R Brooks, Jr. When Jean called and said what she wanted me to talk about, I said I had not done any thinking about that and didn't see any opportunity to do any. I considered that an impediment to talking about it. But I had done some thinking about another subject that I would be glad to talk about. She said, "All right." Hence today's topic. (SLIDE 1) I have been especially interested in the process of design. So I welcomed the opportunity to speak to a room full of experienced designers and to share some of my thinking to date. Because this is in very earl,.,, stages of formulation, I should like to ask you at the breaks, at lunch, and at the reception, to share with me your thoughts on the design process. Here are the subtopics: • What is the ,design process? • Why should anyone do language design now? • Some principles for how to do design • The role of esthetics in technical design • An assertion about the nature of design, namely, that great designs come from great designers, not committees. (SLIDE 2) The Oxford English Dictionary defines design as "To form a plan or scheme of, to arrange or conceive in the mind for later execution." That's a sufficiently general definition. (SLIDE 3) I have had the opportunity in my life to work on five machine languages, three high level languages, a laalf a dozen molecular graphics tools, some application systems in virtual reality, and four buildings.
L a n g u a g e D e s i g n as Design
Design
1. What is the design process? 2. Why do language design now?
"To form a plan or scheme of,
3. Some design principles
to arrange or conceive in the mind...
4. Esthetics in technical design
for later execution." OED
5. Great designs come from great designelrs SLIDE 1
4
SLIDE 2
CHAPTER I
KEYNOTE ADDRESS: LANGUAGE DESIGN AS DESIGN
Why Study Design?
Why Study Design?
My design experiences:
As a Principal
As a Participant
$ computer architectures
S/3(dl Mocroassembler
APL
PILJI
GRIP, GRINCH, GROPE
VIEW, SCULPT
Wolkthrough
Several VR systems
Beach house
Computer Science bldg
Home wing
Church fellowship hall
SLIDE 3
• These experiences are more alike than d i f f e r e n t ! • Can w e d e s i g n better by studying design as a process?
SLIDE 4
(SLIDE 4) The conclusion I reach is that the experiences across these fields--hardware, programming languages, computer application systems, and buildings--are more alike than different. So the intellectual question is "Can we design better by studying design as a process?" (SLIDE 5) Engineers think of design in a very simple-minded way. You have a goal; you have some desiderata; the desiderata combine in a non-linear utility function. You have a slue of constraints that form budgets, and one of these is critical. It is not always dollars, but there is always a critical constraint. You have a design tree of possible decisions. You make the various decisions, working your way down the tree by a very straightforward process. (SLIDE 6) Until the design is good enough or you don't have any more time, you keep trying to improve the utility function. And until the design is complete, you make another design decision, as long as you have a feasible design. When you don't, you backtrack, and you explore a new path. When you have to quit, you take the best design that you have so far. That is a rational design process. (SLIDE 7) Now what is wrong with this simple-minded model? The first difficulty is that we rarely really know the goal. I will assert that the hardest part in any design is deciding what it is you want to design. I have found that to be true across the spectrum of different kinds of designs. Second, the place where experts go wrong is that the vision is either not high enough or not fresh enough. The mini and micro revolutions are good examples of where the experts were plowing on in conventional courses while an entirely fresh vision was waiting in the wings. The third difficulty is that we usually don't know the design tree until we get into it.
How Engineers Think of Design • Goal • Desiderata • Non-Unear utility function • Constraints, especially budget (not necessarily $ cost) • Design tree of decisions
SLIDE 5
THE OPENING SESSION
Engineers' Design Model UNTIL ( "gnod enough") or (no mare time) DO another design (to improve utility function) UNTIL design complete WHILE design feasible, make another design decision END WHILE Backtrack up design tree Explore a new path END UNTIL END DO "l~he best design END UNTIL
SLIDE 6
5
FREDERICK R BROOKS, JR.
~
What's
Wrong
with This Model?
• We don't really know the goal at first The hardest part of design is deciding what to design. • Where eXl~erts go wrong • Vision not high enough - e.g., JCL • or fresh enough - e.g., minis, micros • We usually don't know the design tree.
SLIDE
7
What's
Wrong
with This Model?
• The desiderata keep changing. • Schi~n - "One wrestles with the problem." • As one in fact makes the tradeoffs, the weights change. • S o m e t i m e s one hits new opportunities. • T h e constraints keep changing. • S o m e t i m e s by inspirationl Genius is finding the third w a y ! • Often by the e v e r - c h a n g i n g world. SLIDE
8
(SLIDE 8) Fou~r'th, and most important, the desiderata keep changing. In the design of a house wing that we completed two years ago, we found that the breakthrough on the design came when we finally realized that a critiical function that we had not at all taken into account was where to put the coats of guests when they came to large functions. That warped the whole design. I added a room at one end and took another away at the other end of the house. But that is the kind of thing that happens in the middle of the design process. As Donald Sch6n, Professor of Architecture at MIT and one of the people who has written important books on the theory of the design process, says, "One wrestles with the problem." As one, in fact, makes the trade-offs, the weights change. I have found that to be uniformly true. I would be interested in whether you find that true. As you get into it, things that you thought were important seem to become less important; things you thought unimportant become more important. Sometimes, one hits new opportunities. The things that you have already designed make it possible to put in at very low cost things that you have not thought about as desiderata, and yet you are able to realize those opportunities. Then the constraints keep changing--sometimes by inspiration. I have worked many years with Gerrit Blaauw. Gerry Blaauw is one of the very best machine designers in the world. He has an uncanny gift for taking cases that look like one has an unfortunate choice on this side versus an unfortunate choice on that side, and finding a third way where no one could see there was one at all. I think that is part of the genius of design. In the house wing experience, we wrestled with one problem: how to make the music room work. It had to hold two pianos, an electronic organ, a string octet, and a one-foot working strip for a teacher. The constraint wa:~ a set-back requirement. Nothing would work. Finally, the answer was to buy a five-foot strip of land from the neighbor. It unlocked the design; it made the whole design possible. I have seen the same thing happen in machines. Sometimes the right answer is to change the constraints by a process completely orthogonal to the design process itself. How do we know when to even try to do that? The other thing that happens is that the ever-changing world around us keeps changing the constraints for us. And these changes are not always advantageous. (SLIDE 9) Why should anybody today undertake to do computer language design? This is probably a question that never crossed your mind. The first possibility: Do we want to just redo the old ones better? Well, I am the person who tried to displace FORTRAN with PL/1. That was not a winning undertaking. Part of the reason is that as the field evolves, the marginal utility of the next step goes down, down, down. Also there is the principle that Gerry Blaauw has called the persistence of established techno,fogy. That was the one we ran up against with FORTRAN. As a competitive threat
6
CHAPTER I
KEYNOTE ADDRESS: LANGUAGE DESIGN AS DESIGN
Why Do Language
Design
Now?
• To redo old ones better? • Need new ones? For new algorithms n especially parallel To embody new concepts • To get published? • Becatt~e It is fun? • As a discipline for thought?
SLIDE 9
~I
Programming Languages and Software Building • Software productivity 5 x for Fortran Much more for Excel, LISP, Smalltalk • Software reliability If you can't say it, you can't say it wrong. • Concepts for communication • Concepts for algorithms
SLIDE 10
appears, the established technology starts evolving and moving to accommodate the same needs within the old framework. (SLIDE 10) What have the existing high level languages contributed to software? The first step, the FORTRAN step, has been measured at giving about a five-to-one productivity improvement. It gives perhaps a ten-to-one improvement in the number of statements. But the statements are longer and a little complicated, and it cooks down to about five times over assembly language. If one looks at special-purpose application domains, and looks at the power of languages such as the Excel spreadsheet, or LISP, or Smalltalk, each in its own domain, the productivity improvements of today's high level languages are much higher than that original step function. Well, what idea do you have that is going to give anything like another five-times productivity improvement? This is the low marginal utility point. The second, and maybe most important, step that high level languages have already contributed to programming is software reliability, because of the elementary principle that if you cannot say it, you cannot say it wrong. The details that are suppressed, or abstracted, or implied are a whole host of ways that you used to go wrong. Either conceptually, or just syntax, or even typos, you cannot go wrong there anymore. The most important contribution, I think, is that high level languages by their abstraction have given us ways of thinking and ways of talking to each other. So we routinely talk about concepts such as binding time. One thinking in assembler just doesn't think about binding time. We routinely talk about recursive-descent parsing. A whole new concept, not only useful for communication, but one that leads to other ideas. The whole technology of high level languages, including their compilation, has contributed ideas for doing other algorithms. (SLIDE 11) So I think that the notion of redoing old programming languages to make marginal improvements in them is not a motive that would drive one to do language design. Well, why do we? Is it because we have a desperate need for new high level languages? In fact, I think we do. In the first place, we need new languages to express new algorithms. The place where we are feeling that crunch most keenly today is in concurrency, parallel algorithms, and massively parallel data types. I consider an SIMD machine to be one that has special data types and is not really a multiprocessor. The most important reason is to embody new higher level concepts. Let me come back to that in a moment. One reason for designing new languages that seems to be very common is to get published. The national president of the Humane Society pointed out that this country is about a million puppies and kittens over what would be a normal population. The Society has called for a one-year moratorium on the breeding of any more dogs or cats in the United States. I am tempted to call for a similar
THE OPENING SESSION
7
FREDERICK R BROOKS, JR.
Why
Do Language
Design
Now?
• T o redo old ones better? • Need nt:w ones? F o r n e w algorithms - - especially parallel T o emlmdv new concepts
Language
as Concept
Carrier
• Detailed enough for execution. • Maximize (Shannon Information ffi surprise). • Abstract out redundant detail. • Carry most required detail by Implication. • Define classes, each with shared properties.
• T o get published?
• Class usefulness depends upon frequency.
• Because it is fun?
• Same program as Mathematics. • A s a discinline for thought? v
SLIDE
11
SLIDE
12
moratorium on new computing languages, because much of our literature has the same property as kittens--it has a negative price; you have to pay people page charges to take it away. (A new language that embodies new concepts should be designed and should get published.) Maybe the best reason to design new languages is because it is fun. Designing anything is fun. But it is also an important discipline for thought. J.R.R. Tolkien, the author of The Lord of the Rings, in his professional youth as a philologist undertook to design a language he called "High Elvish." He designed the who]le language, the lexicon, the syntax, the semantics, the whole bit. Somebody asked him, "Why go through a really vacuous kind of exercise of making up a natural language, High Elvish?" He said, "One doesn't really understand the bones of language until one has tried to design one." I think he is quite right. Of course you see the richness of that exercise in his writings. It colors and illuminates and glorifies various parts of his writing. But I think the important thing it did for him professionally was to help him understand all language. (SLIDE 12) The same thing is true as a reason for undertaking to design a programming language. This slide I want to discuss quickly because you can do it better than I could. If we look on language design as a discipline for the mind in understanding languages, we see that the design program looks like this. We have., to make the language detailed enough for execution. That gets rid of much arm waving about algorithmic and data concepts. Next, we want to maximize the Shannon information, that is, the surprise. This means we want to abstract out the redundant detail. There is required detail if one is going to make a language detailed enough for real execution. The technique that has developed through the decades is to carry most of the required detailts by implication so that you don't have to state it but once in the whole process. Today that means defining classes, each one of which has shared properties, and then determining what you can do with the class as a logical consequence of the properties that have been defined for it. I will observe ill passing that the usefulness of difl~rent classes depends on their frequency of use. If you look back over this research program, it is exactly the same program as has characterized mathematics through the years. What we do is define a class of things, a set, or a group, or a ring. Define its properties exactly, and then see what corollaries follow from that set of properties and no other properties. I 'would assert that the undertaking of defining a programming language intellectually is essentially the same program as the classical program for mathematics. That is the reason why language design is', a good exercise. Language design is a discipline. Let me turn to tbe second part of the talk, and talk about some design principles. Here I am treading boldly on dangerous ground, because I am talking about design principles in your field, when I am not a language designer. Therefore I am more subject to correction and would appreciate it. (SLIDE 13) The first principle: Design a language; don't just hack one up. 8
CHAPTER I
KEYNOTE ADDRESS: LANGUAGE DESIGN AS DESIGN
Design Principle I
The Worst L a n g u a g e - OS/360 J C L • One job language for all programming languages • Like Assembler language, rather than P L / I , etc.
Design a language;
• But not exactly like Assembler
• Card-column dependent
don't just hack one up.
• Too few verbs • Declaration parameters do verbish things • Awkward
branching
• No clean iteration • N o clean subroutine call
SLIDE
13
SLIDE
14
(SLIDE 14) People will debate forever about what is the best programming language ever designed. But I expect no challenges when I offer a candidate for the worst programming language ever designed, OS/360 Job Control Language. You are familiar with its faults, so I won't dwell at length. The biggest mistake was making one job language for a system that was intended to run many different programming languages instead of one per programming language. What is worse, at the same time that we were shifting to high level language usage, we made the job control language at the assembler level. But not exactly like the assembler, just incompatible enough to make a nice little mess of rules. It is card-column dependent, so really awkward on a teletype and worse on a terminal. Too few verbs; the boast of the designers is that it had only six verbs. Yes, but you cannot say what you have to say with only six verbs. So guess what? The declaration parameters do verbish things all over the place. There was a discipline that said, "No verbs," but there was no discipline saying, "No more declaration parameters," and they multiplied. The branching is extremely awkward. There is no clean iteration, and there is no clean subroutine call. And you can add favorites of your own to this list. (SLIDE 15) I was not a designer of the Job Control Language, but it was done under my management. Like the Attorney General and the Branch Davidian fiasco, I have to take responsibility for it. It is instructive to look at major mistakes so let's see what lessons we can learn from this one. The basic problem was pedestrian vision. We did not see it as a programming language at all. Those words never came anywhere near the JCL project. There were programming languages in the same overall, OS/360 project, but the concepts and the people familiar with those ideas never came near the Job Control Language team. Instead, it was seen as, "We will provide a few control cards to let people tell the Scheduler what to do with the jobs." Then it was not designed, even as a few control cards; it just grew as needs appeared during the definition of the operating system scheduler. (SLIDE 16) I think JCL is typical of the fact that programming languages appear in many different guises. We have machine languages. I have spent the last twenty years thinking about machine languages. You probably called them assembler languages. But for the computer architect this language design is a major concern. Machine languages are a specialized set of programming languages in which high level is not in fact possible. In machine languages, utterances are costly. The static bit budget is one of the two principal criteria for excellence. The utilization of the memory bandwidth, that is, the dynamic bit budget, is the other criterion for excellence. So, many of the things I say come from these experiences of working with languages in which every bit counts. Job control languages are languages in disguise. Shell scripts are languages in disguise. Spreadsheet languages are languages in disguise. I will be teaching the computer literacy course next year, "Power Tools for the Mind," a course in which students become acquainted with applications. How THE OPENING SESSION
9
FREDERICK R BROOKS, JR.
The Worst Language--OS/360 JCL
Languages in Disguise
• Done und,er my management.
• M a c h i n e l a n g u a g e s m u t t e r a n c e s a r e costly
• Basic problem was pedestrian vision.
• Job control languages
• We did not see it as a schedule-time programming language at all, but as a "few control cards."
• It was not designe~ it just gt~ewas needs appeared.
• Shell scripts • Spreadsheet languages • Interaction motion languages
SLIDE 15
SLIDE 16
are we going to sneak up on programming and spreadsheets? The things you put in the cell are, in fact, utterances in a programming language. As soon as you get away fi'om constants, it becomes obvious that those expressions are languages. Then in working with interactive systems of all kinds, whether 2-D or, in my field, 3-D interactive systems, we have motion languages for which we do not even know the lexicons or the grammar. But we do know that it is useful to think in terms of sentences and utterances and responses. We are at the primitive stage of understanding the linguistic content of interactive protocols. So I would assert that one of the reasons to think about language design today is not that there are so many undone jobs with the old procedura]l languages, but that there are so many areas in which we do programming language design without bringing to bear what we have learned about language design. (SLIDE 17) The second design principle: Study other people's designs. I would assert that the characteristic of an amateur in any design field is that he brings to the task his own experience, period. And the trained professional brings to the task the whole craft's experience. Bach walked 60 miles to copy Buxtehude's music and Buxtehude's collection. Bach was a much greater composer than Buxtehude, but not at the time he did that. He was stronger because he undertook the mastery of the arts of his predecessors. The Bach biographies identify perhaps ten musicians whose works he especially studied in detail to see what they did and to try to figure out why they did it. I think that is still a valid and fruitful undertaking.
Design Principle 2
Study Matrix for Languages API,
Study and use other people's designs.
Oberon
C
Fortran I,ISP
Data Ops
Amateur
-- draws on own
experience
Professional m draws on craft's experience
Naming Control
Syntax
SLIDE 17 10
SLIDE 18 CHAPTER I
KEYNOTE ADDRESS: LANGUAGE DESIGN AS DESIGN
(SLIDE 18) I have found this kind of matrix to be useful for looking at machine languages. That is, to identify in many lines what we call the design decisions. What the data types and data structures will be, for example. What the operations proper to those data types will be. For example, the whole system of naming and binding, the whole system of sequence control and the syntax. I think it is fruitful to study across this direction. Take a design decision and look and see how the different languages have done it. We have been doing that for machine languages. It is essential, however, to also study down the column direction, because the principle of consistency means that if you are going to have any conceptual integrity for the language at all, everything in the column has to work together. But I think much of the surprise comes in looking along the rows. (SLIDE 19) One of the things we, and many people, have observed is that in any kind of design process, designs that are all-new are relatively rare. And most designs start with go-bys. That is, you have an example in front of you to use as a conceptual base on which to make major or minor structural modifications in the design process. I will remark in passing that the opportunity to do an all-new design is really wonderful. They are very exciting to do--to go into a new area where there are not any go-bys--~ut you do not get many such chances in a lifetime. Since go-bys are important, it is important to do the collection of specimens. This is why the HOPL documentation is important. This is why Jean Sammet's language book is very important. The collection must capture the artifacts of previous designers in enough detail that you can understand and see the whole design, not just a casual description. Even a technical paper does not usually capture all the details necessary. Moreover, collecting rationales behind the designs is important for the serious student of the design. I will maintain that as a design discipline matures, it grows from first collection, to then criticism (I use that in the normal sense of looking at the virtues as well as the flaws), to analysis, and then finally to synthesis rules for how one should do a new design. (SLIDE 20) The third design principle applies to all the areas of design that I am familiar with: Design top-down. You may have to build bottom-up, but it is important to design top-down. (SLIDE 21) If we ask ourselves what it means to design top-down in the language area, I find that, at least for machine languages, these are the principal elements of design. The data types and data structures are crucial, and yet the designer has not a lot of freedom here, because the data types follow from the application domain. If you have carefully specified the application domain, then imagination can ~show you powerful and natural data types and data structures. But they do grow out of the application itself. Likewise, the operations follow from the data types one has chosen. The whole notion of an operation set as being proper to a data type is, I think, very powerful. Where the designers
The Role of Go-By's
Design Principle 3
• Few designs are all-new; (but those surely are fun!) • Most designs start with go-by's. • Collection of specimens is important.
Design top-down.
• A design discipline grows from collection, to criticism, to analysis, to synthesis rules. SLIDE
THE OPENING SESSION
19
SLIDE 20 11
FREDERICK R BROOKS, JR.
Language
j
Elements
• Datatypes and data structures - - from application
Principle
4
Know the application area well.
• Operations m proper to datatypes
Describe Its properties and frequencies precisely, even If inaccurately.
• Names Binding times=and semantics Structure naming • Control structures Including concurrency
•
Design
Make up frequencies, if necessary. t
Languagehood It is better to be wrong than vague.
• Syntax
SLIDE 21
SLIDE 22
really cut loose are in names, binding times, and naming semantics. The whole question, once I have picked a data structure, of how I do sub-structure naming, leaves great room for bringing new ideas to bear. Then we come to control structures, because in any computer there are indeed sequences. Today the important issues are: How do I specify the opportunities for concurrency and the mandates for synchronization? Finally, what is a natural syntax? That which makes it easy to say what one means is a crucial part of language design. I call these components languagehood. In a machine language I called them machinehood. These are things that are essentially independent of the application, although which direction you may choose to go on some of these designs may be influenced by application characteristics, especially frequencies. But they have more to do with what Tolkien calls "the bones of a language," whereas the earlier design decisions follow more from the careful definition of the application domaiin. As we look over high level languages, it seems to me that we see more powerful concepts and more exciting concepts in these languagehood areas as the languages have evolved. (SLIDE 22) Design principle four: Know the application area well. One o f the paradoxes of design is it is more difficult to design a general purpose object than a special purpose object. One of the exciting things thtat has happened in high level language design is the proliferation of specialized languages. The spreadsheet language is an example, but not the only example. Simulation languages, logical languages, functional languages, the whole set goes on and on. Therefore the first thing that the designer has to do is to describe the intended scope of use of the language, its domain. I tell my students when they are setting out to do this to describe the properties and frequencies of the application precisely, even if inaccurately. Notice that the frequencies are as important as the properties; if we ~lpproach design from a mathematical point of view, we are apt to overlook that. But if we approach it from an information-theory point of view, we cannot ignore the frequencies. I assert that it is useful to fabricate or postulate frequencies if necessary. In stating and defining precisely the domain of a language's application, it is better to be wrong than to be vague. Why would anybody with reasonably good sense assert a fool thing like that? Because, if you write down the assumptions about frequencies and say, "This is the set of frequencies I believe exists out there," then it is public and open to criticism by other members of the design team and the potential users. Furthermore, you might get illuminated by people offering facts you didn't know about as to what the real frequencies are. So, (A) you might get different opinions to help you modify your view of what the frequencies are, and (B) you might learn the true facts. Consequently, this kind of anti-intellectual approach says, by all means, make up missing frequency data, don't be vague. (SLIDE 23) Design principle five: Iterate the design with independent test problems. As any experiment designer knows, you can pilot with one set of test problems as your driving problems 12
CHAPTER I
KEYNOTE ADDRESS: LANGUAGE DESIGN AS DESIGN
Design Principle 5 Iterate • with independent
test problems
• with real users other than yourself
R a t i o n a l i s m vs. E m p i r i c i s m i n D e s i g n • Aristotle vs. Galileo; France vs. Britain; Descartes vs. Hume; Napoleonic law vs. Anglo-Saxon law
• Wegner: Prologvs. Lisp; Algol vs. Pascal; Dijkstra vs. Knuth; Proving programs vs. testing programs • I am a died-in-the-wool empiricist.
SLIDE 23
SLIDE 24
during a design of an experiment. Then you must run a different set to see how it came out. Each of us, in doing a design, first programs some things ourselves in our language; these examples become the driving problems of our design. It is not a sufficient test to then see how well we can write them in our own language. (SLIDE 24) Now from this whole notion of trial and error to a much more fundamental issue, and one that Peter Wegner has described. I saw it first in a brochure from the Brown University department, but he has now put it in a paper. He says there is a long-running tension between rationalism and empiricism in design. You can see it in Aristotle versus Galileo; in French intellectual thinking versus British, as epitomized by Descartes versus Hume; in Napoleonic law about how things ought to work versus the Anglo-Saxon law that says we won't know until we've seen some cases. Then Wegner goes on to talk about some examples of Prolog versus LISP, A L G O L versus Pascal, Dijkstra's approach to life versus Donald Knuth's, and (I threw in, gratuitously and debatably) proving programs versus testing programs. My position is very clear. I am a dyed-in-the-wool empiricist on this black/white map. (SLIDE 25) I would assert there is no hope of getting our complex designs right the first time. The things we programmers make now are as complex as anything the human race has ever made. A major airplane is nowhere near as complex as a major operating system in terms of the number of different elements and different relationships among them. There is no hope of getting them right the first time by pure thought. To expect to do so is arrogant; a little bit of professional humility goes a long way here. That means we have to adopt design and building processes that provide for evolutionary growth. That is, versus the classical waterfall: specify, design, build. It is also evolutionary growth in many stages versus the simplistic notion I put in The Mythical Man-Month: plan to build one, then throw it away and start over. Instead, we may not have to throw designs away, but we certainly have to plan to grow them bit by bit. I remember how shocked I was the first time I ever heard a person talk about building a program as opposed to writing a program. It was a whole new idea for me. Well, it is equally shocking and equally important to think about growing programs as opposed to building programs. I think Harlan Mills first put that clearly in my mind; it is a really important idea. This means that we also have to be prepared to throw away, if necessary, and we have to iterate. If iterating means making working prototypes of some kind and testing with real users, that is less difficult in language design because we can fake the compilation with hand compiles. (SLIDE 26) Let me say a few words about esthetics. Even invisible designs have an esthetic, and it shows in the way we talk about them. We talk about a clean machine. What is a clean machine? We THE OPENING SESSION
13
FREDERICK R BROOKS, JR.
Rationalism vs. Empiricism No hope of getting our complex designs right first tJime by pure thoughL To expect to is arroganL So, we must adopt design-build processes with • evolutionary growth vs. waterfall specify-design-build, vs. "Plan to throw one away." • iteration~, and restart if necessary • early pr~,totyping and testing with real users
SLIDE 25
~
Esthetics in Technical Design • Even invisible designs have an esthetic: • A "clean" machine • An "elegant" language •
Elegance: "Accomplishing many things with few elements."
• Not enough. Need straightforwardness, too. • van der Poel's one-instruction computer • APL one-liner, idiomatic style
SLIDE 26
have an implicit set of esthetic principles about what a clean computer is. We talk about an elegant language. What is elegance? One dictionary definition says "accomplishing many things with few elements." Ken Iverson said what they tried to do with APL was make it so that if you knew a construct and you wanted to know another construct, you could figure it out without knowing, and "It does what you expect it to do." This assumes that everybody would expect it to do the same thing. Elegance is not enough. This, I think, has often been overlooked. One needs straightforwardness, too. Van der Poel built a magnificent little computer that had only one operation code. It is a marvel of ingenuity. Van der Poel's coding for it is a marvel of ingenuity. No one else has ever coded for it, as far as I can tell. Van der Poel is a great designer, and he also carves intricate little Chinese puzzles for a hobby. I am a fan of APL, but I am not a fan of the one-liner idiomatic style in which the purpose of the designer is to make the program as obscure as possible under the guise of calling it elegance, or to see what cart be done by idiomatic, that is, weird, uses of operators for purposes that were far from their original intention and definition. This means we have counter-balancing forces between elegance and straightforwardness in a language design. (SLIDE 27) Here are a few principles that certainly apply to machine languages. The consistency principle can be e]laborated into orthogonality, propriety (that is, make sure you don't have anything there that doesn't belong), and generality (making sure you don't leave out anything that does belong). Leave plenty of room to put more function in as evolution occurs. And if you notice a certain tension between those--yes, any such design is a tight-rope act between countervailing forces. The skill of the designer is a balancing skill, a judgment skill. It is not a mathematical evaluation skill of measures of propriety and of generality. Now I will asse,rt but not debate today, for lack of time, the thesis that "Good esthetics yields good economics," even in computer language design, where economics is severe. This has to do with an argument that one., wants to minimize long-run overall cost, and that the cost of what you save by doing things dirtily will be more than paid for by instruction and maintenance over the lifetime of the artifact, if your artifact has any lifetime. (SLIDE 28) Some years ago I wrote down a little thought experiment, and I set a different criterion from one you usually assess with. And that is, what languages or software entities have fan clubs? By fan clubs, I mean fanatics, people who think the language is really great. Well, here is my list: FORTRAN, Pascal, C, IBM VM System, Unix, Macintosh, and APL. What are successful, widely used, effective, valuable contributing products that I never saw any sign of a fan club for? COBOL, ALGOL, PL/1, OS/360 and today's descendant MVS/360, DEC's VMS, and PC DOS. What is the difference? I think the difference is that the things on the left were originally designed to satisfy a
14
CHAPTER I
KEYNOTE ADDRESS: LANGUAGE DESIGN AS DESIGN
Esthetics in Design •
- few concepts • Orthogonality
Consistency
• Propriety: parsimony and transparency • Generality: completeness and open-endedness • Thesis: Good esthetics yields good economics.
SLIDE 27
lit
Designs with Fan Clubs Yes
No
Fortran
Pascal C
Cobol Algol PL/1
VM
MVS/360
Unix
DEC VMS PC/DOS
Macintosh
APL SLIDE 28
designer or a very small group of designers. And the things on the right were designed to satisfy a large set of requirements. (SLIDE 29) Great designs come from great designers, not from great processes. The issue is conceptual integrity of the design. A solo design is much likelier to have conceptual integrity than committee design. If we go back and look at that list, the ones on the left were done outside of product processes. All the ones on the right were done inside of product processes. What does that tell us about software product processes? They produce serviceable things but not great things. I was on a review team with another reviewer who was a Marine general (retired) who spent his entire life building military aircraft. We were reviewing the design for the LHX helicopter. The colonel who was briefing us went through how the LHX would jump up and sail over the woods in the dark rainy night, and pop up, and shoot, and jump back down. Then without batting an eyelash, he said, "It has to ferry itself across the Atlantic." No one who had ever designed anything could be insensitive to the damage that putting that requirement on is going to do to all the operational characteristics. This ferrying is a one-in-a-plane's-lifetime task. Twice, if you are lucky. "Why does it have to do that?" "Oh, there are not enough C5's to carry them." "Why don't you take some of the money from the LHX budget and buy some more C5's ?" "We can't do that." But the problem was that this was a unified set of requirements laid on by a committee from various services. The committee included, when the smoke cleared, military bureaucrats and civilian bureaucrats, but neither helicopter pilots nor aircraft engineers. Have you ever heard such a story before, closer to home? This raises three important issues that we have to face: • What are product procedures for? I think they are for making follow-on products. • How does one do great designs within a product process? That's hard. • How does one make a product process that encourages rather than inhibits great designs? (SLIDE 30) Well, where do great designers come from? We have to grow them deliberately, and that means we recruit them for design brilliance and not just meeting skills. One of the very best language designers I have ever known was totally incapable of holding his own in any meeting. We
THE OPENING SESSION
15
JEAN E. SAMMET
Great Designs Come From Great Designers
Where Do Great Designers Come From?
• C o n c e p t u a l integrity - - Solo vs. committee design • W i t h i n vs. outside product-process; W h a t a r e p r o d u c t p r o c e d u r e s for? • T h e L H X heliicopter " a n d ferry itself across the A t l a n t i c . " • How does onc do g r e a t designs w ~ h b l process?
a product
• H o w to m a k e a p r o d u c t process t h a n encourages, r a t h e r thaN, inhibits, g r e a t designs?
SLIDE
• Grew them de//~rate/y. • Recnfil for drslun brilliance, not jusl talking skills. • Make the dual ladder real and henoreble. • Career p h i n i n g and t r a i n i n g , j u s t IW h w managers • Meu|¢lgll
• Mmage them imaginatively. • The Stolnmetz story • The John Coeke story • Prelect them fiercely. • Fntm managers • Ftxtm numaglng
29
SLIDE
30
have to make the dual ladder real and honorable. We have to plan their careers and the rotation of training experiences just as we do for managers. We have to furnish them with design mentors. We have to manage them imaginatively. Two great case histories I commend to you are those of Steinmetz, who invented alternating current theory as applied to iron, and John Cocke, inventor of pipelining and RISC. We have to protect them fiercely, from both managers and management.
FROM HOPL TO HOPL-II (1978-1993): 15 Years of Programming Language Development
Jean E. Sammet JEAN E. SAMMET: The Program Committee felt that it might be of some interest to you to get two pieces of information. One was some perception of what has happened in the programming language area in the last fifteen years, and then a little bit of introduction to making history, particularly for those of you who were not at the Forum yesterday. (SLIDE 1) I arn about to give you Sammet's insight into what has happened in the last 15 years of programming language development. As I am sure all of you recognize, that is a major undertaking and each one of you might choose to do it completely differently than I did, but I have control of the microphone so you are out of luck! (SLIDE 2) In 1978, according to the data that I had--and some of you may recall that for about ten years I tried to publish what I called the Roster of Programming Languages to keep track of what was available and in use in the United States. The only reason for restricting it to the United States was that I had enough trouble trying to get my hands on that data without worrying about what was in Europe as well You see the numbers that are in Slide 2. Please note, in particular, the languages for specialized application areas, which I will say more about later because they represent a little over half of them, and that has been a fairly consistent pattern even though many of my computer science and programming language guru friends don't like these, don't care about them, and don't think they belong. I do. (SLIDE 3) The HOPL criteria for the selection of invited languages are shown here. The criteria were simply that they were ten years old, still in use, and had a major impact. (SLIDE 4) Just for the sake of the record, I am showing the 13 languages that were considered to meet those three criteria in 1978. Of these, I think it is fair to say (and certainly quite accurate) that both ALGOL and JOSS are relatively dead by now. JOVIAL is maybe not quite dead but certainly
16
CHAPTER I
FROM HOPL TO HOPL-II (1978-1993) "From HOPL to HOPL-Ih
(1978-1993) 15 Years of Programming Language Development" Jean E. Sammet Programming Language Consultant (Program Chair, ACM SIGPLAN HOPL-II)
WHERE WE WERE IN PROGRAMMING LANGUAGES IN 1978 Approximately 170 languages used in US Numerical scientific Business data processing Stdng & list processing Formula manipulation Multipurpose Specialized application
SLIDE 1
20 4 11 10 34 90
SLIDE 2
dormant, having been essentially replaced in the military area by Ada. SIMULA 67 has essentially been overtaken by Smalltalk and some of its derivatives. (SLIDE 5) Here is a personal view of what I consider major languages in 1978. The criteria I used for major was either use, or lots of publications, or lots of implementations, or any combinations thereof. I think the only one that you might question would be APT and that turns out to be one of the major specialized application area languages implemented on almost all computers. (SLIDE 6) Here is a list of some more languages and again this is simply an arbitrary decision on my part. These are justsome things that I thought would be interesting and of value to put on the foil. (SLIDE 7) This shows a few of the ninety specialized languages. These are for application areas that are sort of outside of the normal computer science-oriented mainstream. For those of you who are not familiar with these, let me point out that ATLAS is for writing programs to test equipment. COGO is for civil engineers, particularly doing surveying. COURSEWRITER is a CAI type language. GPSS and SIMSCRIPT are simulation languages. Pilot is another CAI language. SCEPTRE is for electrical design. (SLIDE 8) This is perhaps the most interesting. Please realize that 15 years ago, these languages were on the horizon. They essentially didn't exist. Ada was still (in at least early 1978) being called DoD- l, but certainly was in the phase of competitive design. At that stage, Smalltalk 80 was obviously not in existence.
PROGRAMMING LANGUAGES In 1978
PROGRAMMING LANGUAGES in 1978
HOPL Criteria
HOPL Languages
• over 10 years old
ALGOL
• still in use • major impact
APT
JOSS JOVIAL LISP SIMULA 67 PL/I
APL
BASIC COBOL
FORTRAN GPSS
SLIDE 3 THE OPENING SESSION
SNOBOL
SLIDE 4 17
JEAN E. SAMMET
PROGRAMMING LANGUAGES In 1978
PROGRAMMING LANGUAGES In 1978
M~ljor Languages
Some Other Languages
(based on use and/or publications and/or ninny Implementations) APT BASIC COBOL
FORTRAN LISP 1.5
SLIDE $
ALGOL 60 APL ALGOL 68 C FORMAC FORTH
MACSYMA MAD MADCAP MUMPS Pascal
JOVIAL
PL./I Simula 67
JOSS
SNOBOL4
SLIDE 6
(SLIDE 9) I am a great believer in standards and the importance thereof. So note that in 1978, we had standards for ~thelanguages listed. Note that APT and ATLAS, which were two of the specialized application areas, had standards, and in fact APT had two.standards. (SLIDE 10) There were some other things going on besides languages per se. Among the buzz words and the related topics at that point were structured programming, software engineering, and systems programming languages, because people were still very worried about whether you could really write systems programs effectively in high level languages. (SLIDE 11) In the 1980s, in my opinion, there were only two significant pure language developments. I am not t~lking about peripheral concepts and peripheral ideas. But in the 1980s, there were the standardization, implementation, and use of Ada (which did not even exist in 1978), and the significant use of C for systems programming and its beginning use for other areas. (SLIDE 12) But, there were other things going on in the programming language field in the 1980s. This involved an emphasis in areas other than pure language development. These are the ones that I put on the chart. ~nguage bindings is the attempt to develop some frameworks and subroutines in topics that are of importance in and across many languages; graphics is the prime example with GKS. Then later, is the database SEQUEL stuff. Fourth generation languages is a term I hate and despise, but I felt to be fair and complete I ought to put it on there. The application packages--as distinguished
PROGRAMMING LANGUAGES in 1978
PROGRAMMING LANGUAGES in 1978
Some Specialized Languages
On the Horizon
ATLAS COGO COURSEWRITER GPSS
SLIDE 7
18
PILOT SCEPTRE SIMSCRIP'r 1.5 SIMSCRIPT 11.5
Ads Prolog Smalltalk-80
SLIDE 8
CHAPTER I
FROM HOPL TO HOPL-II (1978-1993)
PROGRAMMING LANGUAGES in 1978
PROGRAMMING LANGUAGES in 1978
Existing ANSI Standards
APT' ATLAS BASIC (Minimal) COBOL FORTRAN MUMPS PL/I
(1974, 1977) (1978) (1978) (1968, 1974) (1966, 1978) (1977) (1976)
SLIDE 9
Some related Issues or topics
structured programming aoftwam engineering systems programming languages
SLIDE 10
from languages--and here, as much as I regret to, I must disagree slightly with the eminent Fred Brooks--I don't consider spreadsheets a language. But that is a debate for another time. Thefunctional languages, starting with the FP work of John Backus, was starting. And of course, the object-oriented programming and object-oriented languages were coming into fruition in that time period. (SLIDE 13) In 1993, as best as I can estimate, there were approximately 1000 languages that had been implemented since the beginning of the computer field, and probably 400 to 500 that had been dreamed about and even had lots of publications but which were never implemented. There are a couple of famous languages that had so many papers published that I kept trying to find out what machines these were implemented on. Finally, I got some shame-faced responses from the developers who were busy publishing all these papers, that they had never been implemented. I would estimate there are not more than about 300 in use today. I really don't have any data to back that up--it is just an estimate. And you will see most of this list tonight at the Computer Museum as part of the exhibit. (SLIDE 14a) It turns out that in the past fifteen years we have lost a number of people who were prominent in the computer field and who died in that time period. The Program Committee felt it was appropriate to point these out and to acknowledge them for the sake of the record. They are all alphabetically listed on the next four slides, except for Grace Hopper, who obviously belongs at the top of any such list.
PROGRAMMING LANGUAGES in the 19809
PROGRAMMING LANGUAGES in the 19809
[Only majorlanguage developments]
Emphasis in areas other than pure language development
Ads
standardization Implamentation
use C
significant use for systems programming SLIDE 11
THE OPENING SESSION
Language bindings (e.g., graphics) "Fourth generation" Application packages Functional languages Object-oriented programming and languages
SLIDE 12
19
JEAN E. SAMMET
WHERE WE ARE in PROGRAMMING LANGUAGES in 1993 Approximately 1000 languages Implememted since beginning of computer field (estimate 700 are dead in 1993)
SLIDE
13
"PROGRAMMING LANGUAGE PEOPLE" WHO HAVE DIED SINCE 1978 [1 of 4] • Grace Hopper (first compiler) (leader of FLOW-MATIC, MATH-MATIC) (persuaded eady managers of the value of progrsmmlng languages) • Saul Gom (theoreUcian) (computer science education pioneer) • John Kemeny (co-developer of BASIC) SLIDE
14a
Special Note: A few of the people listed in these slides were added after the conference because their death wa.,~unknown to me at that time, and the appropriate remarks have been inserted into this text. The speaker and editor felt it was better to do this than to omit them, even though the latter would have maintained strict accuracy with the original presentation. Among Grace Hopper's credits are the first compiler, the leader of the FLOW-MATIC and MATH-MATIC developments, and a major role she played (which is almost forgotten by now) in persuading the early managers to acknowledge the value of programming languages. For those of you who have not read the appropriate documents and wonder about the absence of COBOL there, I regret to inform you that Grace was not a developer or co-developer of COBOL. If you want to see what the facts are, go back to the COBOL paper I put into the first HOPL Conference, or in fact, look at the much briefer description that was in the biography of Grace that I published in the ACM Communications last year. Saul Gorn was a theoretician and one of the early pioneers in computer science education. John Kemeny was the co-developer of BASIC along with Tom Kurtz. BASIC was one of the languages in the first HOPL conference. (SLIDE 14b) Barry Mailloux was one of the co-developers and co-editors of the ALGOL 68 report. AI Newell was best known for artificial intelligence work but also as the co-developer of the list concept. From a language point of view, he was the co-developer of IPL-V and the earlier versions of the IPLs. Roy Nutt, while working for United Technologies (or some similar name but not IBM), helped implement the first FORTRAN. (SLIDE 14c) AI Perlis was a speaker at the first HOPL Conference. He was the primary developer of IT, which was an early language on the 650. He was on the ALGOL 58 and ALGOL 60 committees and another computer science education pioneer. Klaus Samelson from Germany was on the ALGOL 58 and ALGOL 60 committees, and made major contributions to early compiler scanning techniques. J. Cliff Shaw (who is different from C. J. Shaw) was the developer of JOSS, which was one of the languages in the first HOPL conference, although Cliff Shaw did not develop the paper personally; he declined to do so and we had somebody else who had worked on JOSS write the paper. Shaw was a co-developer (with AI Newell and Herb Simon) of the list concept and a co-developer of the IPL languages. (SLIDE 14d) Peter Sheridan, who was at IBM, helped implement the first FORTRAN. Aad van Wijngaarden was the lead developer of ALGOL 68, the lead editor of the ALGOL 68 reports, and the
20
CHAPTER I
FROM HOPLTO HOPL-II (1978-1993) "PROGRAMMING LANGUAGE PEOPLE" WHO HAVE DIED SINCE 1978 [2 of 4 • Barry Mailloux (co-developer of ALGOL 68) (co-editor of ALGOL 68 Report) • Alan Newell (co-developer of IPL-V) (co-developer of list concept) (artificial Intelligence) • Roy Nutt (helped Implement 1st FORTRAN) SLIDE 14b
"PROGRAMMING LANGUAGE PEOPLE" WHO HAVE DIED SINCE 1978 IS of 4 • Alan Perils (co-developer of IT) (on ALGOL 58 end 60 committees) (computer science education pioneer) • Kleua Samelson (on ALGOL 58 and 60 committees) ((m-developer of scanning technique) • J. Cliff Shaw (developer of JOSS) (co-developer of the list concept) (co-developer of IPL languages) SLIDE 14c
developer of a complex metalanguage used to define ALGOL 68. He was also one of the major figures in Dutch and European computing. Now, even though fortunately they are not deceased, I want to acknowledge two people who in this time period received significant honors--namely Nobel prizes! Herb Simon, who is primarily in the artificial intelligence area but is also involved in the list concept and IPL-V, and Howard Markowitz, who was involved in the early SIMSCRIPT, both received Nobel Prizes in economics. And I must tell you that when I heard about the Nobel Prize for Herb Simon, I thought, "interesting--another person with the same name as o u r Herb Simon." Then later, I heard mention of Professor Herb Simon of Carnegie Mellon; I thought, "isn't that amazing, two people with the same name at the same university." Finally, I saw a TV picture and I finally got the message! Those are two of our shining stars who had some involvement with languages, albeit there are no Nobel Prizes for languages. (SLIDE 15) This list shows what, in my opinion, are the major languages in 1993. You are entitled to dispute this, but that is my judgement using the same criteria as for the 1978 list--either major use and/or lots of publications and/or lots of implementations. (SLIDE 16) This bears some resemblance to Fred Brooks' comments about "fan clubs." The APL, FORTH, and MUMPS languages, in my opinion, have significant "fan clubs" or "cults." Some of the
"PROGRAMMING LANGUAGE PEOPLE" WHO HAVE DIED SINCE 1978 [4of4] • Peter Sheridan (helped Implement 1at FORTRAN) • Aed van Wijngearden (lead developer of ALGOL 68) (lead editor of ALGOL 68 Report) (developer of complex metalenguage)
SLIDE 14d
THE OPENINGSESSION
PROGRAMMING LANGUAGES in 1993
MajorLanguages (based on use and/or publications and/or many implementations) Ads APT C C++ COBOL
Common LISP FORTRAN Pascal Prolog Smalltelk
SLIDE 15
21
JEAN E. SAMMET
PROGRAMMING LANGUAGES in 1993
PROGRAMMING LANGUAGES in 1993
"Cd~lt" Languages
Numerous Application-Oriented Languages
APL, FORTH, MUMPS
(e.g.,)
Some, Other Languages
GPSS ICON MACSYMA MATHMATICA
PLA Slmula SIMSCRIPT
ATLAS
(teat)
KAREL OPS5 PILOT STRUDL VHDL
(robotics) (expert systems) (CAI) (civil englneedng) (hardware design)
SLIDE 16
SLIDE 17
other programming languages that I think are of some significance that are in use today are the ones I have listed there. (SLIDE 17) Back to the specialized application languages. And in case you haven't gotten the message yet, that is an area that I happen to be very strongly interested in personally, even though I know many of the computer science and many of the computer language people are not. I think these are under-played, under-appreciated, misunderstood and so forth. I listed half a dozen of them that are in use today in the areas that I have indicated. (SLIDE 18) Standards: These are brand new, relative to 1978. These are languages which were not standardized in any way whatsoever in ! 978 and do have standards in 1993. C-ATLAS is some version of ATLAS, which is the testing language. CHILL is a European language, a very large, powerful language in the genre of ALGOL 68 or PL/I or Ada. DIBOL is some kind of a business data processing language; it doesn't look like very much. PANCM has been standardized. PILOT is a CAI language. And SCHEME is an offshoot or dialect with regard to LISE (SLIDE 19) ThiLsshows the standards that have been revised relative to 1978. In other words, those seven languages all had standards in 1978 and there are now newer versions of those standards. (SLIDE 20) W]hat is going on today? Here is my personal view of what seems to be happening today. Certainly, olbject-odented programming as a separate intellectual discipline; that is, somewhat separate from the languages per se, is a major area of interest and concern in the programming
PROGRAMMIING LANGUAGES In 1993
PROGRAMMING LANGUAGES In 1993
ANSI and/or ISO Standards New (relative to 1978)
ANSI or ISO Standards Revised (relative to 1978)
Ads
PANCM
APL
Pascal
BASIC (full)
Extended Pascal
C C/ATLAS CHILL DIBOL
PILOT PL/1 subset
SCHEME
SLIDE 18 22
~
APT
ATLAS BASIC (minimal) COBOL
FORTRAN MUMPS PLJI
SLIDE 19 CHAPTER I
FROM HOPL TO HOPL-II (1978-1993)
PROGRAMMING LANGUAGES In 1993
PROGRAMMING LANGUAGES IN 20xx
Some related Issues or topics
??
Object-oriented programming User Interface Software enginsering Parallelism Functional programming
SLIDE
20
HOPL--xxx Number of languages Major, other, specialized languages Standards Issues In programming languages
SLIDE 21
community in general, and as this is often manifested by programming languages, it tends to be very relevant. User interface--again, that is not a major language issue, but certainly an important issue for the people who are using the computers. Software engineering is always with us, and certainly that is a major area. Parallelism--Fred Brooks also made an allusion to that this morning, and it is certainly an area of importance; people arc concerned with languages that enable you to exploit parallelism of computers and also with parallelism as a general topic. Finally, functional programming is a new way of looking at programming languages. (SLIDE 21) HOPL XXX, as one of my colleagues on the Program Committee said, "I don't know when it will be but I know I won't be on the Program Committee." We don't know when 20XX will be. I certainly hope it is less than 15 years and I would be very happy if there were another HOPL in 1998, or something of that kind. I don't know what the number of languages will be. I think it will not increase that much. As best as I can tell from the data I have and the examinations I've made, the number of new languages is certainly increasing at a very much smaller slope. I think to a large extent that the curve has pretty much leveled off; there are not as many new ones coming along. Most of the new ones that come along are not really justified, just as most of the thousands that existed are not justified. Some of the reasons you saw on Fred's chart, and it is interesting because we had no collaboration on any of this. You will see tonight a series of panels at the Computer Museum--something I insisted on--which attempts to list some of the reasons that there are somany programming languages and certainly the fact that it is fun is one of them. There are going to be some major other specialized languages, but I don't know what they are going to be because I think there the increase is moving somewhat faster. I don't know what the standards will be, but certainly the standards committees continue on forever, and I think they serve a very useful purpose. I don't want any remark I made to be misinterpreted against standards; I am very much in favor of the standards. Finally, I don't know what the general or major issues in programming languages will be. This talk is a look backwards not a look forwards.
INTRODUCTION OF MICHAEL S. MAHONEY SESSION CHAIR,JEAN E. SAMMET: Michael Mahoney is a Professor of History at Princeton University and a member of its Program in the History of Science. According to him, he met his first computer, which was a Datatron 204, as a part time programmer for Melpar Electronics while he was a senior at Harvard in 1959 to 1960. He was apparently unimpressed. So after graduation he turned
THE OPENING SESSION
23
MICHAEL S. MAHONEY
to the History of Science and Medieval Science--first at the University of Munich and then at Princeton, where he earned his Ph.D. in 1967. I can't help interspersing this more formal biography with the fact that ti'equently over the past couple of years when I had occasion to either call him on the phone or communicate with him by e-mail he told me he was worrying about his course in Medieval History or leading a tour for some group looking at history that goes back a thousand years. I keep thinking this must be two people, but it isn't; it is really all one person. After Mike Mahoney got his Ph.D., he spent a decade or so teaching and doing research in the history of science and mathematics in the early modern era, which included writing a book on the mathematician Pierre Fermat. At this point he looked again to see what computers had been doing. Apparently he found that they had acquired a history. After writing several exploratory articles, including one in die Annals of the History of Computing entitled "The History of Computing in the History of Technology," he is now nearing completion of a book tentatively entitled The Structures of Computation: Idathematics and Theoretical Computer Science, 1950-1970. Heaven forbid we should bring that any closer to today than 1970; that is my comment, not his. After he finishes that, he plans to return to the project that started him on much of this--namely, the origins and early development of software engineering. He has served as the HOPL-II historian, for which I am eternally grateful, is a member of the HOPL-II Program Committee, and a member of the Forum Committee.
MAKING HISTORY MICHAEL S. MAHONEY: What we are doing here this morning is making history. We are making history in what wc,uld seem an obvious way. That is, we are here over the next few days to hear from the people who have made history through their creative work. We are here to hear how they did it. But we are also making history ourselves by being here. We are here in essence doing what the software development people call "validation and verification." We are here to help the authors to make sure that we have the history right, and more importantly, to think about whq~ther we have the fight history. That is the function of questions, comments, and conversations, the interactive activities that make it seem worthwhile for all of us in fact to get together here in one place lind sit down and talk with one another, instead of just reading the papers in their published form. We think about Gwen Bell's remark about establishing the history that people like the producers of "The Machines That Changed the World" will use to tell our story. In essence, what we are here for today in this conference is to establish what that story of programming languages is, the story that we think best fits our experience. That is making history, and we are all a part Of it. So what to listen for and what ought we be talking about? Let me briefly review what I said to the authors about "What Makes History?" in a piece I sent to them after the first drafts had been reviewed. I think we can help the authors and ourselves by thinking through the issues. First of all, the obvious, are the facts fight and are they in the right chronological order? We want to make sure that :is the case, that is the sine qua non. But actually that is a subtle question. Are the facts right? But, w,z may also ask, are we getting the right facts? Is this the story we want to be telling? Are the facts chronologically appropriate? Are they the right facts for the time? Are there other facts that we ought to be thinking about? What we want to aim for is to meet Dick Hamming's charge, made at the pioneer's historical conference back in 1976 in the title of his keynote talk: "We Would Know What They Thought When They Did It." By which he meant, to get through the explicit documentation and back to the undocumented practice to recreate the frame of mind and the body of practice at another time. Fred Brooks talks about great design as reflecting craft experience, experience of the craft is necessary to understand design at any time.
24
CHAPTER I
MAKING HISTORY
It is necessary, then, for us to be sure that we know what the experience of the craft was at that time. It is a tricky problem. It is not a problem of memory alone. It is not only that our memories fail. Indeed, as Alan Kay reminds us in the second of the leitmotifs for his paper on Smalltalk, quoting Thomas Hobbes, "Part of the problem is that we remember the past bY reconstructing it," that memory and imagination tend to mix. I think the artificial intelligence people actually have something to say about the way we remember things, in part by reconstruction• And there, the mind can play tricks. If you look at the published version of this, the piece that was sent around to the authors, I tell a story there. It is probably apocryphal, but then again, apocryphal stories have their purposes, too. What it comes down to is the following: once you know the answer to a question, it is very hard to imagine what it was like not to know it, to recreate the frame of mind you were in before you knew what the answer was, or indeed, before you were sure what the question was. Because in the act of answering, the problem gets reshaped. Having an answer, in many ways, makes clear what questions one should have been asking• And here comes the reconstruction. What question was I answering? Why, the obvious question. Maybe it is obvious, maybe it is not. Fred Brooks said the hardest thing in the world is knowing what to design• I submit that quite often we find out what we are designing in the process of designing. And when we are finished it is hard for us to imagine that we were ever looking for anything else. Indeed, it is important, as he points out, to know sometimes that you are just wrong• But even that is not clear; we usually start out with confusion• That leads to an interesting paradox of pioneers--people who were there--because the very act of creativity makes it harder to recreate the circumstances that the people involved should be best able to tell us about. That is, they are on the one hand our best witnesses and, in another very real sense, our worst, simply because of the way the mind plays tricks. Here is where others less directly involved can help out. If they are less directly involved in the creative act but were around at the time, informed about the time, they can help by recalling what the problem was. Maybe for some people it is still a problem. They don't have the enlightenment of the answer. This is tied up with the problem of language, which is a matter that historians are very conscious of. This is what I mean about getting the right facts. Fred Brooks reminded us of something we do know, but it was important to bring it out. Language enables us to think about certain things in certain ways. There is a corollary to that. Before we had that language, we were not thinking that way. Now, quite often one sees people, scientists and engineers who make history, talk about work they were doing, or they will look back and say, "So and so was really doing X," where X is some modern concept. In many ways, to use modern terms that way is simply to make our problem, the problem I have just been describing, opaque. It does not clarify things to say, "What he was really doing was. • ." "Now this is really object-oriented programming thirty years ago," because the emergence of that concept out of the earlier concepts is what we are interested in. That is, ideas grow roughly as trees do; Fred talked about the decision tree. It is important to get back to the root but not identify the root with the branch. Because the branch may actually have emerged in quite different ways than that assumption, that single backtrack, might reveal• Again, here, I think we can help. We can say, "Wait a second. We weren't talking that way back then. We didn't call it that. We called it something else. Now that we use that other language, maybe we are not quite sure what it is." A major point you want to bear in mind, and this is something historians must insist on: being right is not an explanation. Right answers require as much explanation as wrong answers because in many cases at the time there was no way of knowing that you were right• You made choices or people involved made choices. What we have to do is to recreate the choices• What were the options open? How did decisions foreclose certain options and open other options? We need to know what the reasons
THE OPENING SESSION
25
MICHAEL S. MAHON EY
were for making those choices, and actually what we would like to know is what the standards were at the time for being judged to be right? What constituted a right answer by what standards? What makes history? It is a matter of going back to the sources, of reading them in their own language and thinking one's way back to the problems and solutions as they looked then. It involves the imaginative exercise of suspending one's knowledge of how things turned out, so as to recreate the possibilities th~tt were still open at the time. It is to imagine an alternative present. In The Go-Bem'een, Leslie Hartley remarked (and I quote), "The past is a foreign country. They do things differently there." The historian must learn to be an observant tourist alert to the differences that lie behind what seems to be familiar. Now I wrote that before I went on the trip that Jean referred to. A colleague and I took a group of Princeton alumni to Spain last October to follow Columbus across Spain. We gave lectures but we also visited various sites in Spain. Again and again we would take people to a site because Columbus had visited there, or talked to the Queen there, and in one place Queen Isabella had died. Time and time again, we would arrive at the site to have the tour guide tell us, "Well no, actually Columbus never was here. No, Queen Isabella did not die here." We discovered a whole new Columbian Spain, quite different from the one we have read about in the books. Well, folks, we are a mixture of tourists and former residents. We are trying to recreate a land that is no more, but a land that can be deceptively familiar. That is what we are up to, and I think it is going to be a good deal of fun to see if we can do that.
26
CHAPTER I
II ALGOL 68 Session
Chair:
JacquesCohen
A HISTORY OF ALGOL 68
C. H. Lindsey 5, Clerewood Avenue, Heald Green, Cheadle, Cheshire SK8 3JU, U.K.
ABSTRACT ALGOL 68 is a language with a lot of "history." The reader will hear of discord, resignations, unreadable documents, a minority report, and all manner of politicking. But although ALGOL 68 was produced by a committee (and an unruly one at that), the language itself is no camel. Indeed, the rigorous application of the principle of "orthogonality" makes it one of the cleanest languages around, as I hope to show. Moreover, when the language came to be revised, the atmosphere was quite different, enabling a much more robust and readable defining document to be produced in a spirit of true cooperation. There are some lessons here for future language design efforts, but I am not optimistic that they have been learned. CONTENTS 2.1 Introduction 2.2 History of the Original ALGOL 68 Report 2.3 The Concepts of ALGOL 68 2.4 History of the Revised ALGOL 68 Report 2.5 The Method of Description 2.6 The Maintenance Phase 2.7 Implementations 2.8 Conclusion Acknowledgments References Appendix A: The Covering Letter Appendix B: The Minority Report
2.1
INTRODUCTION
The world seems to have a rather negative perception of A L G O L 68. The language has been said to be "too big," to be defined by an "unreadable Report" produced by a committee which "broke up in disarray," to have no implementations, and to have no users. The only phrase that everybodycan quote
27
C. H. LINDSEY
from the Report is the one that says, "It is recognized, however, that this method may be difficult for the uninitiated reader" [R 0.1.1 ]. While these stories do have some basis in fact, which it will be the purpose of this paper to explore, they are at the least a considerable oversimplification of what really took place. In fact most of the people who pass on these things have never read the Report, or tried to use the language, and the observed fact is that those who have used the language have become totally addicted to it. I should point out that my own involvement with the project came after the basic design of the language, and of its original Report, were complete. I was an onlooker at the fracas, as confused as any outsider as to what was going on. It is only now, in the course of studying the minutes and other documents from that time, that I have come to see what the real fuss was about, and I hope that all this has enabled me to take a dispassionate view of the events. The reader of this paper will certainly see discord, but I believe he will see also how good design can win through in the end. ALGOL 68 clearly grew out of ALGOL 60, but many other language developments were taking place at that time---Lisp, COBOL, PL/1, Simula--all of them aimed at wider markets than the numerical comput~Ltions for which ALGOL 60 was so well suited. The territory into which ALGOL 68 was now pushing was largely unmapped. Individual research languages had probed far ahead; ALGOL 68 was to advance into this landscape on a broad front. We indeed discovered what was there, but it seems to have been left to other, later languages to complete the colonization. 2.1.1
The Political Background
ALGOL 60 [Naur et aL 1960] was produced by a group of persons, half nominated by ACM and half by various European institutions. Apart from that initial sponsorship, the group had no official standing or authority. Meanwhile, the International Federation for Information Processing (IFIP, founded in 1960), through the auspices of its Technical Committee 2 on Programming Languages (TC2), had founded a Working Group on ALGOL (WG 2.1). At their meeting in Rome in April of 1962, upon completion of the Revised ALGOL 60 Report, the authors accepted that any collective responsibility which they might have with respect to the development, specification and refinement of the ALGOL language will from now on be transferred [to WG 2. I]. Thus, it will be seen that IFIP is a hierarchical organization with a General Assembly and a Council, a layer of Technical Committees, and a layer of Working Groups below that. There is a procedure for promulgating an 'qFIP Document," the product of some Working Group, with some variant of the following wording: This Report has been accepted by Working Group 2. !, reviewed by Technical Committee 2 on Programming Languages and approved for publication by the General Assembly of the International Federation for Information Processing. Reproduction of the Report, for any purpose, but only of the whole text, is explicitly permitted withoulLformality. Over the last thiirty years, some eight IFIP Documents have been produced by WG 2.1 under this procedure, as shown in Table 2. l. IFIP does not have any significant funds at its disposal. The costs of bringing members together at a Working Group meeting falls on those members' employers or funding agencies, and on the organization hosting the meeting. If it were possible to add up the total cost of bringing ALGOL 68 before the world, it would come to a tidy sum. Whether the world has now the benefit of this investment is an interesting question.
28
CHAPTER II
PAPER: A HISTORY OF ALGOL 68 TABLE
2.1
IFIP Documentsproducedby WG 2.1. Revised report on the algudthmic language ALGOL60 Report on SUBSETALGOL60 (IFIP) Report on input-outputproceduresfor ALGOL60 Report on the algorithmiclanguageALGOL68 Revised report on the algorithmiclanguage ALGOL68 A supplementto the ALGOL60 revised report A sublanguageof ALGOL68 The report on the standard hardware representation for ALGOL68
2.1.2
Naur et aL 1962] [WG 2.1 1964a] [WG 2.1 1964b] [VanWijngaarden 1969] [VanWijngaarden 1975] [De Morgan 1976] [Hibbard 1977] [Hansen 1977]
Historical Outline
As will be seen from Table 2.1, The early years of W G 2.1 were spent in various activities arising out of A L G O L 60. But even as early as March 1964 there was mention of a language, A L G O L X, to be a "short-term solution to existing difficulties," and a "radically reconstructed" A L G O L Y [Duncan 1964]. Table 2.2 shows the milestones in the life of A L G O L 68, which can be divided into three phases. •
1965 through 1969, culminating, in spite of much dissention, in the original Report [Van Wijngaarden 1969].
•
1970 through 1974, leading to the Revised Report [Van Wijngaarden 1975].
•
1975 onwards--the maintenance phase, resulting in various supplementary documents.
The milestones themselves are most conveniently remembered by the names of the meeting places at which the events took place. 2.1.3
Some Conventions
A L G O L 68 and the documentation that surrounds it adopt by convention various usages that I shall follow in this paper. In particular, I shall refer to [Van Wijngaarden 1969] as [R], often followed by a section number, and to [Van Wijngaarden 1975] as [RR]. Also, the long series of draft Reports leading up to [R] will be known by the numbers given them by the Mathematisch Centrum, of the form [MRnn]. References of the form ( n . m ) are to sections within this paper. [R] is noted for its number of arcane technical terms used with a very precise meaning. Some were introduced purely to facilitate the syntax and semantics, but others denote concepts of definite interest to the user, and of these many are now in common parlance (for example, 'dereference', 'coercion', 'elaborate', 'defining/applied occurrence', 'environment enquiry'). Often, however, the authors chose terms for existing (or only marginally altered) concepts that have failed to come into common usage, such as the following: mode multiple value name scope
ALGOL 68 SESSION
instead of .... " " " "
type array variable extent (a dynamic concept)
29
C. H. LINDSEY reach routine
.... ....
range
....
identity-declaration
s c o p e (a static c o n c e p t ) procedure block "
constant-declaration
To a v o i d c o n f u s i o n , I shall b e u s i n g the t e r m s in the f i g h t h a n d c o l u m n in the rest o f this paper. TABLE
2.2
Summary of the main events in the history of ALGOL 68. The ORIGINAL REPORT Date
Meeting Place
May 1965
]Princeton
Oct 1965
St. Pierre de Chartreuse
Apr 1966
Kootwijk
Oct 1966
Warsaw
[W-2]
May 1967
Zandvoort
[MR 88]
Progress meeting.
[MR 93]
Draft Report [MR 93] circulated as a supplement to the ALGOL Bulletin.
Feb 1968 Jun 1968
Document
Events Start of ALGOL X. Draft proposals for a full language solicited.
[MR 76]
Drafts presented by Wirth/Hoare, Seegmiiller and Van Wijngaarden. Commission given to these four to produce an agreed draft. Meeting of the commissioned authors.
Tirrenia
Van Wijngaarden commissioned to produce and circulate a draft ALGOL X Report.
Intense discussion of [MR 93].
Aug 1968
North Berwick
[MR 95]
Dec 1968
Munich
[MR 100]
ALGOL 68 Report accepted by WG 2.1.3
Sep 1969
Banff
IMR 101]
Final cleanup before publication.
A week of political wrangling.
The REVISED REPORT Date
lVleeting Place
Events
Jul 1970
1-labay-la-Neuve
Discussion of "Improvements." Subcommittee on "Data processing."
Apt 1971
lvlanchester
Subcommittee on "Maintenance and Improvements to ALGOL 68".
Aug 1971
l%vosibirsk
Decision to produce a Revised Report by the end of 1973.
Apr 1972
Fontainebleau
Editors for the Revised Report appointed.
Sep 1972
Vienna
Progress meeting. Hibbard's Sublanguage proposal.
Apr 1973
Dresden
Progress meeting.
Sep 1973
Los Angeles
Revised Report accepted, subject to "polishing". Subcommittee on ALGOL 68 Support.
Apr 1974
Cambridge
Meeting of Support Subcommittee to discuss transput.
See Table 2.5 (Section 2.6) for events after i 974 (the Maintenance Phase).
30
CHAPTER II
PAPER:A HISTORYOF ALGOL 68
[R] is writing about language, and this always causes problems when one needs to distinguish clearly between a word and the thing it denotes. Distinguish, for example, between the following: "John has four daughters", "John has four letters", "John is in italic." In these the word "John" stands for, respectively, the object denoted by the word, the syntactic structure of the word, and the appearance of the word. To ease this sort of problem, it has long been traditional to print fragments of program text in italic, but [R] goes further by introducing a special font for constructs produced by the grammar (foo is an identifier). Moreover, when talking about the grammar symbols themselves (or fragments thereof') single quotes are used as well (the mode of the identilierfoo is 'integral'). To express the text of an ALGOL 68 program, two alphabets are necessary, and in the days when computers did not support two cases of characters a variety of 'stropping' conventions (this term comes from [Baecker 1968]) were used (for example, 'REAL' X or .REAL X, or REAL x once two cases did become available). However, it has always been traditional to use a bold font for the stropped words in printed documents (realx). When preparing [RR] we took special care in choosing suitable fonts. The stropping font, although still slanted like italic, is also sans serif, and the font for constructs and grammar symbols is bold roman (as opposed to the insufficiently distinctive sans serif used in [R]). I follow the same conventions in this paper, but I also adopt a practice not used in the Report, which is to use a type (usually written as a stropped word) to indicate some value of that type (foo is an inO. Thus I will talk about strings and structs and procs, and by analogy, about arrays, even though the word "array" is not an official part of the language. And I take the liberty of applying these conventions to other languages where appropriate. Finally, to avoid confusion with an ever changing language, the examples in this paper are generally written using the syntactic sugar of the final language, even when discussing features of earlier versions. 2.1.4
Layout of the Rest of This Paper
2.2 The history of the original Report, up to 1969. This is the period during which all the controversies arose. 2.3 The concepts of ALGOL 68. This traces the sources of the various ideas, including some that fell by the wayside, and a few that only appeared in the revision. 2.4 The history of the Revised Report, from 1970 to 1975. 2.5 The method of description. This changed substantially during the revision, which is why it is considered here. 2.6 The maintenance phase: enhancements and problems. 2.7 Implementations. 2.8 Conclusions, including "Whatever happened to ALGOL 68?" and "Whatever have we learned from ALGOL 68?" I have included in this paper those incidents in the history of ALGOL 68 that I considered to be significant. Space did not permit me to tell all the stories that could have been told; for a different subset and an alternative perspective, especially of the early days, the reader is referred to [Van der Poel 1986].
ALGOL 68 SESSION
31
C. H. LINDSEY 2.2 2.2.1
HISTORY OF THE ORIGINAL ALGOL 68 REPORT Dramatis Personae
Table 2.3 lists those members of WG 2.1 who were active in the development, in the order in which they became full members of the Group. Most members of the Group were there on account of their involvement with, or experience of, ALGOL 60. Those belonging to academic institutions would have teaching duties and research interests not necessarily connected directly with ALGOL 68. Only the team at Amsterdam (Van Wijngaarden, Mailloux, Peck, and Koster) together with Goos, who was preparing an implementation, worked full-time on the project. McCarthy had been responsible for LISP, regarded as a tool for his work on artificial intelligence; Wirth, after initially working on ALGOL X, devoted his energy to his own ALGOL W; ]Ross was working on his own languages, AED-0 and AED-1; and Yoneda was working on the Japanese ALGOL N. The nonacademics were subject to the bidding of their employers, although those in large research establishments would have much opportunity to do their own thing. Thus Woodger and Duncan at NPL and Sintzoff at MBLE could devote their time to programming language research. Randell had been responsible for a major ALGOL 60 implementation at English Electric, but at IBM he was into system architecture; and Hoare had implemented ALGOL 60 for Elliot and was now trying to provide operating systems to match; Bekic was part of the group that developed the Vienna Definition Language. 2.2.2
Princeton (May 1965)
The first public mention of ALGOL X (which eventually became ALGOL 68) and of the mythical ALGOL Y (originally conceived as a language that could manipulate its own programs, but in fact degenerating into ~ collection of features rejected for ALGOL X) was in a paper entitled "Cleaning up ALGOL 60" [Duncan 1964]. Although it had been discussed at Tutzing (March 1964) and Baden (September 1964), work started in earnest at the Princeton meeting in May 1965. The chairman's Activity Report to TC2 for that meeting [Van der Poel 1965] shows a wide ranging discussion on basic aspects of the language. There was much interest in the language EULER [Wirth 1966a] and particularly in its 'trees' or 'lists'. There was a strong feeling towards what now we should call 'strong typing', and even a firm decision to have coercion from integer to real to complex. Draft proposals for a full language were solicited for the next meeting. 2.2.3
St. Pierre de Chartreuse (October 1965)
There were three drafts on the table: [Wirth 1965], [Seegmtiller 1965b], and [MR 76], which was Aad van Wijngaarden's famous "Orthogonal design and description of a formal language." [Wirth 1965] had been written while the author was on sabbatical at the Mathematisch Centrum over the summer, and was available sufficiently in advance of the meeting that a substantial set of comments on it was also available. It was a straightforward compilation of features as discussed at Princeton, including the trees from EULER. In the meantime, however, Record Handling [Hoare 1965b] had been proposed and Wirth much preferred this to his trees. Henceforth, the Wirth/Hoare proposal must be regarded as one. [Seegmtiller 1965b] was really an extension of [Wirth 1965] and never a serious contender. Its main feature was a systera of References, also described in [Seegmiiller 1965a] (see also Section 2.3.4). 32
CHAPTER II
PAPER: A HISTORY OF ALGOL 68
TABLE 2.3 WG 2.1 members active in the original design of ALGOL 68. Fritz Bauer
Techn. Hocl't~chule,Munich
Edsger Dijkstmt
Tech. University, Eindhoven
Fraser Duncan#
National Physical Lab., UK
Tony Hoare#
Elliot Automation, UK
P. Z. Ingerman
RCA, Camden, NJ
John McCarthy
Stanford University, Palo Alto, CA
J. N. Merrier
General Electric, Phoenix, AZ
Peter Naur:~
AJS Regnecentralen, Copenhagen
Manfred Paul
Techn. Hochschule, Munich
Willem van tier Poel
Techn. Hogeschool Delft, Chairman of WG 2.1
Klaus Samelson
Techn. Hochschule, Munich
Gerhard Seegmiiller#
Techn. Hochschule, Munich
Aad van Wijngaarden
Mathematisch Centrum, Amsterdam
Mike Woodger'l"
National Physical Lab., UK
Jan Garwick'i"
Oak Ridge National Lab., Oak Ridge, TN
Brian Randell'~"
IBM, Yorktown Heights, NY
Niklaus Wirth:~
Stanford University, Palo Alto, CA
Peter Landin
Univac, New York, NY
Hans Bekic
IBM Lab., Vienna
Doug Ross
M.I.T., Cambridge, MA
W. M. Turskii"
Academy of Sciences, Warsaw, Secretary of WG 2.1
Barry Mailloux
Mathematisch Centrum, Amsterdam
John Peck
University of Calgary
Nobuo Yoneda
University of Tokyo
Gerhard Goos
Techn. Hochschule, Munich
Kees Koster
Mathematisch Centrum, Amsterdam
Chades Lindsey
University of Manchester, U K
Michel Sintzoff
MBLE, Brussels
t Signatories to the Minority Report. :I:Resigned after [MR 93].
[ M R 76], distributed only the w e e k before the meeting, introduced three basic ideas: 1. T h e two-level g r a m m a r notation we now know as a W - G r a m m a r (2.5.1.1). 2.
The combination o f a minimal number o f language concepts in an orthogonal way (2.3.4.3), thus providing the p o w e r o f the language. (This process is m u c h facilitated by using a W-Grammar.)
3.
An expression-oriented language, that is, no distinction b e t w e e n statements and expressions.
ALGOL 68 SESSION
33
C. H. LINDSEY
Apart from these, the language described by [MR 76] was nothing special, and the document itself was exceedingly hard to read (no examples, no pragmatics, and only 26 one-letter metanotions of not much mnemonic significance). Nevertheless, WG 2. ! was sufficiently impressed to resolve formally (but with misgivings from Hoare) that "whatever language is finally decided upon by WG 2.1, it will be described by Van Wijngaarden's metalinguistic techniques as specified in MR 76." Whether they had bought just the notation, or whether it included (2) and (3) as well, is not clear. The meeting spent most of its time discussing language issues, mainly in terms of the Wirth/Hoare proposal (which was not expression-oriented, be it noted), and by the end of the week the participants felt that they had a fair idea what ALGOL X was going to look like. Meanwhile, it had established a subcommittee consisting of Hoare, Seegmiiller, Van Wijngaarden, and Wirth with instructions to prepare a Draft Report along the lines agreed upon. A second subcommittee, set up to consider I/O, consisted of Ingerman, Merner, and (in their absence) Garwick and Paul; it was charged with producing facilities somewhat between [Knuth et aL 1964] and [Garwick 1965]. Nevertheless, all was not plain sailing. A bad attack of cold feet occurred on the Thursday morning (a traditional time for cold feet in WG meetings), and serious suggestions were made by Naur and Randell that ALGOL X should be dropped and ALGOL Y proceeded with. At the end of thte meeting, the Subcommittee announced that Van Wijngaarden would write a draft report for the other three to consider, and that it would be circulated well in advance of the next meeting (with the proviso 1:hatmembers wishing to change anything would have to rewrite those parts of the report affected). The next meeting was fixed for six months hence, and it was well understood that the time for radic~lly new concepts was already passed. Throughout the,,whole project, the WG in general, and Van Wijngaarden in particular, consistently underestimated the time it would take by substantial factors. Recall that ALGOL 60 was put together in six days, albeit after various preliminary meetings over the previous six months. Naur's draft for [Naur et al., 1960] was written in two months, and the final version was circulated within two months after the meeting [Naur 1981 ]. But the art of language design and definition had advanced since 1960 and things could not be done at that pace anymore. In the event, Van Wijngaarden's draft was nowhere near complete, and the next meeting had to be postponed for a further six months. However, the Subcommittee members themselves did get together on the date originally proposed at Kootwijk.
2.2.4 Kootwijk (April 1966) In addition to the tour members of the Subcommittee, this meeting was attended by Barry Mailloux, Van Wijngaarden's doctoral student from Canada, and W. L. van der Poel, chairman of WG 2.1. Contrary to the an'angement made at St. Pierre, there were two drafts available: Van Wijngaarden's incomplete one, w~rittenin the agreed formalism, and a Wirth/Hoare"Contribution to the development of ALGOL" [Wirth 1966b], which had been prepared from [Wirth 1965] and [Hoare 1965b] for publication in Communications of the ACM after the adoption of [MR 76] at St. Pierre. It was generally agreed that the Contribution described more or less the right language, but in the wrong formalism. Due to the incompleteness of Van Wijngaarden's document, the meeting worked initially by amending the Contribution (although still with the intent that Van Wijngaarden's version should be brought into line ~tnd become the official definition, as agreed by the WG). However, there arose a complete disagreement between Seegmiiller and Van Wijngaarden on the one hand, and Hoare and Wirth on the other, concerning the parameter mechanism (2.3.4.3), and as Van Wijngaarden's parameter mechanism could not easily be incorporated into the Contribution, it was clear that the two documents must now diverge. Certainly, there was little prospect that the Van Wijngaarden approach
34
CHAPTER II
PAPER:A HISTORYOF ALGOL 68 would produce a document within 1966, whereas Hoare and Wirth were especially concerned about achieving a short timescale. The Subcommittee made a long list of points that the Van Wijngaarden version should attend to, and he continued to work on it, assisted by Mailloux, a further incomplete draft being sent to WG 2.1 members during July, and a more-or-less complete draft just ten days before the next meeting. The language defined in the Contribution was subsequently implemented by Wirth as ALGOL W (see also [Wirth 1966c]).
2.2.5
Warsaw (October 1966)
The draft submitted to this meeting was [W-2] (which apparently never did get an MR number). 'There was fierce debate as to whether this document by one member could be accepted as the report of the Subcommittee: Hoare was willing to accept it as such if time were allowed for missing parts to be completed; Wirth, who had had grave misgivings about the formalism at Kootwijk, had resigned from the Subcommittee and declined to attend this meeting, complaining of insufficient time to study the document, and insisting that it could no longer be regarded as a Subcommittee product. There was also a report [Merner 1966] from the I/O subcommittee, which had held meetings at Oak Ridge and at the University of Illinois. However, this was not yet incorporated into [W-2]. At the start of the week there was some expectation that the two documents could be put together and submitted to TC2. However, there was strong debate on the subject of references. Orthogonality dictated that references could exist to any object, whether a record or not and whether that object were declared locally or on the heap, and this also considerably simplified the parameter-passing mechanism. Hoare and some others wanted to restrict references to records only (as in [Hoare 1965b] and [Wirth 1966b])--the so-called "diagonal" approach (2.3.4.3). Moreover, McCarthy had introduced fresh proposals for operator overloading (2.3.6), and had also been demanding serial elaboration of a n d and o r (2.3.3.6), and Samelson had asked for anonymous routines (2.3.5). So by Thursday afternoon the customary depression had set in, to the extent that they even considered abandoning it altogether, and certainly the most to be expected was publication as a Working Document, while further editing and implementation studies continued. Finally, the following were formally agreed: 1. [W-2] to be amended, incorporating at least [Merner 1966], together with proper pragmatics. (A 'pragmatic remark' is to the Report as a comment is to a program.) 2. The amended document to be published in the ALGOL Bulletin, and possibly other informal, non-refereed journals. 3. The results of implementation studies to be incorporated. 4. Van Wijngaarden to be charged with the editing, alone without any subcommittee (provided he was not pressed for any specific time schedule, although he could foresee mailing it the following February). 5. The next meeting in May would be too soon to consider the revised draft, and would be devoted to ALGOL Y. The following meeting in September would take the final decision. 6. McCarthy's overloading could be incorporated if the editor found it feasible. It will be seen that the content of the language was growing steadily (and more was to come). It should be stressed that Hoare made several attempts to limit the content to something like [Wirth 1966b], or at least to "within the intersection of the agreement of WG 2.1," but to no avail. It is also
ALGOL 68 SESSION
35
C. H. LINDSEY noteworthy that Van Wijngaarden was beginning to realize just how long the revision might take, although he was still out by a factor of two. 2.2.6
Zandvoort (May 1967)
This meeting was supposed to discuss ALGOL Y: it spent nearly all its time on ALGOL X. The document available (in spite of there being no obligation to produce one at all) was [MR 88], which was now beginning to look substantially like the eventual [R]. John Peck, on sabbatical from the University of Calgary, had now joined the editorial team. It had been mailed four weeks in advance of the meeting. McCarthy's overloading was there "in all its glory", as were Samelson's anonymous routines. There was pressure to get the process finalized before a TC2 meeting in October (which could lead to final acceptance as an IFIP document at the forthcoming General Assembly meeting in Mexico), but the timing was very tight. So the motions passed were 1. The report published in the ALGOL Bulletin (as agreed in Warsaw) should also be submitted to TC2, who would accept it subject to subsequent adoption by WG 2.1 "without substantive changes." 2. The next meeting was to be held not less than three and a half months after the circulation of the report. On this basis, the earliest date for the next meeting would be October 22 (but, by application of the formula, it did not actually happen until the following June 3). The meeting spent much time in constructive discussion of language issues (and also of the description method) without (so far as I can tell from the minutes) threats of resignation or rebellion, apart from a considerable disgust expressed by Wirth. They even spent an afternoon on ALGOL Y, from which it emerged that no one had very concrete ideas of what it was about, and that the only role model was LISP, on account of the fact that that language could construct its own programs and then eval them. 2.2.7
MR 93
The draft Report commissioned at Warsaw was eventually circulated to the readership of the ALGOL Bulletin as [MR 93] in February 1968, and was the cause of much shock, horror, and dissent, even (perhaps especially) among the membership of WG 2.1. It was said that the new notation for the grammar and the excessive size of the document made it unreadable (but they had said the same about ALGOL 60 and, although it may have been the longest defining document at that time, it is rather shorter than most of its successors). Moreover, it was not all gloom--there was also a substantial number of positiw; reactions and constructive comments. Another of Van Wijngaarden's students, Kees Koster, had now joined the team, with special responsibility for "transput," as I/O was now to be known. This is where I entered the picture myself. Everything described up to now has been gleaned from the minutes and other documents. However, a copy of [MR 88] happened to come into my possession, and I set out to discover what language was hidden inside it. Halfway through this process, I switched to [MR 93]. The task occupied me for fully six man-weeks (the elapsed time was much more, of course), and as it progressed I incorporated my knowledge into an ALGOL 68 program illustrating all the features, embedded within comments so as to read like a paper. At that time, the ALGOL
36
CHAPTER II
PAPER: A HISTORY OF ALGOL 68
Specialist Group of the British Computer Society announced a meeting to discuss the new language, so I circulated my document in advance under the title "ALGOL 68 with fewer tears" (non-native English speakers need to be aware of an English school textbook entitled "French without Tears"). On arrival at the meeting, at which three members of WG 2.1 (Duncan, Hoare, and Woodger) were present, I found that I was the only person there who knew the language well enough to present it, and I was hauled out in front to do just that. "Fewer tears" went through several revisions, appearing in the ALGOL Bulletin [Lindsey 1968], and finally in the Computer Journal [Lindsey 1972]. Of course my report contained errors, but the only important feature of the language I failed to spot was the significance of what could be done with records (or 8truets as they had now become), and the necessity for garbage collection arising therefrom. Nevertheless, it served as an existence proof of the language, and when Duncan took a copy to the next WG meeting it helped to redeem some of the damage. In addition to myself, several people (notably G. S. Tseytin of Leningrad) succeeded in interpreting the Report "from cold." In May 1968, the tenth anniversary of ALGOL 58, a colloquium was held in Ziirich, where the recently distributed [MR 93] came in for much discussion, being "attacked for its alleged obscurity, complexity, inadequacy, and length, and defended by its authors for its alleged clarity, simplicity, generality, and conciseness" [AB 28.1.1 ]. Papers given at the colloquium included "Implementing ALGOL 68" by Gerhard Goos, "Successes and failures of the ALGOL effort" [Naur 1968], and a "Closing word" [Wirth 1968]. Naur's paper contained criticism of [MR 93], as providing "the ultimate in formality of description, a point where ALGOL 60 was strong enough," and because "nothing seems to have been learned from the outstanding failure of the ALGOL 60 report, its lack of informal introduction and justification." IFIP seemed to be calling for immediate acceptance or rejection, and thus IFIP was the "true villain of this unreasonable situation," being "totally authoritarian" with a committee structure and communication channels entirely without feedback and with important decisions being taken in closed meetings. "By seizing the name of ALGOL, IFIP has used the effort for its own glorification." Strong words indeed! Wirth's contribution was also critical of [MR 93], and of the method whereby the WG, after a week of"disarray and dispute," and then "discouragement and despair" would accept the offer of any "saviour" to work on the problems until next time. Eventually the saviours "worked themselves so deeply into subject matter, that the rest couldn't understand their thoughts and terminology any longer." Both Naur and Wirth resigned from the Group at this time. However, Naur's point about "lack of informal introduction and justification" was correct. Starting from [W-2], which contained no informal material whatsoever, the amount of pragmatics in the successive drafts had been steadily increasing, particularly under pressure from Woodger, but it still had far to go. And Wirth's caricature of the meetings was not far off the truth. . . .
2.2.8
Tirrenia (June 1968)
Three and a half months after the distribution of [MR 93] (four days less, to be exact), WG 2.1 met to consider it. Van Wijngaarden had had a considerable response from readers of the ALGOL Bulletin, and came armed with pages of errata, including some modest language changes. There was concern that the use of the name "ALGOL 68" might turn out to be premature. Van Wijngaarden had been invited to talk on "ALGOL 68" at the forthcoming IFIP Congress, but there might be no ALGOL 68 by then. Randell questioned the need for the "mystical IFIP stamp," and others wanted publication delayed until implementations existed. But without the stamp, manufacturers would not implement it, so maybe it should be stamped, but with a proviso that it would be revised in the light of experience.
ALGOL 68 SESSION
37
C. H. LINDSEY Seegmialler pn~uced a list of demands: 1. An expanded syntax in an Appendix. 2. A formal semantics (perhaps using VDL [Lucas 1969]). But the WG had rejected that as far back as Princeton in order to avoid "unreadability." However, competitive descriptions ought to be invited. 3. There shotdd exist implementations. 4. There shotdd be an informal introduction to the language (and to its method of description), preferably within the final Report. 5. The final vote on the report should be delayed until all these requirements were met. In a series of straw votes, the WG showed itself in broad agreement with these requirements. But the meeting was not all like this. The bulk of the time was spent considering technical points of the language. Members would ask about some particular situation, and Van Wijngaarden would explain how the Report covered it. There seems to have been a consensus for approval of the language itself. It was the Report that was the sticking point. Came the last clay, and what were they to do? First, two decisions were made: 1. Changes already made to [MR 93] were too "substantive" for the Zandvoort mechanism to be applied (see 2.2.6 (1)). 2. The Warsaw resolutions (see 2.2.5 (2)) had been fulfilled. This put the whole project into limbo, with nobody charged to do anything anymore. At this point "~an Wijngaarden presented a Statement (some saw it rather as a threat) in which the authors offered to make just one more edition of the document, which would be submitted at some agreed moment to WG 2.1 which would then either accept it or reject it. If it was rejected, then the authors would have the right to publish it as their own. And he pointed out that the WG had worn out its first editor (Peter Naur), and then two authors (Wirth and Hoare), and now it might have worn out four more. After the tea break, this statement was turned into a formal resolution, and the authors were asked to produce their final draft by October 1 for consideration by a full WG meeting on December 16. 2.2.9
North Be~rwick (August 1968)
This meeting, held just before the IFIP Congress, had been fixed before the decision quoted above. Hence it was not clear what this meeting should do, except talk--which is just what it did. It was the first meeting that ',[ attended myself, and it was five days of continuous politics. For example, a poll was taken concerning the future work of the group, and the best part of a whole day, both before and after the poll, was taken up with its form, and how its results were to be interpreted. Mutual trust among the parties had been entirely lost, and jockeying for position was the order of the day, and of every day. Much time was devoted to discussion of whether and how minority reports might be attached to the final Report. Barely half a day was spent in technical discussion. The document before the meeting was [MR 95], a half way stage to the document requested in Tirrenia, and containing much improved pragmatics and also extensive cross referencing of the syntax. But at the end of the meeting it was clear that the future of ALGOL 68 was still very finely balanced. On a personal note, it was here that I met Sietse van der Meulen who had been asked by Van Wijngaarden to write the Informal Introduction requested by Seegmtiller at Tirrenia. He asked me to
38
CHAPTER II
PAPER:A HISTORYOF ALGOL 68 join him in this task, and together we worked out the plan of our book during the IFIP Congress the following week. 2.2.10
Munich (December 1968)
By October, Van Wijngaarden had circulated his report [MR 99] to the Working Group as promised. In the meantime, Ross had been trying to organize a Minority Report that would be constructive and well thought out [Ross 1969]. Also, Dijkstra, Hoare, and Randell each circulated drafts of brief minority reports, which they invited others to join in signing. At Munich, another draft was available [MR 100] whereas, some said, the meeting should have been considering only [MR 99]. To resolve this, three of us had to be dispatched to a side room to list all the differences between the two (not that I think anybody actually read our list). A draft of the first chapters of the Informal Introduction was also presented to the meeting by Van der Meulen and myself. Although this meeting had much political content, there was more willingness than at North Berwick to reach a compromise, and there was also more technical discussion. Nevertheless, there were clearly some who would wish to move on from ALGOL 68 and who were already considering (following discussion at a NATO software engineering conference two months earlier) the possibility of a group devoted to Programming Methodology. It was therefore proposed that TC2 should be asked to form a new Working Group in this area (WG 2.3, as it later became). To try to preserve the unanimity of the Group, a covering letter to be issued with the Report was drafted. This "did not imply that every member of the Group, including the authors, agreed with every aspect of the undertaking" but affirmed that "the design had reached the stage to be submitted to the test of implementation and use by the computing community." Then a motion to transmit the report with its Covering Letter to TC2 was proposed by Hoare and Woodger. There was heated discussion of the wording of the Covering Letter, but both it and the motion were accepted by substantial majorities, and we thought we were done. However, in the last hour of the meeting some who were unhappy with the final form of the Covering Letter, and with interpretations which were being put upon it, produced a minority report. It had been constructed at the last moment, based upon the draft circulated by Dijkstra, and could clearly have been improved if its authors had had more time. Following the agreements at North Berwick the meeting had to accept it, and the point was clearly made that TC2 should be asked to publish it alongside the main Report. In January of 1969, TC2 duly forwarded the Report and a mauled version of the Covering Letter to the IFIP General Assembly, which in a postal vote in March authorized publication. But TC2 refused to forward the Minority Report. The texts of the original Covering Letter and of the Minority Report are reproduced in Appendix A and Appendix B. 2.2.11
Banff (September 1969)
This was a very peaceful meeting by comparison with its predecessors. The agreed Report had been printed [MR 101 ], plus copious sheets of errata. Arrangements were in hand to have it published in Numerische Mathematik and Kybernetika. The decision of TC2 not to publish the Minority Report was regretted (but it had meanwhile been published in the ALGOL Bulletin [AB 3 I. i. 1]). During the meeting some small additional errata to [MR 101] were discussed (including a few extra representations to facilitate writing programs in ASCII). Thus was the final published text of [Van Wijngaarden 1969] established.
ALGOL 68 SESSION
39
C. H. LINDSEY
A much more substantial draft of the Informal Introduction was available, and discussions proceeded as to how it should be published. The decision was to ask TC2 to arrange for publication under IFIP copyright (which was subsequently done, and it appeared as [Lindsey 1971 ]). In order to promote implementation of the language and to provide feedback from implementors, the WG empowered Mailloux to set up an Informal Implementers' Interchange as a means of getting a rapid dissemination of implementation techniques. Later, at Manchester, this responsibility was taken over by Branquart. It never did work fully as intended, but it enabled us to know who was implementing and to provide a channel for communication to them. 2.2.12
SO What Had Gone Wrong?
It would be wrong to describe the seven who signed the Minority Report (or the two who resigned) as wreckers. They were all honourable men who cared about programming languages (even about ALGOL 68) and most of them had contributed substantially towards it. But their objections were diverse. First, it should be said that Dijkstra had attended none of the crucial meetings from St. Pierre to Tirrenia, and Garwick had been entirely absent from St. Pierre to the end (although he had been active on the I/O subcommittee [Merner 1966]). Some of them were opposed to the language. In particular, Hoare had grave misgivings about the language all along, as he has described in his Turing lecture [Hoare 1981 ], and he published his specific criticisms in [Hoare 1968]. He much preferred the way things had been done in SIMULA 67 [Dahl 1968]. Basically, he had hoped that more of the language definition could have made use of its own overloading facility (2.3.6), and he thought that the whole reference concept had been taken much too far (2.3.4.3). He had consistently expressed these opinions at the meetings, always in the most polite terms, always acknowledging the immense amount of work that Van Wijngaarden had put into it. It would seem that Wirth shared Hoare's views on most of these issues. For some, notably Dijkstra, the whole agenda had changed. The true problem, as he now saw it, was the reliable creation of programs to perform specified tasks, rather than their expression in some language. I doubt :ifany programming language, as the term was (and still is) understood, would have satisfied him. I think the rest were more concerned with the method of description than with the language, and with the verbosity and possible unsoundness of the semantics as much as with the W-Grammar (see [Turski 1968]). A:; Randell said at Tirrenia, "From our discussions . . . . it seems to follow that there is reasonable agreement on the language, but that there is the need for the investigation of alternative methods of description." But how had the WG managed to support the description so far, only to become so upset at the last minute? After all, [MR 93] was not so different in style from [MR 88], and the discussion of [MR 88] at Zandvoort had been all about the language, not the document. It may be that having three months to read it had changed their perception. Duncan in particular did not like the W-Grammar, but he did try to do something about it by proposing an alternative syntax notation and even a complete rewrite of Chapter 1. And [MR 95] was much more readable than [MR 93], as Woodger admitted at North Berwick (but Ross, when trying to produce his own minority report [Ross 1969], still could not get to grips with [MR 99] although he dissociated himself from the Minority Report actually produced). Contrariwise, in spite of all the complaints from within the working group, I must report that I have never heard an actual implementor complain about the method of description. The text of the Munich Covering Letter seems to have been the last straw, at least for Turski, who wanted a clearer expression of the preliminary nature of the Report and of the deep divisions within 40
CHAPTER II
PAPER: A HISTORY OF ALGOL 68
the WG. He also shared the view, often expressed by Hoare, on the necessity for simplicity in programming languages, and he has written on this [Turski 1981]. However, all the dissenters shared an exasperation with Van Wijngaarden's style, and with his obsessional behaviour in trying to get his way. He would resist change, both to the language and the document, until pressed into it. The standard reply to a colleague who wanted a new feature was first to say that it was too late to introduce such an upheaval to the document, then that the colleague should himself prepare the new syntax and semantics to go with it. But then, at the next meeting, he would show with great glee how he had restructured the entire Report to accommodate the new feature and how beautifully it now fitted in. Moreover, there were many occasions when he propagated vast changes of his own making throughout the document. 2.2.13
The Editorial T e a m
At Tirrenia, Van Wijngaarden described the editorial team in Amsterdam as follows: Koster Peck Maiiloux Van Wijngaarden
Transputer (from Oct. 1967) Syntaxer (on sabbatical from Univ. of Calgary Sep. 1966 to Jul. 1967) Implementer (doctoral student Apr. 1966 to Aug. 1968) Party Ideologist
Peck and Mailloux worked on the project full time, and all the pages of the Report were laboriously typed and retyped as changes were made. Van Wijngaarden, whose full time job was to direct the Mathematisch Centrum, would receive daily reports of progress. Mailloux was also responsible for ensuring that what was proposed could be implemented (as reported in his doctoral thesis [Mailloux, 1968]; see also 2.7.1). The use of a distinctive font to distinguish the syntax (in addition to italic for program fragments) commenced with [MR 93], using an IBM golf-ball typewriter with much interchanging of golf balls. Each time Van Wijngaarden acquired a new golf ball, he would find some place in the Report where it could be used (spot the APL golf ball in the representations chapter). In fact, he did much of this typing himself (including the whole of [MR 101 ]). From late 1967 on, intermediate drafts of parts of the document were circulated among an "inner circle" that included Yoneda, Goos' implementation team in Munich, Landin and, most importantly, the quadrumvirate of Michel Sintzoff, E Branquart, J. Lewi, and P. Wodon from MBLE in Brussels. This latter group was particularly prolific in the number of comments that they submitted, to the extent that there were effectively two teams involved--one in Amsterdam creating the text and another in Brussels taking it apart again. Peck continued to submit comments and suggestions after returning to Calgary, and he returned to Amsterdam to resume the old routine during the hectic summer of 1968.
2.3
THE CONCEPTS OF ALGOL 68
Historically, ALGOL 68 arose out of ALGOL 60 and, although it soon became apparent that strict upwards compatibility with ALGOL 60 was not a realistic goal, there was always reluctance to adopt new syntactic sugar for familiar constructs, and there were many rearguard actions to maintain, at least the appearance of, certain cherished features (such as switches, call-by-name, and Jensen's device). All this led to some strange quirks in the final product. From our present vantage, it is amazing to see how ill-understood in the early sixties were concepts that we now take quite for granted. It was at those early meetings of WG 2. I that these concepts were painfully hammered out. In spite of the differences that surfaced, the membership of WG 2.1 ALGOL 68 SESSION
4"1
C. H. LINDSEY
comprised as good a collection of international programming language experts as could have been gathered together at that time. Everybody had something to contribute, especially, perhaps, those who were eventual signatories of the minority report. 2.3.1
The Easy Bits
In spite of the stormy passage of some items, many new features were proposed and went into the language with hardly any discussion. Complex arithmetic (type c o m p l ) was accepted without qualm, as were bit patterns (type bits) and long versio, s of int, real, etc. (also short versions in [RR]). Naur [1964] proposed various standard operators (mod, abs, sign, odd, and so forth) and also 'environment enquiries' such as max int, max real, small real, and long versions thereof. It was agreed r.hat there should be a string type, but some wanted them to be of indefinite length with a concatenation operator [Duncan 1964], and some assumed that each string variable would be declared with some maximum length [Seegmiiller 1965a]. In both [MR 76] and [Wirth 1965] string was a primitive type. You could declare string variables, assign literal strings to them, and concatenate strings, but that was all; a delight to use, but requiring a heap for implementation. An inconclusive discussion at St. Pierre seemed to support the maximum length view, but in the event [MR 88] they turned out to be flexible arrays of the primitive type char. This meant that sub-strings could easily be extracted and assigned to, but the flex facility itself was a mistake (2.3.2). ALGOL 68 is still the only major language not to require a maximum length with each string variable. It was agreed Ihat the ALGOL 60 for-statement was too complicated (although hankerings after for-lists continued to crop up). Hoare [1965a] proposed what eventually became the loop-clause: for identifier fi,om first by increment to last do statements od where identifier is an implicitly declared intconstant (unassignable) for the duration of the loop only, andfirst, increment, and last are intexpressions to be evaluated once only at the start. It was agreed that there should be a separate while statement, although eventually it became just another option of the loop-clause (defaulting to true). That ALGOL 68 is an expression-oriented language is due to [MR 76], which made no distinction between expressi,ans and statements (this idea having been first proposed in [Wirth 1966a]). Thus, all forms of conditional-, case- and closed-clauses (that is, blocks) return values, as do (after [W-2]) assignations. For example, x := (reala = p ' q ; realb = p/q; ifa>b t h e n a e l s e b fi) + (y := 2*z); In addition, it is also possible to declare an identifier as an (unassignable) constant (as a and b above). Neither of these fi~atures was in [Wirth 1965], although constant-declarations were in [Seegmtiller 1965b]. They are, of course, now the basis of functional languages such as SML [Milner 1990], but contemporary imperative languages seem to have fought shy of being expression-oriented, although constant-declarations are now well accepted (as in Ada). The example shows another important feature that appeared without comment in [W-2], namely the matching of if by fi (likewise c a s e by e s a c and, in [RR], do by od). This removes the dangling else problem and, at the same time, the requirement for a compound-statement. Most modern languages have followed this lead except that, being without any sense of humour, they reject the easily memorable fi in favour of end if, or endif, or even plain end. (How do you remember which one it is?)
42
CHAPTER II
PAPER:A HISTORYOF ALGOL 68 2.3.2
Arrays
A 2-dimensional array can be regarded in two ways. First, it can be an array of arrays, and this was the view taken in both [Wirth 1965] and [MR 76]. Thus, one might expect to declare Ioc [1:4][1:5] int a4a5;
and subscript it by a4a5[i][j], and the type of a4a5 would be described as 'row of row of integral' (indeed that example is legal in [RR]). A consequence is that a4a5[i] is then a row-vector, but there is no way to construct a column-vector. WG 2.1 understood and approved" this at St. Pierre, Bauer remarking, "It is not necessary for our two-dimensional arrays to have all the characteristics of matrices." But they did ask that " ] [ " be written as "," allowing a4a5[i, j ] after all (but titter ye not! for this is exactly the situation now in Pascal, and also in ALGOL W as implemented [Wirth 1966c]). In [W-2], however, we find genuine 2-dimensional arrays: Ioc [1:4, 1:51 inta45;
subscripted by a45[i, j ] and with type 'row row of integral' (also legal in [RR]). Semantically, this was modelled in [R] as a linear sequence of elements together with a descriptor composed of an origin c, and two each of lower bounds//, upper bounds ui, and strides si. The element at a45[i, j ] is then found in the sequence at c + (i-l/) * s / + (j-12) * s2. This suggests an obvious implementation. Moreover, it now allows all sorts of slices, such as
a4512, 1 a45[ , 3] a4512:3, 3] a4512:3, 2:4]
row 2 column 3 part of column 3 a little square in the middle.
This was accepted with enthusiasm; it is simple to implement and does not hurt those who do not use it; I cannot understand why other languages (excepting, in some degree, PL/1 ) have not done the same. It also provides the possibility to extract diagonals, transposes and the like. The next facility added, in [MR 88], was flexible arrays. These allowed the size of an array variable to be changed dynamically. Ioc flex [I:0] int array; array := (!, 2, 3); array := (4, 5, 6, 7, 8)
# initially empty # # n o w it has bounds [1:3] # # now it has bounds [1:5] #
That seems nice, but every student who has ever tried to use the facility has wanted to extend the array with bounds [i:3] by adding 5 extra elements at the end, leaving the existing values in array[l:3] untouched. But that goodie is not on offer, and what is on offer can be achieved in other ways anyway. Van Wijngaarden has explained to me that flexible arrays were provided simply to facilitate strings, which are officially declared as mode string = flex [1:0] char;
But strings can be extended Ioc string s := "abe"; s +:= "defgh"; # now s = "abcdefgh" #
ALGOL 68 SESSION
43
C. H. LINDSEY
It would have been better, in my opinion, to omit the flex feature entirely and to provide strings as a primitive type. In [RR] flex was made a property of the reference to the array rather than of the array itself, thus bringing flexibility within the strong typing. This avoided a run-time check required in [R] to prevent the preservation of refs to no-longer-existent elements of flex arrays. It was a fundamental principle that every value in the language should be expressible by some external denotation. Hence the row-display (the (4, 5, 6, 7, 8) in the example) has been present since [MR 76], although the corresponding structure-display did not appear until after Tirrenia. Unfortunately, this does not provide a convenient way to initialize the whole of an array to some same value (Ada has better f~tcilities in this respect), and another problem, pointed out by Yoneda, is that although 0 and (1, 2) are valid row-displays, (i) is not (it is just a / with ( ) around it), and if you want to initialize your array with it you have to rely on the rowing coercion (2.3.3.5). Oddly, this bug was also present in the Preliminary Ada Reference Manual--Plus ~a change .... Operators Iwb and upb were provided in [MR 99] to determine the actual bounds of any given array. These replaced the less useful flexible-bounds used up to then in formal-parameters (as in [l:intupper] inta). However, bounds could still be specified, optionally, in formal-parameters. This possibility was removed in [RR] because, so it was said, there was nothing useful that implementors could do with that information. I now think this was a mistake, since to have such preconditions (even if all they trigger is a run-time check) can simplify writing the body of a routine. 2.3.3
Coercion
Although coercions had existed in previous programming languages, it was ALGOL 68 that introduced the term and endeavoured to make them a systematic feature (although it is often accused of a huge overkill in this regard). They existed in [W-2] (not by that name) but reached their full fruition in [MR 93], provoking three quarters of a day's discussion at Tirrenia. Coercion can be defined as the implicit change of the type (a priori) of an expression to match the type (a posteriori) required by its context. There were eight different coercions in [R], diminishing to six in [RR]. These will now be examined, starting with the least controversial. 2.3.3.1
Widening
You can 'widen' from int to real and from real to compl. This is quite natural, and most languages (Ada is the notable exception) allow it. Note that there is no 'narrowing' in A L G O L 68 as there is in
FORTRAN and PL/1. Thus realvariable := intvalue is allowed, but not intvariable := realvalue. 2.3.3.2
Dereferencing
This changes a reference into the thing referred to. Thus, having declared y as a real-variable, so that its type is refreal(2.3.4.3), it is necessary to dereference y in x := y. The term 'dereferencing' is now used by many languages (even those that call their references 'pointers' and those that use an explicit operator for the purpose). 2.3.3.3
Deproceduring
This is the m e t h ~ whereby parameterless procs are called (the alternative used by some languages is to write PO). A coercion is necessary to distinguish the case requiring the value returned by
44
CHAPTER II
PAPER:A HISTORYOF ALGOL 68 the proc (as in I o c r e a l x : = random) Ioc pro¢ anotherrandom := random). 2.3.3.4
from
that requiring
the
proc
value
itself (as in
Uniting
Any language with unions needs this coercion, which can turn, for example, an a priori int into an a posteriori un/on( int real). These four coercions are uncontroversial, either they, or some syntactic equivalent, being obviously necessary to perform their respective functions. The next four are all peculiar in one way or another. 2.3.3.5
Rowing
This turns a value of some type into an arrayof that type, but it is not, as might be expected, a means to initialize a whole array to some given value. Rather, it produces an array with just one element, and the only reason it exists is to overcome the Yoneda ambiguity described in 2.3.2. Consider [] intzero = O, one = (1), two = (i, 2); 0 and (1, 2) are row-displays yielding arrays of, respectively, 0 and 2 elements. (i) however is a closed-clause and its a priori value is an int, which must be 'rowed' to make an array of 1 element to suit the context. The same thing arises with strings: string zero = "", one = "A . , t.w.o =. . .~AB ; since "A" is, a priori, a character-denotation whereas "AB" is a string-denotation. The rowing coercion was clearly a mistake. There just has to be some other way (some new kind of brackets perhaps) to solve this problem. 2.3.3.6
Proceduring
It was agreed at St. Pierre that the elaboration of operands should be in parallel, to the discouragement of side effects (2.3.8). However, at Warsaw McCarthy raised the issue of or and and, where it might be considered reasonable not to elaborate the second operand if the first had already determined the outcome (as in true or doesitmatter). Although McCarthy pressed strongly, it was agreed to leave matters alone in the interest of semantic consistency. What did appear, instead, was the procexluring coercion, as in the following example taken from [R 7.5.2]. op c a n d = ( bool john, proc bool mccarthy) bool: if john then mccarthy else false fi;
Now, in p candq, q is 'procedured' from boolto proc bool and, according to the definition of cand, the resulting proc will never be called unless p turns out to be true. The proceduring coercion can also be used to make Jensen-like operations look more Jensen-like when f o r m a l - p a r a m e t e r s are parameterless procs. Now the proceduring coercion complicated the syntax considerably (it is necessary to avoid cycles of proceduring and deproceduring) and it was a pain to implement. Moreover, it did not do the job it was intended to do, for in p cand (a := b; q)
ALGOL 68 SESSION
45
C. H. LINDSEY it is only q that gets procedured, and a := b is elaborated whetherp is true or not. For these reasons, procedufing was removed entirely from [RR].
2.3.3.7
Hipping
Jumps, skip,
and n//have no type a priori, but they can occur in some contexts where a value is (syntactically) expected (for example, x := ifp then y else gore error fi). In [R] they were said to be 'hipped' to the required mode. The same things are acceptable in [RR], but are not described as coercions.
2.3.3.8
Voiding
Voiding is a trick to satisfy the syntax when, upon encountering a ';' (as in x := y; a := b), the value of the unit just elaborated (x := y) is to be discarded. The user need not be aware of it. The real complication of the coercions lay in the rules that governed how they might be cascaded. The removal ofproceduring simplified things considerably, as may be seen by comparing the Coercion Chart on page 208 of [Lindsey 1971] with that on page 196 of [Lindsey 1977].
2.3.4 The Type System (or Records, References, and Orthogonality) Orthogonality, as ~tguiding principle of design, had been introduced by Van Wijngaarden in [MR 76]. The idea was that if a range of features (say type constructors) exists along one axis, and another range (say types) along another, then every meaningful application of the one to the other should be present in the language. Whether WG 2.1 had accepted it as a guiding principle is another matter. The effect of thiis principle on the language is nowhere more apparent than in the case of parameter passing and records--features that are superficially unrelated.
2.3.4.1
Parameter Passing
It is said that an Irishman, when asked how to get to some remote place, answered that if you really wanted to get to that place, then you shouldn't start from here. In trying to find an acceptable parameter-passing mechanism, WG 2.1 started from ALGOL 60 which, as is well known, has two mechanisms--call-by-value (which is well understood) and call-by-name (with which is associated Jensen's Device, and which is nowadays regarded as obsolete). Starting from ALGOL 60 was a mistake. All subsequent proposals were measured by how well they stood up to the classic Innerproduct and other such Jensen paradigms. ([R 11.2, 3, 4] contains no less than three innerproduct examples.) Moreover, they still used the term 'name' even when discussing alternatives that might replace it. It was soon realized that there were two cases of call-by-name; where the actual-parameter was an expression and a 'thunk' had to be generated (sometimes termed 'call-by-full-name'), and where the actual-parameter was a variable to be assigned to (which was thus termed 'simple-name'). Here is the classic example of Jensen's device in ALGOL 60, the lnnerproduct example from [Naur et aL 1962]: procedure lnnerproduct(a, b) Order: (k, p) Result: (y); value k; integer k, p; real y, a, b;
46
CHAPTER II
PAPER: A HISTORY OF ALGOL 68 begin real s; s : = O; forp := ! step 1 untilk dos := s+a*b;
y:=$ end Innerproduct
and here is a call:
real arrayxl, yl[l:n]; integer j; real z; lnnerproduct(xl[j], yl[j], n, j, z); Observe that the formal-parameters a and b are called-by-(full-)name, and p and y are called-by(simple-)name. See how j, the actual-parameter for p, is also used within the actual-parameters for a and b. The semantics of call-by-name then require that the for-statement behave as if it had been written f o r j := I step I untilk dos := s + x l [ j ] * y l [ j ] ; In [MR 76] formal-parameters could be marked as val, Ioc or var, which might nowadays be rendered as in, outand in out. Things declared Iocor varcould be used on the left of an assignation, and things declared val or var within expressions on the right. p r o c f = (real val x, real Ioc y, real var z) real..... ; In a call off, the coercion rules allowed •
an intor realvalue forx;
•
a real or compl variable for y;
•
only a real variable for z.
Actual-parameters must be compatible with their formal-parameters as regards val, Ioc, or var, so that the accident of assigning to an expression, which could happen (and be detected only at run-time) in A L G O L 60, is avoided. If call-by-full-name is required, it must be indicated by expr: at the point
of call. Here is innerproduct:
proc innerproduct = (real vel a, b, int val k, int Ioc p, real Ioc y) void: begin real var s := O;
forp := ! step ! until k # A L G O L 60 loop semantics # d o s := s+a*b;
y:=s end; and here is a call: Ioc [ l : n ] realxl, y l ;
Ioc i n t j ; Ioc realz;
innerproduct(expr." xl[j], expr: yl[j], n, j, z); Seegmiiller [ 1965b] proposed that formal-parameters for call-by-full-name should be explicitly declared as parameterless procedures (that is, explicit thunks), with the corresponding actual-parameter indicated at the point of call (as in [MR 76]). Simple-name parameters, however, would be explicitly declared reference (and reference variables were also to be allowed, but reference reference types were forbidden). An explicit refoperator was provided to indicate that a reference to some variable, rather than to its contents, was to be taken (if you like, an anti-dereferencing operator like the '&' of C). ALGOL 68 SESSION
47
C. H. LINDSEY
let reference ,ii; int i; ref ii := ref i; # to assign a reference to i #
ii := i;
# to assign the let in i to the place indicated by ii #
Here is innerproduct:
proc innerpro, duct= ( ptoc real a, b, int k, int reference p, real reference y) void: begin Ioc real s := O; for p := 1 step I until k #ALGOL 60 loop semantics # do s := s+a*b; y ::= s end; And here is the cdl: Ioc [ l : n ] realxl, y l ; Ioc intj; Ioc realz; innerproduct(expr: xl[j], expr: yl[j], n, refj, refz); One can see how Seegmtiller's proposal derived from EULER [Wirth 1966a], but EULER was a dynamically typed language so that references could refer to values of any type. EULER was the first language, so far as I am aware, to introduce the terms 'call-by-reference' and 'call-by-procedure'. At St. Pierre, Hoare presented a concept of 'value/anti value', which appears to have been what we now call 'copy/copy back'. At any rate, this is what appeared in [Wirth 1966b] alongside an untouched call-by-name as in ALGOL 60 and parameterless procedure parameters (to be matched by statements or expressions in the actual-parameters). Here is innerproduct in ALGOL W: procedure innerproduct (real a, real procedure b, Integer value k, Integer p, real result y); beginy := O; p := I; while p_ b then a else b fi; op m a x = (rea~r a, b)reah i f a>b then a else b fi;
Observe that the ~)dy of max is just a routine-text, so it might be said that we have just a fancy new way of calling procs, but observe also that we have separate definitions of m a x for the cases int-int and real-real (and int-real and real-int ought to have been defined also). Thus m a x has been 'overloaded', and to see which version of m a x is intended in any particular context the compiler simply has to look at the types of its two operands. Contrast this with the situation in Ada (which along with C++ [Stroustrup 1996], has adopted this overloading) in which, not only the types of the operands, but also the type required for the result must be taken into account. This puts a hugely increased burden on the compiler, with little real practical benefit that I can see. Now it is the coercion of the operands that provides the interest in overloading. Clearly, in x m a x y the coercion of x and y must not be allowed to include widenings, but it should include the 'firm' coercions such as dereferencing (for x and y might well be variables of type ref int, say). We have 54
CHAPTER II
PAPER:A HISTORYOF ALGOL 68
also modified the rules of block-structure, for a block can now contain several definitions of the same operator, but not so that more than one of them can be legitimately chosen in a given formula. There has to be a rule forbidding the coexistence of two definitions the types of whose operauds are 'loosely related' [R 4.4.2.c] or 'firmly related' [RR 7.1.1 ]. (Checking this property is quite hard work, and in the sublanguage promulgated in [Hibbard 1977] there is a less permissive 'meekly related' rule.) Incorporating overloading into the Report was a major upheaval. Not only did the coercion rules and context conditions have to be overhauled, but all the existing "built-in" operators had to be taken out of the syntax and replaced in the standard-prelude. At Zandvoort, Yoneda asked why could not procs be overloaded also? Because we expect to be able to do widening coercions to actual-parameters (note that Ada can overload its procedures because it has no widening coercion). Hoare [1968] wanted subscripting, ' : = ' and even ';' to be defined as overloaded operators, but these would have needed user access to the descriptors of arrays (dangerous), right-associative dyadic-operators, and other such complications. 2.3.7
Labels and Switches
ALGOL 60 had the most horrendous collection of labels, designational-expressions, and switchdeclarations. Trouble was that people got used to using them. (This was long before such things had been declared "harmful" [Dijkstra 1968b]), and as a result some really horrid constructs were proposed (some even made their way into the final language). Things actually started by getting worse. Duncan [ 1964] proposed label as a type, with arrays of them instead of switches, and the ability to jump into a block. Naur [1964] realized that an environment has to be a part of every label value, rendering jumps into blocks inappropriate. The solution to the switch problem came with [Hoare 1964], which proposed a case-clause of the (eventual) form case
integer expression in first, second, third
esac
but without any out (or o t h e r w i ~ option). Clearly, this would be implemented by a table of jumps (in contrast to the ease-clause in more recent languages where each alternative is preceded by a possible value of the expression). This was well received, and was the end of the ALGOL 60 switch (but it still left the possibility of label values and arrays thereof). At St. Pierre, Wirth [1965] would not allow jumps into a syntactic entity, nor any designationalexpressions (these were accepted), nor labels as parameters (which was not accepted). Van Wijngaarden then asked whether declarations might not be labelled (apparently so that one could jump back to them to change the size of arrays). Surprisingly, and in the face of grim warnings from Hoare, the meeting agreed to let him look into this (but fortunately the idea never came to fruition). label variables and parameters had been a feature of [Seegmiiller 1965b], but following St. Pierre the only way to pass a label around was to encapsulate it as a j u m p inside a prec. So Seegm~iler complained that to pass label to a procedure p he would have to write something like p(expr: gore label). Van Wijngaarden promised to look into it. The result was that, in [MR 88], first a j u m p in a suitable context was automatically turned into a proc, allowing p(goto label); and second the gore in a j u m p was made optional (to the great inconvenience of compiler writers, as it transpired), allowing p(label). But worse! Van Wijngaarden was now able to exhibit his pride and joy--his pseudo-switch [R 8.2.7.2].
[ ] proe voidswitch = (el, e2, e3); #el, e2 ande3 are jumps to labels # switch[i];
ALGOL 68 SESSION
55
C. H. LINDSEY
or even Ioc [1:3] proc' voidswitch := (el, e2, e3); switch[2] := el; To my shame, I must admit that this still works in [RR], although implementations tend not to support it. 2.3.8
Parallel and Collateral
At St. Pierre there was discussion as to whether the order of elaboration of the two operands of a formula, or of the actual-parameters of a call, or of the two sides of an assignation, should be prescribed. In spite of some protest from Naur, it was agreed that it should be explicitly undefined (and all subsequent languages seem to share this view). Meanwhile, [MR 76] contained a proposal for explicit parallelism in which the elementary actions in the parallel branches were to be merged in an undefined order. This was agreed (again over the protests of Naur) but with the proviso that a serial elaboration should be among the legal interpretations (hence there was no idea of fairness). Questions of synchronization and resource sharing were hardly discussed, it being supposed that interlocks could easily be programmed (that this was not so was shown by [Dijkstra 1968a], of which earlier drafts were available in 1965, but apparently not known to the WG). However, [MR 76] also suggested that elaboration of operands of a formula and so on should be implicidy in 'parallel', thus going further than merely undefining the order. Of course the reason was to allow the implementor as much leeway as possible to introduce optimizations, and it later turned out that this proposal also permits the elimination of common sub-expressions, even when they contain side effects. Certainly there was a demand for genuine parallelism (see for example [Dahl 1966]), and by the time the issue was discussed at Zandvoort, [Dijkstra 1968a] was well known; hence [MR 88] provided for the symbol elem in front of a closed-clause, the whole of which was to be treated as an elementary action. Van Wijngaarden seemed to think this sufficient to enable Dijkstra's semaphores to be written (but I cannot see how he could have avoided using spin locks). Randell then proposed that semaphores should be included as an explicit feature. This led to a bad attack of cold feet concerning whether parallelism should be in at all, and if so whether it was to support multiple processes on one or more processors, or was just a device to undefine the order of elaboration. The trouble was that [MR 88] did not distinguish between these two usages. The outcome was that in [MR 93] the term 'collateral elaboration' was used to indicate where the implementor might do his optimizations, and an explicit construction
par begin process l, process2, process3 end was introduced for 'parallel elaboration', within which Dijkstra's semaphores (written as up and down) could be used [R 10.4; RR 10.2.4]. The elem symbol was still present, but it had disappeared by [MR 101 ]. Wit]h hindsight, it is debateable whether such a low-level feature as the semaphore was a proper feature of such a high-level language. At North Berwick, even Dijkstra was expressing doubt on this point.
56
CHAPTER II
PAPER:A HISTORYOF ALGOL 68 2.3.9
Transput
The report of the I/O subcommittee established at St. Pierre [Mcrncr 1966] was in the form of an addition to [Wirth ] 965]. It provided separate procedures for converting numerical values to/from strings, as opposed to transmitting them to external media (an explicit request of the WG at St. Pierre). There was an elaborate system of formats (represented internally as strings), largely derived from [Knuth et al. ]964]. At Zandvoort, the WG asked for an explicit format type (one benefit of which was the possibility of introducing dynamic-repllcators). However, this was about the only action on transput taken by anybody up until October 1967, when Kostcr returned from his military service and serious work began. Kostcr's main contribution was the 'rectangular book' model in which an external document was conceived as composed of so many pages, each of so many lines, each of so many characters, it being the responsibility of the system to keep track of the 'current position' and to institute action if the boundaries were exceeded. (ALGOL 68 is the only major language to provide this service.) Actually, the prime reason for adopting this particular model was to ensure implementability on IBM mainframes, whereon the alternative idea of a file as an undifferentiated stream of characters (with perhaps some newlines thrown in) would be quite unimaginable. (Just think--there might then be more than 80 characters between newlines.) IBM was not to be given any such excuses. The conversion and transmission of values were now recombined so as to provide a usable system, although the explicit conversions to/from strings were still present (but in a not very satisfactory form, so that in the revision new functions whole,fixed, andfloat were provided in their place). For reasons of orthogonality, the transput of struats and arrays had appeared (as 'straightened' sequences of their primitive components). A nice feature was the ability to gather a sequence of disparate values and layout procedures into one procedure call:
print((newpage, "Some Title", newline, "index = ", someinteger, space, somestruct, ", ", somereal, newline)); With the removal of the type i r a after Warsaw, this had to be done by a fictitious union of all transputable types, and it required some trickery to fit it into the language framework. The proe read was made to be, so far as possible, complementary with print. The formats were derived from those of [Merner 1966] with the addition of dynamie-replicators, and alignments to control line and page endings. Considerable effort was devoted to making the action of formats on input complement that on output. [MR 93] was the first that anyone had seen of the detailed transput specifications, but serious discussion was lost in the general furore about other matters. Following discussions at Tirrenia, 'on' routines to handle exceptions such as line and page overflow, and facilities for opening named files were added in [MR 95]. However, many detailed problems remained. If you took it too literally (and evidently you were intended to take the rest of the Report literally) you found that all sorts of strange behaviours were mandated. The changes in the revision were mostly minor, to remove such unintended behaviours. They were concerned with the fact that the old model assumed every line to be padded with spaces to some fixed width and with a presumption that the particular-program was the only program running in the whole universe. Various problems with formats were fixed (for example, that the effect of the format $ 5z $ differed from that of $ zzzzz $). The only new features were the conversion routines whole, fixed, andfloat, and the facility to associate a filo with a []¢harin place of an external book.
ALGOL 68 SESSION
57
C. H. LINDSEY 2.4 WG 2.1 membersactive in the revisionof ALGOL68
TABLE
Of the members already listed in Table 2.3, the ones who continuedto he active in the revision were Bauer, Bekic, Goos, Koster, Lindsey,Mailloux, Paul, Peck, Van der Poel, Samelson, Sintzoff, Van Wijngaarden,and Yoneda. Newcomersto the scene were: Steve Bourne Bell Labs, Murray Hill, NJ Westinghouse Research Labs, Pittsburgh, PA [Secretaryof WG 2.1] Henry Bowlden lan Currie RRE, Malvem, UK Paul Branquart MBLE, Brussels Peter Hibbard University of Liverpool, UK Lambert Meertens Mathematisch Centrum, Amsterdam Sietse van der Meulen Rijks Universitaet, Utrecht Stephen Schuman IRIA, Paris Robert Uzgalis UCLA,Los Angeles,CA
2.4
HISTORY OF THE REVISED ALGOL 68 REPORT
2.4.1
Drarnatis Personae
Many who had earlier been prominent in WG 2.1 resigned from the group after Munich (most moving over to the newly formed WG 2.3), although Turski, Duncan, and Hoare remained in WG 2.1 for the time being. Table 2.4 lists some new members active in the revision, The style of W G meetings, under the new chairman, Manfred Paul, was very different (and less confrontational). Much of the work was done by setting up subcommittees, each with a Convenor who could invite members from both within WG 2.1 and outside. 2.4.2 2.4.2.1
Improvements
Habay-la-Neuve to Fontainebleau
Habay-la-Neuve (July 1970) was the week after a TC2-sponsored conference on A L G O L 68 Implementation in Munich [Peck 1971 ]. Although the implementations by Goos at Munich and Branquart at MBLE had been underway since before the finalization of[R], the race had been won by an outsider, a team from the Royal Radar Establishment at Malvern in England, who had implemented a dialect they named A L G O L 68R. This had caused quite a stir at Munich. It was simple, and it worked, even though it was not quite A L G O L 68. There had also been discussion at Munich about features that had caused implementation problems, and there had been suggestions for sublanguages that would avoid them. At the meeting, there was a wish-list, prepared by Van Wijngaarden and myself, of things we might like to change. As ttne meeting progressed, this list was augmented until it was three times its original size. A selection of these items for serious consideration was chosen, and an ad hoe subcommittee on "improvements" hammered them into shape. It was clearly envisaged that there was going to be a Revised Report, and there was tension between doing it later (to make it as complete as possible, an option strongly advocated by Samelson) and doing it earlier (so that fewer implementations would 58
CHAPTER II
PAPER:A HISTORY OF ALGOL 68
be affected). There was, however, a firm decision that, when the time came, there would be just one revision "once and for all." The pattern established was for the two subcommittees established at this time to meet between and during WG meetings and to produce reports for consideration by the full WG. After each meeting, some official message from the WG to the Computing Community would be published in the ALGOL Bulletin, together with edited versions of the subcommittee reports. So after the Manchester meeting (April 1971), a letter to the readership of the ALGOL Bulletin, quoting from the Covering Letter (Appendix A) the remark about having subjected ALGOL 68 "to the test of implementation and use," announced that there would presently be a single Revision but that, in the meantime, the changes under consideration were being published "for their critical appraisal [WG 2.1, 1971 c]. By the time of Novosibirsk (August 1971) it was felt possible to fix a definite timetable, and a formal resolution [WG 2.1, 1972a] laid down that the definitive list of changes would be published in theALGOL Bulletin after the next meeting, at which time editors would be commissioned to prepare the Revised Report, which was to be approved and published before the end of 1973. This schedule was known to be extremely tight, and Sintzoff pointed out that two further meetings of the Maintenance subcommittee would be required before the next full meeting. Fraser Duncan, who had edited the ALGOL Bulletin since shortly after the beginning of WG 2.1, had announced his intention to resign, and a.t a moment when I was absent from the meeting attending to some business or other I was elected to take his place, a post I held until the ALGOL Bulletin finally expired in 1988. At Fontainebleau (April 1972), the Editors commissioned were Van Wijngaarden, Mailloux, and Koster, together with Sintzoff and Lindsey (the convenors of the two sub committees). Peck, who was now Professor at Vancouver, did not become an editor officially until the following meeting. Our brief, as expressed in the formal resolution, was to "consider, and to incorporate as far as practicable" the points from the two subcommittee reports and, having corrected all known errors in the Report, "also to endeavour to make its study easier for the uninitiated reader" [WG 2.1 1972d]. 2.4.2.2
Maintenanceand Improvements
This subcommittee, successor to the ad hoc improvements subcommittee at Habay, was officially constituted at Manchester with Sintzoff as convenor (although I acted as the "scribe," keeping the texts of the reports on paper tape and editing them on a Flexowriter). It met at Amsterdam (August 1971), Malvern (November 1971), and Brussels (February 1972), as well as during WG meetings, and each time it passed over the accumulated proposals together with comments received, and everything that was deemed "safe" by the fidl WG was published [WG 2.1 1971 b, 1972b, and 1972e]. The report presented at Fontainebleau contained 53 specific suggestions for change, which were discussed, re-examined, and voted upon every which way. Many points that had seemingly been decided at earlier meetings were reopened and revoted, not always with the same result. By the time [WG 2.1 1972e] was published in the ALGOL Bulletin, implementors of the language had a pretty good idea of what was going to happen, arid could bend their implementations accordingly. After that the responsibility for improvements effectively passed to the Editors, who brought further items to the Vienna meeting, resulting in [WG 2.1 1973a], and to Dresden and Los Angeles, resulting in [WG 2.1 1973b]. In the event, the agreed changes amounted to a thorough tidying up of minor ambiguities, oversights, and inorthogonalities in the original language. Various redundancies, most notably proceduring (2.3.3.6) and formal bounds (2.3.2), were removed. ("The language is too fat," as Bauer remarked at Novosibirsk.) void became a type, flex became part of the type (2.3.2), a new confor-
ALGOL 68 SESSION
59
C. H. LINDSEY
mity-clause replaced the old conformity-relation (2.3.4.6), and various matters of representation were tidied up (fi)r example, you could no longer write itc I a I b esac). The only major language change that migh:t have happened, the lifting of the extent restriction on procs advocated by Bekic (2.3.5), was left to a possible future extension. 2.4.2.3
Data pA,ocessingand Transput
This subcommittee was established at Habay with myself as convenor. It met the week before Manchester and considered many small changes to tidy up the transput. However, its main consideration was a concept, of 'record transfer' in which complex structures could be sent to backing store and later retrieved exactly as they had been written. There was a concept of a 'masskey', which was to backing store what a ref was to ordinary store, and there was a proposal for ' m o d a l s ' - - a facility for genefic/polymorphic procedures. These things continued to be discussed for some considerable time, but never did make it into the revision. A further meeting was held in Amsterdam (August 1971 ), after which transput discussions tended to happen at the s~,me time as the Maintenance subcommittee. The reports of this subcommittee were [WG 2.1 1971 a, 1972c, and 1972f]. At Fontainebleau, we presented 32 specific suggestions for change but we ran out of time before these could be discussed. (It has always been a problem within the WG to get people who have a strong understanding and concern for language issues to discuss transput seriously.) The transput proposals were therefore all left for decision until Vienna, where they were mostly accepted and included in [WG 2.1 1973a]. The changes were mostly minor, and have already been described in (2.3.9). 2.4.3
Revision
Of the Editors appointed, Van Wijngaarden immediately announced that he would leave all the hard work to the rest of us, and in the event, Koster, who was in the process of becoming Professor at Berlin, did not play an active role either. The rest of us were geographically well separated: myself in Manchester, Mailloux in Edmonton, Peck in Vancouver, and Sintzoff in Brussels. For keeping the text, machine assistance was needed, and we decided to keep it on the MTS system at Edmonton using a line editor called ed and a formatting program known asfrnt. Edmonton had an AM typesetter for which we had a special disc made. It was the craziest mixture of fonts and symbols ever found on a typesetter disc, which may explain why it took them over two years to produce it. Mailloux was in charge of the text, and wrote a typesetting program compatible with.tint. 2.4.3.1
Vancouver(July 1972)
John Peck invited us all to spend three weeks in Vancouver during July. There we all became familiar with MTS, ed, and.tint, and agreed how to divide the task. I was to be responsible for Chapters 1 and 2, which introduced the syntax notation and the semantic model (2.5.2). Peck was to be responsible for the syntax, and Sintzoff for the semantics. Mailloux was to be Keeper of the Text. We invented (or discovered) production trees, predicates (2.5.1.2), ' N E S T ' s (2.5.1.3), and environs (2.5.2), and established a new 'structured' style for the semantics (2.5.3). Sintzoffreturned home via Edmonton, and as he sat in Mailloux's office the telephone rang. There was a temporary nine-months teaching post available, and did he (Mailloux) know anyone who could fill it? Well of course he did! Thus it came about that the centre of gravity of the whole operation moved to Canada. It was particularly fortunate that Vancouver and Edmonton ran the same MTS operating system. 60
CHAPTER II
PAPER: A HISTORY OF ALGOL 68
2.4.3.2
Vienna(September 1972)
The next WG meeting was in Vienna. (The Editors had a private meeting beforehand.) We had available samples of what we had written, in particular the ' N E S T ' syntax (2.5. i .3), and also a large number of detailed issues to raise on the improvements. The meeting gave first priority to transput, whose discussion had been curtailed at Fontainebleau, and then proceeded to discuss and vote on the various improvements. But then started the biggest attack of cold feet I have ever witnessed (brought about, perhaps, by the extent of the changes we were proposing to the method of description, and by the ~NEST' syntax in particular). A "Petition for the Status Quo of ALGOL 68," signed by five members and five observers, claimed that the Revised Report had become a pointless undertaking (beyond a few corrections to ambiguities or inconsistencies) and that the idea should be abandoned. This was debated on the very last day of the meeting. The motion was that the revision should consist of [R] plus an addendum, and the petitioners produced a small list of the changes they conceded should be allowed (and clearly there was no time left at that meeting to re-vote all the detailed decisions already made). We pointed out that some errors (for example, the infinite mode problem (2.5.1.4)) were almost impossible to correct in the old framework; we pointed out that implementors seemed content with the intentions as published and that only three implementations were anything like complete (and Malvern already incorporated many of the changes); we pointed out that, to remove troublesome points so as to have a basis for upwards-compatible future extensions, we would need at least twice the list proposed by the petitioners; we pointed out that it would then require an addendum half the size of the Report, and that it was crazy to define the changes to be made by the length of an addendum--we were getting nowhere, and now it was time for the vote. It had long been a Working Group tradition to phrase straw votes in the form "Who could live w i t h . . . ? " rather than "Who prefers...?" Therefore, to let everybody see the full consequences before taking the formal vote, I proposed the questions, "Who could live with the state if the resolution was passed?" and "Who could live with the opposite state?" The results were 12-5-1 (for-against-abstain) and 12-1-5. Now Van Wijngaarden was always a superb politician. Having observed who had actually voted, he now pointed out that passing the resolution "would cause the death of five of the six editors. That seems a most unproductive situation." And when the formal motion was put the vote was 6-6-6, and we were through. 2.4.3.3
Revision by Mail
For the next nine months we worked separately on our pieces. Each circulated his texts to the others, and we all checked each other's work. The text of the syntax was maintained in Vancouver and the rest in Edmonton. (Periodically, I sent long ed scripts to Edmonton on paper tape--and surprisingly they usually worked without error.) This method of collaboration proved to be exceedingly fruitful. You don't launch a text over such distances until you are quite sure it is really what you intend to say. We survived together, accepting and appreciating each other's strengths and weaknesses, because that was the only way that could work. It became apparent, right from Vancouver, that a major rewrite of the Report was necessary if it was to be made more accessible to the uninitiated reader. From time to time we were shocked and surprised by some outrageous consequence of the original definition, and each time, rather than patching it up, we stood back, identified why the misunderstanding had arisen, and modified the method of description so that it was no longer possible to express problems of that class. (Examples are the removal of extensions (2.5.4.1) and of infinite modes (2.5.1.4).) We treated the Report as a ALGOL 68 SESSION
6"1
C. H. LINDSEY
large programming project, and consciously applied the principles of structured programming and good system desilgn. The syntax and semantics are now written so that it is generally easy to check that all possible cases have been accounted for, and wherever there was any doubt about this we generated a proof of the doubtful property, even incorporating the proof in the pragmatics [RR 7.3.1 ]. That we succeeded in our aims is evidenced by the fact that, disregarding the transput section (which is another story), the total number of bugs now known in [RR] can be counted on the fingers of one hand (2.6.2.1). During Augus~t of 1972 I had met Koster in Manchester, where we worked over the transput. However, there was no obvious person available actually to do the work. Transput, as usual, was receiving less attention than it should. Eventually, in February 1973, Richard Fisker, a student at Manchester, came to me looking for a project for his Masters thesis. He embarked upon it and had a small sample to show at Dresden, but the work was barely complete by the deadline in Los Angeles. We circulated a draft two months before the next WG meeting in Dresden (April 1973), and I wrote an explanation of how the descriptive method had changed. This time there were no significant calls for abandonment, and many people gave their opinion that the new document was clearer to read, especially Sintzoff's semantics. A few further improvements were discussed and voted on. 2.4.3.4
Edmonton (July 1973)
We had obtained funding from the NATO Science Committee that enabled the Editors to meet in Edmonton. Lambert Meertens, who had been playing an increasingly active role in monitoring the progress of the revision, was sent by Van Wijngaarden as his representatixre; Fisker was also present, and thus we had now reached our final complement of eight editors. The texts of the various parts were now merged into one document, and a hectic three weeks ensued. As before, we discussed, argued, and compromised, but always retaining our mutual respect. The technique used if one of us thought his opinion was being shouted down was to say to the others, "Eat?" (these arguments often took place at mealtimes); by established convention the others then kept silent while the point was made; the paradigm is specified formally in [RR 3.3]. Finally, we produced a text for circulation to the WG in advance of the next meeting that was complete except for the pragmatic:~ in the transput section (and much of these were included in a further edition provided at the meeting itself). The Los Angeles meeting (September 1973) considered the Report, proposed some minor changes, and authorized its submission to TC2 subject only to "editorial polishing and explanatory material which make no additional substantive changes." The Editors were instructed to make it available to the subscribers of the ALGOL Bulletin and to submit it for publication in appropriate journals. WG 2.1 also established a standing subcommittee on ALGOL 68 Support (convened by Robert Uzgalis, and then by Van der Meulen from 1978) "to act as a point of contact with users and implementors of the language, and to serve their needs by preparing complementary specifications and enhancements." 2.4.4
T h e Aftermath
The Editors met once again in Manchester to discuss the polishing, and Fisker and I continued to tidy up the transput and complete the missing pragmatics. Since the typesetting disc still had not arrived, the Report was eventually issued to the ALGOL Bulletin readership reproduced from a lineprinter listing [TR 74-3].
62
CHAPTER II
PAPER: A HISTORY OF ALGOL 68 2.4.4.1
Cambridge(April 1974)
The newly formed Support subcommittee held its first meeting in Cambridge. A close study of the transput section, mainly in Amsterdam, had revealed a number of bugs and inconsistencies, and these formed the main topic of discussion. Now this meeting was, in my experience, the first time that any group of people sufficiently concerned with transput and competent to discuss it had ever assembled in one place, and the result was a very thorough review leading to a considerable cleanup (2.3.9). Whether we were entitled to make such changes as were shortly to be published in AB 37 as errata to [TR 74-3] is a legal nicety, but we certainly did, and the language is all the better for it. For a report of this meeting see [King 1974]. 2.4.4.2
Typesetting
The WG met in Breukelen in August 1974, but our special typesetting disc still had not been delivered. A further set of errata to [TR 74-3] appeared in AB 38. The disc finally appeared early in 1975, so that at the Munich meeting of WG 2.1 (August 1975) the Editors spent all of their free time reading through the galleys, spotting all the things that were not quite fight. [Van Wijngaarden 1975] just made it by the year's end, and a final set of errata in AB 39 brought [TR 74-3] into line. 2.4.5
Postscript
What have we learned about designing programming languages? First, a small group of people (four or five) must do the actual work, and geographical separation (as between Amsterdam/Brussels in [R] or Manchester/Edmonton/Vancouver in [RR]) is a great encouragement to careful work. (The advent of e-mail may undo this in the future.) The editors need to have very tidy and pernickety minds (which does not necessarily qualify them as good designers of language features); moreover, constructing the formal definition at the same time as the language is being designed is a sure way to avoid obscure corners--a simultaneous prototype implementation would be even better. A large committee is a good place for brainstorming to get initial ideas, but it must recognize its limitations, the most important of which is that it is incapable of attending to detail. A large committee is also necessary to give democratic approval to the work of the editors. (In spite of the fact that this arrangement was observed to be unstable, I still do not know how to dampen it.) Moreover, the large committee will often take decisions which the editors know to be technically flawed--but that is in the nature of democracy. Finally, there is much to be said for doing the whole job twice, but in any event it always takes twice as long as you think (even when you think you have allowed for this factor). Any attempt to rush it is doomed to failure (although it must be admitted that our revision did, bar a few items, meet its deadline--but it was hard work). My opinion is that in this Revision we did get it just about right, and what I have observed of other language design efforts since that time only serves to confirm this view. 2.5
THE METHOD OF DESCRIPTION
The word "on the street" is that ALGOL 68 is defined by an "unreadable" document. Certainly [MR 93], when it first came out, was a tough nut to crack (I should know!), but [R] was already a big improvement and we tried strenuously to attack this problem for [RR]. But unfortunately, much of the mud slung at [MR 93] is probably still sticking. ALGOL 68 SESSION
63
c. H. LINDSEY
The language is defined by its Report in four parts: the Syntax, the Semantic Model, the Semantics proper, and the Standard-prelude. These will now be examined in turn. 2.5.1 2.5.1.1
Syntax
W-Grammars
The notation now known as a W-Grammar seems to be the main stumbling block to people approaching the Report for the first time. When this completely new notation first appeared, its readers had no previous model on which to build. Today there are several similar notations (for example, Attribute Grammars and Prolog) with which people are familiar. So a good way to explain it to a modern audience :is to start from Prolog. This will also help to illuminate both the power and the limitations of W-t3rammars. That a W-Grammar can be explained in terms of Prolog is not surprising when it is realized that Prolog actually stems from some attempts at natural language processing by Colmerauer. His first system [Chastellier 1969] actually used W-Grammars. This developed into the more structured Q-Systems, and finally into Prolog [Colmerauer 1996]. Here is a rule written in Prolog:
assignation( reJ~M OD E ) ) :desti[nation( ref(M O D E ) ), becomessymbol, source(MODE). This is Prolog, so MODE is a variable (it begins with an upper case letter) and refis a functor (with no inherent meaning). The meaning is that we have a goal "do we see an assignation here?", and to answer this we must test the subgoals "do we see a destination here?", followed by "do we see a becomes_symbol here?", etc. (I have cheated slightly by regarding the source text as an implicit variable). Prolog will keep backtracking if it fails, and if it gets into a loop, one just says, "Ah! but that was just the procedural meaning--the declarative meaning clearly expressed the right intention." The nice thing abeut Proiog is that the values of variables such as MODE may be deduced from the subgoals or imposed with the question; and again, from the declarative point of view, the distinction does not matter--the value of the variable just has to be consistent throughout. Here now is the corresponding rule in a W-Grammar [R 8.3.1.1 .a]. reference to MODE assignation : reference to MODE destination, becomes symbol, MODE source. The difference is that in Prolog the parameters of goals are well-formed expressions built out of functors, atoms and variables, whereas in a W-Grammar they are just free strings of characters, or 'protonotions', and the variables, or 'metanotions', stand for other strings of characters as produced by a context-free 'metagrammar'. Some possible 'metaproductions' of the metanotion ' M O D E ' are 'real', 'integra]l', 'reference to integral', 'row of reference to integral' and so on. So if you substitute 'integral' for ' M O D E ' you get reference to integral assignation : reference to integral destination, becomes symbol, integral source. (observe the consistent substitution for ' M O D E ' throughout), which will eventually produce familiar things like i := 99. But observe how we have insisted that the type (or mode) of the destination i must
64
CHAPTER II
PAPER: A HISTORY OF ALGOL 68
be refint because the type of the source 99 is int (or 99 must be int because i is refint--you can argue both ways round, just as in Prolog). The unstructured and potentially ambiguous strings of characters that form the rules of a W-Grammar give it great power; indeed, Sintzoff [1967] shows that it can produce any recursively enumerable set, and hence is equivalent to a Chomsky Type-0 Grammar. One can say things that simply cannot be expressed using the well-formed expressions of Prolog. The Bad News is that it is quite impossible to write a parser based on unrestricted W-Grammars. If you want to do that, you must introduce some more structure, as in Prolog, or as in the Affix Grammars described in Koster 1971. Here is an example that cannot be written in Prolog (although it was possible in Q-Systems). First, some metagrammar: M O O D :: real ; integral ; boolean ; etc. L M O O D S E T Y :: M O O D and L M O O D S E T Y ; EMPTY. R M O O D S E T Y :: R M O O D S E T Y and M O O D ; EMPTY. Hence, in the rule [R 8.2.4.1 .b], one out of L M O O D S E T Y M O O D RMOODSETY mode F O R M : M O O D FORM; . . . . ' L M O O D S E T Y M O O D R M O O D S E T Y ' can metaproduce a sequence such as 'real and integral and boolean' in such varying ways that the ' M O O D ' can be chosen as any of the three (for example, choose 'real and integral' for ' L M O O D S E T Y ' , ' E M P T Y ' for ' R M O O D S E T Y ' , and thus 'boolean' for ' M O O D ' ) . Thus a W-Grammar is a much more powerful notation than Prolog; but this power must be used by report editors with the utmost discretion, if the result is to be intelligible. Here is another rule [R 8.3.0.1 .a]: M O D E confrontation : M O D E assignation ; MODE conformity relation ; M O D E identity relation ; MODE cast. With this you can try to produce a confrontation for any ' M O D E ' - - s o how about a real-confrontation? But the rule already given for 'assignation' will produce only a reference-to-MODEassignation. Likewise, the only rule for 'conformity relation' is for a boolean-conformity-relation. In fact, the only alternative on the right side of the rule that has productions for every possible ' M O D E ' is ' M O D E cast'. All the other attempts at a real-confrontation lead to 'blind alleys'. Duncan was much concerned about blind alleys, especially as to how the reader could recognize one without an exhaustive search through the whole syntax, and he was not satisfied by their indication by a ' - ' in the cross references. Nevertheless, blind alleys turn out to be a very powerful tool in the hands of the grammar writer. Blind alleys occur also in Prolog. In [RR] we made three major changes to the syntax, as will now be described. 2.5.1.2
Predicates
In the Revision we discovered new and helpful ways to use a W-Grammar. Consider the following: First the metagrammar
N O T I O N :: ALPHA ; NOTION ALPHA. A L P H A :: a;b;c;d;e;f;g;h;i;j;k;l;m;n;o;p;q;r;s;t;u;v;w;x;y;z. N O T E T Y :: NOTION ; EMPTY. ALGOL 68 SESSION
65
C. H. LINDSEY
and now the ordinary rules where true : EMPTY. where ( N O T E T Y ) is ( N O T E T Y ) : where true.
So if I ask for productions of 'where (abc) is (abc)' I will get the terminal production ' E M P T Y ' , but i f I ask for productions of 'where (abc) is (def)' I am forced into a blind alley, and I get no terminal production at all. There is also a rule of the form unless ( N O T E T Y 1 ) is (NOTETY2) : . . . which produces ' E M P T Y ' if ' N O T E T Y I ' and ' N O T E T Y 2 ' are different, and a blind alley if they are the same. This is quite a bit harder to write than the ' w h e r e ' case; for the full story see [RR 1.3.1 ]. Rules that can produce only ' E M P T Y ' or a blind alley are known as 'predicates', and their use greatly simplifies the number and complexity of rules required in the Report. Here is an example of their use [RR 6.1. l.a]. The intention is to forbid deproceduring for a certain subclass of F O R M s . strong M O l D F O R M coercee :
where ( F O R M ) is (MORF), S T R O N G M O I D M O R F ; where ( F O R M ) is ( C O M O R F ) , S T R O N G M O I D C O M O R F , unless ( S T R O N G M O I D ) is (deprocedured to void). 2.5.1.3
Context Conditions vs NESTs
In [R] a whole chapter is devoted to 'context conditions', which seek to ensure, for example, that each
applied occurrence of an identifier 'identifies' its correct defining occurrence. In other languages these conditions are often referred to as 'static semantics'. So in [R 4.1.2.a], for example, there is a fairly straightforward set of Steps for starting at an applied occurrence and searching in ever wider blocks for its defining occurrence. But this is deceptively straightforward; people will quote it at you to show you how simple it all is. What they do not show you is the corresponding rule [R 4.3.2.b] for identifying operators, with this alternative form for the Step 3 of [R 4. 1.2.a]. Step 3: If the horae contains an operator-defining occurrence O {, in an operation-declaration (7.5. l.a,b), } of a terminal 13roduction T of'PRAM ADIC operator' which is the same terminal production of 'ADIC indication' ~ts the given occurrence, and which {, the identification of all descendent identifiers, indications and operators of the operand(s) of F having been made, } is such that some formula exists which is the .,tame sequence of symbols as F, whose operator is an occurrence of T and which is such that the original of each descendent identifier, indication and operator of its operand(s) is the same notion as the original of the corresponding identifier, indication and operator contained in F {, which, if the pregr~lm is a proper program, is uniquely determined by virtue of 4.4.I.a}, then the given occurrence identifies O; otherwise, Step 2 is taken. Every word of that (except for the pragmatic remarks between {...}) is essential for its correct interpretation. I know that it is correct because I have, in my time, studied it carefully, and I have seen all the half dozen incorrect versions that preceded it. But how can one have confidence with mechanisms requiring such turgidity? In the Revision, therefore, we removed all the context conditions and brought the whole identification process int,~ the syntax. The tools required to do this are still complex, but once one has understood them they hardly intrude. And their formality ensures that it is always possible to work through any particular case and to see whether and why it is or is not allowed.
66
CHAPTER II
PAPER:A HISTORYOF ALGOL 68 Briefly [RR 1.2.3], there is a metanotion ' N E S T ' that metaproduces a sequence of ' L A Y E R ' s (each corresponding to a block). Each ' L A Y E R ' metaproduces a sequence of ' D E C ' s (each corresponding to a declaration in the program). The ' N E S T ' of each block contains one more ' L A Y E R ' than its parent block, and the syntax of declarations enforces that the ' D E C ' s of that extra ' L A Y E R ' correspond to the things declared, and moreover that they are 'independent' of each other (for example, that the same identifier is not declared twice) [RR 7.1.1]. Each syntax rule CalTies a ' N E S T ' , so that the new rule for assignation [RR 5.2.1.1 .a] is REF to M O D E NEST assignation : REF to MODE NEST destination, becomes token, M O D E NEST source. Now, if the source is, or contains, an applied-identifier, the syntax fishes its ' D E C ' out of the 'NEST' [RR 7.2.1] (it is required to be there) and checks its ' M O D E ' . Of course, all of this machinery makes heavy use of predicates. 2.5.1.4
Infinite Modes
Consider the following: mode language = struct ( int age, ref language father);
Ioc language algol; In [R] the mode of algol is 'reference to [language]', where '[language]' stands for 'structured with integral field [age] and reference to [language] field [father]'. In other words, the string of characters describing this mode is infinite. Why did this need to be so? Consider:
algol : = father of algol. If the mode of algol had been represented finitely, by some such notation as 'reference to structured with integral field [age] and reference to languagefield [father]', then the mode of father of algol (after coercion) would be "language'. Substituting these in the right side of the syntax rule for 'assignation' gives reference to structured with integral field [age] and reference to language field [father] destination, becomes symbol, language source. And this is not allowed, since the ' M O D E ' in the rule has not been substituted consistently. With an infinite string the substitution is consistent, provided only that you believe that, if X °* stands for . . . XXXX, then X 0. X is no different from X °*. Infinite modes caused much discussion at Tirrenia and after. The strange thing is that the fuss had not started earlier, as infinite modes had been present since [MR 88]. Maybe the one obscure pragmatic remark in [MR 88] had been overlooked, whereas a second more obvious remark in [MR 93] had invited attention. Duncan was particularly concerned (he claimed he could not read the Report beyond a certain point because he was still unfolding some infinite production). The question asked was "how could an infinite sequence be written on a finite piece of paper?", to which Van Wijngaarden's famous reply was that you wrote the first character on the first half of the sheet, the second character on half of the remaining part of the sheet, the third on half of what remained after that, and so on. More seriously, he claimed that (from the viewpoint of a constructivist mathematician) it was the mechanism that produced the infinite sequences that was important, not the sequences themselves. However, [R] did
ALGOL 68 SESSION
67
C. H. LINDSEY
not discuss these mathematical niceties, and it was not at all clear that the procedure was mathematically sound. Meertens [1969] (quoting a letter from Tseytin) and Pair [ 1970] were the first to suggest that there might be flaws, but these doubts were expressed so vaguely, or so abstractly, that they went unnoticed. It was not until Boom [1972] exhibited an actual ambiguity that we were forced to take note. Here is Boom's example: m o d e n = struct(ref n a, c); m o d e hendrik = struc~ref struc~ref n a, b, c) c); # I field # m o d e b o o m = struc~ref n b, c); # 2fields #
Now if you write out (in imagination) the full modes for hendrik and boom, you will find that they cannot be distinguished under any reasonable understanding of infinity, certainly not one that regards X °*X as equivalent to X °*, yet their modes are clearly supposed to be different. For [RR], therefore, we resolved that any program should be producible in only a finite number of moves. The mode of algol is now 'reference to mui definition of structured with integral field [age] reference to mui application field [father] mode' (read 'toni' as a kind of label). However, there are many otber ways of 'spelling' that same mode, just by expanding the 'mui application' a few more times, but all these spellings are equivalent (in fact, a mode is now an equivalence class). The equivalence is defined by means of a predicate [RR 7.3.1] that systematically compares two (possibly infinite) trees, essentially following the algorithm of [Koster 1969]. Writing the syntax for this predicate was hard work. We all had a go at it, first to get a version that worked, and then to get a version tidy enough to present. It is, admittedly, also hard work to read (in spite of copious pragmatics), but the Report is written so that it does not obtrude, and the naive reader need hardly be aware of it. 2.5.2
The Semantic Model
Any definition of ~Lprogramming language needs to define very carefully the "domain of discourse," or model, in terms of which everything is to be explained. Even today, many language definitions do not do this (they suppose that the reader can infer the meaning "obviously" intended), or they scatter this important information throughout the text. But McCarthy had explained this need to the WG as early as 1963, leading to its adoption by the Vienna school [Lucas 1969]. Following an explicit request from the Subcommittee at Kootwijk, [R2] was therefore devoted to describing the rules of the 'hypothetical computer'. This particular hypothetical computer is well removed from "reality," giving little comfort to the man who wants to relate it to concepts with which he is already familiar (variables, addresses, and the like). Essentially, it is a graph of 'objects' (including 'external' constructs as produced by the syntax, and 'internal' values). Objects may have attributes (for example, values have types and scopes). The arcs of the graph are 'relationships' (both static and dynamic) between objects (for example, 'to access', 'to refer to', 'to be newer than', and 'to be a subname of'). The terminology used is often arcane and different from common usage, as already pointed out in Section 2.1.3. For example, the attribute 'scope' would nowadays be termed 'extent'. (It will be noted that I have been using such present-day terminology throughout this paper.) The worst example was the term 'name'. Names are allowed 'to refer to' values, and from time to time (during assignations) they may be made t a refer to other values. If you read 'name' as 'variable', and 'to refer' as 'to contain', then you might suddenly begin to understand things a whole lot better. And you must not confuse
68
CHAPTER II
PAPER:A HISTORYOF ALGOL 68
(internal) names with (external) identifiers, although the latter may, in appropriate circumstances, 'access' the former. The 'actions' available to the hypothetical computer are the creation of new objects and the changing of dynamic relationships. The semantics for the various constructs of the language prescribe the actions that comprise their 'elaboration'. One of the actions provided by the original Report was to take a copy of some construct, to replace some of its identifiers systematically by other identifiers, and then to elaborate it. This technique was in the tradition of the semantics of A L G O L 60, although other language definitions, such as [Lucas 1969], had already abandoned it. If carefully applied, it does give the expected and well-known semantics of block-structured languages, but its operation is counter intuitive as regards the way programmers normally think of a running program, and it is exceedingly difficult to ensure that it has indeed been "carefully applied" throughout. Having been caught out several times, therefore, we abandoned this concept and introduced a system of 'environs' and 'locales'. An 'environ' comprises a 'locale' (which models the objects accessible locally within some block) together with an older environ (whose locales model objects that were declared outside of that block). Every elaboration is deemed to take place within some identifiable environ, and the chain of locales comprising that environ corresponds to the 'dynamic stack' familiar to implementors. (A separate chain of locales is defined for the 'static stack'.) 2.5.3
T h e Semantics
The semantics of A L G O L 68 is an operational semantics. In [R] the semantics were described in sequences of Steps, with frequent jumps to other Steps (a program full of gotos, in effect). Also, there was some very turgid phraseology that we were able to remove by defining terminology in the semantic model more carefully. In [RR], Sintzoff set out to adhere to the principles of structured programming, with 'If's, 'Case's, and nice indentation. The new semantics is therefore much shorter (only 12 pages total, which for 12 months work might not seem much). Here is the semantics of assigning a value to a name in both the old and the new styles. First, from [R 8.3.1.2.c]: An instance of a value is assigned to a name in the following steps: Step 1: If the given value does not refer to a component of a multiple value having one or more states equal to 0 {2.2.3.3.b}, if the scope of the given name is not larger than the scope of the given value {2.2.4.2} and if the given name is not nil, then Step 2 is taken; otherwise, the further elaboration is undefined; Step 2: The instance of the value referred to by the given name is considered; if the mode of the given name begins with 'reference to structured with' or with 'reference to row of', then Step 3 is taken; otherwise, the considered instance is superseded {a} by a copy of the given instance and the assignment has been accomplished; Step 3: If the considered value is a structured value, then Step 5 is taken; otherwise, applying the notation of 2.2.3.3.b to its descriptor, if for some I, I=1. . . . . n, si=l (11=1)and Ii (Ul) is not equal to the corresponding bound in the descriptor of the given value, then the further elaboration is undefined; Step 4: If some $1=0 or tl=O, then, first, a new instance of a multiple value M is created whose descriptor is a copy of the descriptor of the given value modified by setting its states to the corresponding states in the descriptor of the considered value, and whose elements are copies of elements, if any, of the considered value, and, otherwise, are new instances of values whose mode is, or a mode from which is united, the
ALGOL 68 SESSION
69
C. H. LINDSEY
mode obtained by deleting all initial 'row of's from the mode of the considered value; next M is made to be referred to by the given name and is considered instead; Step 5: Each field (element, if any,) of the given value is assigned {in an order which is left undefined} to the name referring to the corresponding field (element, if any,) of the considered value and the assignment has been accomplished. And now from [RR 5.2.1.2.b]: A value W is "assigned to" a name N, whose mode is some ' R E F to MODE', as follows: It is required that •
N be not nil, and that
• " W be not r~ewer in scope than N; Case A: ' M O D E ' is some 'structured with FIELDS mode': •
For each "rAG' selecting a field in W,
•
that field is assigned to the subname selected by 'TAG' in N;
Case B: ' M O D E ' is some 'ROWS of M O D E l ' : •
let V be the {old} value referred to by N;
•
it is requin~ that the descriptors of W and V be identical;
•
For each index I selecting an element in W,
•
that element is assigned to the subname selected by I in N;
Case C: ' M O D E ' is some 'flexible ROWS of M O D E l ' : •
let V be the {old} value referred to by N;
•
N is made to refer to a multiple value composed of (i) the descriptor of W, (ii) variants {4.4.2.c} of some element {possibly a ghost element} of V;
•
N is endowed with subnames {2.1.3.4.g};
•
For each index I selecting an element in W,
•
that element is assigned to the subname selected by I in N;
Other Cases {e.g., where ' M O D E ' is some 'PLAIN' or some 'UNITED'}: •
N is made l:o refer {2.1.3.2.a} toW.
On the face of it that looks straightforward enough, but if you peer closely you will observe that no less than 20 apparently ordinary words are being used with a very precise meaning, as defined in the semantic model. Here they are: value; name; mode; is; require; nil; newer than; scope; select; field; subname; refer to; descriptor; index; element; make to refer to; multiple value; variant; ghost element; endow with subnames. Thus much o f the improved readability o f [RR] came from a careful choice of new technical terms and abbreviations--the art of choosing such abbreviations lay in making them "suggest" to the reader the same "obvious" meaning that he found when he actually looked them up. But the price paid was
70
CHAPTER II
PAPER:A HISTORYOF ALGOL 68
the piling of more and more concepts and definitions into the semantic model, their purpose and necessity not always being immediately apparent. It is probably fair to say that the model is too big. (It certainly occupied more space than the semantics proper.) Although the semantics is ostensibly written in English, it is in effect a formal notation ("syntaxdirected English," as Mailloux described it). It is therefore proper to ask why we did not, in the revision, go the whole way and make it entirely formal. This would clearly have been possible, but the growth of our understanding of the new semantics and its model did not happen overnight, but indeed occupied all the time available to us, so the possibility could not be considered seriously. Moreover, it would have, in my opinion, added nothing to the rigour achieved, and the formalization of the large semantic model itself would have been a major task, not necessarily resulting in a clearer product. 2.5.4
Standard-prelude
It is always tempting to define parts of a language in terms of other parts already defined, but there are dangers, as I shall explain. This was done in two places in [R], in the 'extensions' and in the standard-prelude, especially in the transput. 2.5.4.1
Extensions
Having defined a core language (which was actually about 90% of the total), [R 9] purported to define the rest by providing replacements for certain sequences of symbols. For example, according to [R 9.2.c] you could replace struct s = ( i n t a , b), struet t = ( r e a l x , y);
by
struct s = ( i n t a , b), t = ( r e a l x , y);
and you could replace [l:n]realal, [l:n]reala2;
by [i:n]realal, a2; .
Effectively, these extensions were defining both syntax and semantics at the same time. So it turned out that the first example also allowed you to produce, by extension, struet s = ( int a, b ), t = real; which is nonsense (this is a syntactic problem), and the second example mandates that, given [l:n]real al, a2; it is quite in order for the side effects of n to happen twice (this is a semantic problem). WG members had expressed doubts about the safety of this mechanism as far back as Zandvoort. We now found so many further shocks and surprises that our confidence in the mechanism entirely evaporated and we abandoned it, incorporating these features (where they were retained at all) into the main syntax. Extensions seemed like a good idea at the time, but they are only really appropriate for a language where the core really is small (say 30 percent), and even then some separate method of specifying the syntax should be used. 2.5.4.2
Transput
Defining the built-in operators in the standard-prelude by means of operation-declarations turned out to be quite satisfactory, but doing the same thing for the transput routines was a grave mistake. The underlying model of the transput system has already been described (2.3.9). To write this model and the procs using it in ALGOL 68 was a substantial programming task, running to 68 pages in [RR 10.3]. This was akin to writing an actual implementation, insofar as we had to add numerous ALGOL 68 SESSION
71
C. H. LINDSEY
declarations and so forth with which to 'implement' the model. But it still was not (and was not intended as) an implementation that you could run (you were simply meant to read it in order to see what requirements were being defined), and care was taken to leave many things undefined. The net result was that you could not see the forest (the model) for the trees (the details of its implementation), and it was difficult to show that it was free of bugs and inconsistencies (which it was not). Most of the problems we had in the maintenance phase (2.6.2.2) lay in sorting out the resultant mess. IfI were doing this job over again, I would certainly define the meaning of the transput procs in a more axiomatic style by providing the preconditions and postconditions on the state of the model that each was supposed to satisfy, for example. 2.5.5
Style
[R] was written in a very pedantic style. This was necessary because the more formal your document is seen to be, the more people will actually believe what you actually wrote, as opposed to what you intended. Van Wijngaarden's English followed a very set style, with punctilious punctuation (as may be seen from the ,examples already quoted). In the revision, we tried to adhere to the same high standards (I beliew~ I learned to write a good pastiche of Van Wijngaarden's style), and we often spent much time discus:ring what was and what was not correct English. For example, we had great arguments as to the proper form of the negative subjunctive ("It is required that the value be not nil") and I remember a full 15 minutes devoted to whether well-formedness should be hyphenated. The successive drafts of [R] gradually established the style. In [MR 76] the metanotions consisted of just one upper-case letter. (Hence there were just 26 of them.) There was no explanatory material and no examples, and that document really was unreadable (in addition to being buggy), so that I find it hard to imagine why WG 2.1 agreed to go with it. The meeting at Kootwijk agreed that the metanotions should be English words with suggestive meanings. By [MR 88] 'pragmatic remarks' (comments enclosed within {...}) had appeared and by [MR 101] had been elevated to an art form. The choice of words used for metanotions and nonterminais was initially too arbitrary. (One can recognize the overzealous use of Roget's Thesaurus in the sequence 'adapted', 'adjusted', 'fitted', 'peeled' which preceded the now familiar 'strong', 'firm', 'weak', 'soft'.) It took much pressure from the WG, in Zandvoort and Tirrenia, to persuade Van Wijngaarden to include more motivations, more cross references, different fonts for syntactic objects, and so on. In the revision, we tried to take this policy even further. The additions to the syntactic tools enabled us to use fewer nonterminals, and we systematically introduced each section with pragmatics that set out the goods to be described (indeed, you can almost discover the language from the pragmatics alone). If a reader approaches some piece of mathematical formalism with the wrong preconceived idea of what is to be presented, he can waste hours before his internal model becomes corrected. I therefore regard the principle purpose of pragmatics to be to "preload" the reader with the appropriate model. This of course introduces redundancy into the document, but this is no bad thing (as seems to have been accepted when this came up at Tirrenia), for if the formal and pragmatic descriptions are found, after close scrutiny, to disagree, this may well alert the reader to the presence of a bug in the formalism; better to recognize this (and to seek clarification from the proper authorities) than to implement the bug. I therefore offer the following guidelines, based on our experience. • Pragmatic remarks should be copious, but well delineated from the formal text. Their purpose is to educate the reader (in the sense of the Latin educare).
72
CHAPTER II
PAPER: A HISTORY OF ALGOL 68
• Motivation should be given for why things are as they are. Redundancy is no bad thing, except within the strictly formal parts. • Syntax should be fully cross referenced, both forwards and backwards; semantics likewise. • Each syntax rule should be accompanied by examples. • There should be copious glossaries, indices, and summaries. • The Report should not take itself too seriously. With the best will in the world, it is not going to be perfect. Our Report contains some good jokes, many quotations from Shakespeare, Lewis Carroll, A. A. Milne and others, and even a picture of Eeyore. The various translations of it have been made in the same spirit. • Above all, the Report should be fun to write. Unfortunately, Standards Bodies and Government Departments do not always encourage these practices in their guidelines. I invite the reader to consider the extent to which they have been followed, or otherwise, in more recent programming language definitions, together with the perceived success of those definitions. On that basis, I will rest my case.
2.6
THE MAINTENANCE PHASE
After 1974, WG 2.1 proceeded to other things and left most ALGOL 68 activity to its Support Subcommittee. This considered enhancements to the language, together with the various bugs and problems that were reported. It met whenever there was a meeting of the full WG, but its main activities took place in independent meetings, as listed in Table 2.5. TABLE
2.5
Meetings of the Support Subcommittee. Date
Meeting place
Meeting
Topics discussed
Apr 1974 Aug 1974
Cambridge
SC
Transput (2.4.4. I); Sublanguagc.
Breukelen
WG, SC
Jan 1975
Boston
SC
Modules; Standard Hardware Representation; Sublanguage; Partial Parametfization.
Aug 1975
Munich
SC, WG
TUM-10 mechanism; acceptance of Sublanguage, Standard Hardware Representation, and Partial Parametrization.
Sep 1976
St. Pierre de Chartreuse
WG, SC
Sublanguage still being polished.
Aug 1977
Kingston
SC
Modules; Bugs and problems; TP task force formed.
Dec 1977
Oxford
TP, SC, WG
Implementation Model; Transput problems; 1st Commentaries released.
Aug 1978
Amsterdam
TP
Transput problems; Implementation Model.
Aug 1978
Jablonna
WG, SC
Acceptance of Modules and TORRIX; 2rid Commentaries released.
Dec 1978
Cambridge
TP
Transput problems; Implementation model.
Apr 1979
Summit
TP, SC, WG
Acceptance of Test Set and Implementation Model; 3rd Commentaries released.
WG = full Working Group; SC = Support Subcommittee; TP = Transput task force.
ALGOL 68 SESSION
73
C. H. LINDSEY 2.6.1
2.6.1.1
Enhancements
The Sublanguage
Although a Subeemmittec on Sublanguagcs had been formed at Manchester, it never produced anything concrete, and it was an independent effort by Peter Hibbard, implementing on a minicomputer with only 16K words at Liverpool, which eventually bore fruit. Hibbard's sublanguage, first introduced to the WG at Vienna, was intended for mainly numerical applications, and the features omitted from it were intended to simplify compilation. It was discussed by the WG and the Support Subcommittee on several occasions, and finally formulated as an addendum to the Report and released for publication as =m IFIP Document at Munich. However, the final polishing lasted for some time until it eventually appeared as [Hibbard 1977]. A more informal description will be found in Appendix 4 of [Lindsey 1977]. 2.6.1.2
The Standard Hardware Representation
ALGOL 68 was conceived in the days when every computer had its own character code. Even with the advent of ASC[! things were not entirely settled, since many printers still did not support lower case letters. The conclusion reached, and sold to the Support Subcommittee by Wilfred Hanscn and Hcndrik Boom, was that one could easily transliterate between two character sets, provided that implementations restricted themselves to a set of 60 'worthy characters', each representable by a single character in each set. This still left the problem of 'stropping' (2.1.3) and the solution adopted was for POINT stropping, which would always be enabled (as in .REAL X) with a choice of UPPER stropping (as in REAL x) or REServed stropping (as in REAL X) under control of a pragmat. The document formalizing this [Hanscn 1977] was also released for publication as an ]FIP Document at Munich. For an informal treatment, see Appendix 5 of [Lindsey 1977]. 2.6.1.3
TUM-10
The hassle of getting a document approved through the IFIP hierarchy was considered too great for every small enhancement to the language, and a simpler mechanism was agreed on at Munich. The Support Subcommiittee was to scrutinize proposals to ensure that they were consistent, upwards-compatible, and useful, and release them "to encourage implementors experimenting with features similar to those described ... to use the formulation here given, so as to avoid proliferation of dialects," and the full WG would then authorize publication in the ALGOL Bulletin with this wording. This principle was enshrined in a document numbered TUM-10 [WG 2.1 1975]. 2.6.1.4
Partial Parametrization
After the failure of' the Bckic proposal to relax the extent restriction on procs (2.3.5), it was agreed that this problem ought to be solved by partial paramctrization. At Boston the Support Subcommittee appointed a task force (Bckic, Foster, Hibbard, Mccrtcns, and myself) which brought forward a proposal to incorporate this [Lindsey 1976], and it was adopted under the newly invented TUIVl-l0 mechanism at Munich. Here is an example:
proc compose =: (proc(real)realf g, real x) real: fig(x)); proo(reaOreal ~qex = compose(sqrt, exp, );
74
CHAPTER II
PAPER: A HISTORY OF ALGOL 68 2.6.1.5
Modules and Separate Compilation
"['he basic idea for program encapsulation using modules was first presented (so far as ! am aware) by Steve Schuman at the Fontainebleau meeting of WG 2.1 (see [Schuman 1974] for a fuller account). The inclusion of such a facility within ALGOL 68 was discussed by the Support Subcommittee on various occasions, and finally agreed under the TUM- 10 mechanism at Jablonna [Lindsey 1978]. The people involved at various times, in addition to myself and Hendrik Boom who wrote the final document, included Steve Bourne, Robert Dewar, Mike Guy, John Peck, and Steve Schuman. Here is an example: module stack = def int stacksize = 100;
Ioc [ l :stacksize ] int st, Ioc int stptr := O; pub proc push = ( int n)int: ((stptr+ := 1)O l st[(stptr-:= !)+ I ] l print("stack underflow''); stop); postlude
(stptr/=O I print("stack not emptied"); stop) fed; ..o
access stack (push(l); push(2); print(pop); pop)
There was provision for separate compilation of modules at the global level, but there was also a second mechanism for separately compiling an egg in an environment known as a nest, which could be declared at any level within a program. It is interesting to note that Ada also has two separate compilation mechanisms, of a similar sort. 2.6.1.6
TORRIX
TORRIX was an ALGOL 68 library for handling vectors and matrices, developed at the University of Utrecht [van der Meulen 1978]. At its Jablonna meeting WG 2.1 commended its use, using a variation of the TUM-10 wording. 2.6.1.7
The MC Test Set
This was a suite of 190 ALGOL 68 programs, developed at the Mathematisch Centrum [Grune 1979], and designed to establish confidence that an ALGOL 68 compiler was correct with respect to the Report. It therefore contained many "pathological" examples as well as some more straightforward programs. The Summit meeting of WG 2.1 authorized a statement of commendation to be attached to it. 2.6.2
Problems
It was not long before people began to report problems with [RR]. The policy for dealing with them was hammered out by the Support Subcommittee at Kingston and Oxford, the principles being that • Clerical errors and misprints in [RR] could be corrected by publication of errata. • [RR] would not be changed in any substantive fashion.
ALGOL 68 SESSION
75
C. H. LINDSEY
Commentaries would be published stating the opinion of the Support Subcommittee on problems that had been raised, but they were "not to be construed as modifications to the text of the Revised Report." Their definitive forms can be found in [WG 2.1 1978] and [WG 2.1 1979]. 2.6.2.1
Langua,ge Problems
Only three of the commentaries refer to the main body of the Report, that is, to the syntax and the semantics, and one of these is arguably discussing a non-problem. There are also a couple of problems with [RR 10.2] (the non-transput part of the standard-prelude). Allowing a margin for these uncertainties and for some problems that might be counted as two, it is still safe to say that the number of known problems in the main part of the Report can be counted on the fingers of one hand. 2.6.2.2
Transput Problems
Unfortunately, the same cannot be said for [RR 10.3], the transput part of the standard-prelude. A continuous stream of problems was reported, notably by Hans van Vliet who had been trying to construct a machine-independent implementation model of the transput. At Kingston a task force, convened by Chris Cheney, was set up with a brief to review [RR 10.3] and to provide a reasonable interpretation for it. Over a succession of meetings the task force decided to adopt Van Vliet's implementation model, adjusting both it and the Report to ensure that they were consistent (of course, proving the equivalence of two programs is not easy, but a very intensive study of [RR 10.3] had now been taking place, resulting in some confidence that we at last understood it, warts and all). Commentaries were prepared to establish the "approved" understanding of the Report, and the final version of Van Vliet's model [Van Vliet 1979] was released with a TUM-10-1ike wording. 2.7
IMPLEMENTATIONS
Shortly after publication of the ALGOL 60 Report there were implementations on a large variety of machines, written in universities and research establishments and by machine manufacturers. There was a natural expectation that the same thing would happen with ALGOL 68 and, for example, it was reported at Novosibirsk that 20 implementations were underway on 15 different machines. The sad fact is that the great majority of implementations that were started were never completed. 2.7.1
The Early Implementations
The implementations by Goos at Munich on a Telefunken TR4, and by Branquart at M B L E on an Electrologica-X8 ,were well under way by the appearance of [R]. Moreover, Mailloux had had a
particular responsibility among the authors for ensuring that the language, as it was being defined, was implementable. In his thesis, Mailloux [1968] considered examples such as the following: begin real x; p r o c p = void: beg,rn proc q = begin somelongexpression + x; ... end;
abc x; . . ,
end; 76
CHAPTER II
PAPER: A HISTORY OF ALGOL 68 #either# #or#
m o d e ab¢ . . . . ; op ab¢ . . . . ;
When a b e x is encountered, we do not yet know whether it declares a new variable x of an as-yet-undeclared mode abe, or whether it is an application of an as-yet-undeclared operator ab¢ to the previously declared x. So a first pass of the compiler is needed to detect all declarations of modes and ops before it can be known what identifiers have been declared. But now, supposing the first pass shows a b e to be a mode, we cannot tell on the second pass whether the x within pra¢ q is of mode real or of mode abe. Therefore, we cannot tell which overloaded version of the operator + is meant in p r o e q until the third pass, by which time it is too late to compile code to coerce somelongexpression. Hence a fourth pass is required to generate the code. Thus Maiiloux established the classical 4-pass ALGOL 68 compiler, and they all said how clever he was and gave him his degree. What they ought to have said was how clever he was to have discovered a flaw in the language that could easily be fixed by a small syntactic change, such as a compulsory Ioe in front of each variable-declaration (2.3.4.5), thus saving an entire pass in every compiler. But compile-time efficiency was not regarded as important although run-time efficiency was always a prime goal. As Van Wijngaarden said at North Berwick, " . . . yes, it does some extra work for the compiler but we should not be concerned with the efficiency of compiling. You do not lose any run-time efficiency, and that is what we are most concerned with." Strangely, Goos, who was well into writing his compiler at that time, seemed quite content with this philosophy. Goos' compiler in fact had six passes. Branquart's compiler was a piece of research into compiler methodology rather than a serious production tool, but it did establish many features necessary to all compilers, particularly the storage of values and the layout of the stack, all documented in a series of MBLE Reports that were finally collated into [Branquart 1976]. The project consumed 20 man-years of effort, spread over the years 1967 to 1973. Being implementations of the original language, neither of these compilers ever came into use outside their home bases. The Malvern ALGOL 68R compiler, on the other hand, restricted the language so as to permit l-pass compilation and also made numerous small language changes, for convenience of implementation. Some, but not all, of these changes were subsequently blessed by inclusion within [RR]. Thus JR], [RR], and ALGOL 68R could be regarded as three vertices of an equilateral triangle. It was available from 1970 onwards on ICL 1900 series machines, and became the most widely used implementation, especially in Great Britain. A TC2-sponsored conference on ALGOL 68 implementation was held in Munich in July 1970, ~nd the proceedings [Peck 1971 ] contain papers on all the three compilers mentioned, together with several papers discussing garbage collection, showing this problem not to be as intractable as had been feared. 2.7.2
Implementations of the Revised Language
A full list of compilers available at the time can be found in [AB 52.3.1]. ]t is now apparent that implementing full ALGOL 68 requires an effort beyond what a university department can usually provide, which is why so many attempts failed. But by making some quite modest restrictions to the language the effort is reduced quite significantly, as Malvern showed, and such restrictions or omissions hardly affect the functionality or the orthogonality of the language. We therefore need to distinguish between full commercial implementations and small partial ones.
ALGOL 68 SESSION
77
C. H. LINDSEY 2.7.2.1
FullImplementations
The most successful commercial implementation was by CDC Netherlands, first delivered in 1977 in response to a threat from several Dutch universities to buy only machines with ALGOL 68 available. It was an excellent compiler, but the parent company in the USA never showed any interest in it. Next, Malvern produced their second attempt, ALGOL 68RS, for their own in-house machines and available from 1977. This was much closer to [RR] than their first product, it was written to be machine independent, and it has been ported to the ICL 2900 series, to MULTICS and to VMS Vaxen. It is still the best slLarting point, should anyone wish a new (almost) full implementation. The final commercial-strength product, called FLACC and first shipped in 1978, was a checkout compiler for IBM machines. This was produced by two of Mailloux's ex-students who set up their own company. Again, this was an excellent product (not fast, being a checkout system), but it did not spread far because they completely misjudged the price the market would pay. 2.7.2.2
PartialImplementations
Hibbard's Liverpool implementation, around which his sublanguage (2.6.1.1) was designed, was rewritten in BLISS for a PDP-11 when he moved to Carnegie Mellon, and was rewritten again by myself in Pascal and now runs on various machines. On the way, it acquired heap-generators (not in the original sublanguage), giving it nearly the functionality of the full language. ALGOL 68C was a portable implementation originated by Steve Bourne and Mike Guy at Cambridge in 197:5, and now available on IBM machines, DEC-20s (anyone still have one?), VMS Vaxen, Primes, Telefunken TR440, and even a CYBER 205. Its development continued for a while, but it was never completed (for example, it still has no garbage collector, although one was "almost working" at one stage). It was quite widely used, especially on IBM machines where it is much faster than FLACC. ALGOL 68LGU is a system for IBM 360 clones, written by Tseytin and his colleagues at Leningrad State University (as it then was). As with other university products, it lacked features such as garbage collection, but it has now been adopted by Krasnaya Zarya, a "commercial" company in Leningrad, which has produced various products around it, including cross compilers and a portable version. Indeed, the former Soviet Union is the only place where there exists an official Standard for ALGOL 68 [GOST 27974/9-88]. Finally, an interactive implementation by Peter Craven of Algol Applications Ltd, originally developed for MS-DOS systems, is now available in the form of a public-domain interpreter, written inC. 2.8
2.8.1
CONCLUSION Whatever Happened to A L G O L 68?
Well, one could say that it is alive and well and living in Pascal, or C, or C++, or SML, or Ada; and indeed this is true in part for all of these languages (see 2.3. !, 2.3.4.3 and 2.3.6 for some specific mentions). The real questien is why it did not come into more widespread use, and the answer here is simple enough: because it was not implemented widely enough, or soon enough. And the reason for that is that implementation was too hard, and the reason for that was on account of a relatively small number
78
CHAPTER II
PAPER:A HISTORYOF ALGOL 68
of troublespots, not inherently necessary for the basic principles of the language and certainly not for its orthogonality. It was possible only to correct a few of these problems during the revision. But it was in fact used in many places (and still is in some), especially in Great Britain where the ICL machines were popular. Universally, those who had once used it never wanted to use anything else, and would gleefully point out the shortcomings of any other language you might care to name. It was the orthogonality that they liked (and the troublespots were in such obscure corners that no-one beyond the implementors ever noticed them). The most successful feature was the strong typing. It was a not at all uncommon experience for a program of significant size to work first time, once it had got past the compiler. Thus it was in actual use a very safe language. Another successful concept was orthogonality. No subsequent language has achieved it to quite the same degree, but it is now firmly fixed in every language designer's agenda. Some features, strangely, have not made it into more recent languages. Among these are truly unlimited strings (2.3.1), slices (2.3.2), and the transput model (2.3.9), none of which is particularly difficult to implement. It was often used as a first teaching language. Students usually demand to be taught the language that they are most likely to use in the world outside (FORTRAN or C). This is a mistake. A well-taught student (that is, one who has been taught a clean language) can easily pick up the languages of the world, and he or she will be in a far better position to recognize their bad features as he or she encounters them. It still has a role in teaching because of the concepts that it can illustrate. It is still a widely talked-about language (even among those who have never used it) and no respectable book on Comparative Programming Languages can afford to ignore it. Has it a future? The honest answer must now be "No." The world has moved on. To be accepted now, your language needs modules, exception handling, polymorphism, safe parallelism, and clean interfaces to everything else (not to mention a rich and powerful sponsor). Moreover, you need all these things from the start--this is certainly one place where Ada got it right. Was it TOO BIG? It has often been so accused, but it is really quite a small language compared with PL/1, or Ada. What, for example, does it provide beyond Pascal? Dynamic arrays, slices, formats, overloading, full block-structure, and expression-orientedness. Put these things into Pascal, make it orthogonal where it is not, and you have ALGOL 68. 2.8.2
Whatever Have We Learned from ALGOL 68?
The chief legacy of ALGOL 68 must be what the world has learned from it. I, personally, have learned a lot, and a major purpose of writing this paper was in order that others might do the same, bearing in mind that the chief lesson of history is that we do not learn from history. So, first I know more about the dynamics and instabilities (but also the benefits) of large committees, and against that I know what can be achieved by a small band of people dedicated to working towards a common aim (2.4.5). Next, there is the requirement for absolute rigour (which is not the same as formality) in the description of programming languages. I claim that we have shown that it can be done, but examples of real programming languages whose official definitions match this ideal are few and far between, and I know of no others where the rigorous definition was not a retrofit. What we achieved we achieved by consciously applying principles of good program design (2.4.3.3). We also recognized that rigour must be counterbalanced by adequate motivations and commentaries (2.5.5). And we must also warn of the considerable price to be paid in time and effort in order to do the job properly. Was the WG wrong to attempt too much innovation in what was intended as a language for widespread use? Possibly so. It may be that experimental features should be tried out in small ALGOL 68 SESSION
79
C. H. LINDSEY
experimental languages. Instead, we found ourselves with a large experimental language on our hands. That might have been avoided, but only at the expense of more time. Whether the ultimate benefit was worth all the effort and argumentation and heartbreak that went into it is another matter--and whether a good product can ever be made at all without some degree of heartbreak is also debatable.
ACKNOWLEDGMENTS I would like to acknowledge the help of several people who have read earlier versions of this paper and offered constructive comments, notably Tony Hoare, Kees Koster, John Peck, Brian Randell, Michel Sintzoff, Peter Lucas, and Henry Bowiden. I should also like to thank Wlad Turski for the excellent and almost verbatim minutes of WG meetings which he took down in longhand, and without which my task would have been impossible.
REFERENCES The ALGOL Bulletin, in which many of the following references appeared, was the official publication of WG 2.1. It is kept in a few academic libraries but, as the former Editor, I still have copies of most back numbers since AB 32, and could also probably arrange for photocopying of earlier issues. [AB 28.1.1] News item---Tenth anniversary colloquium, Ziidch, May 1968, ALGOL Bulletin AB28.1.1, Jul. 1968. [AB 31.1.1] News item---Minority report, ALGOL Bulletin AB31.1.1, Mar. 1970. ]AB 52.3.1] Survey of viable ALGOL 68 implementations, ALGOL Bulletin AB52.3.1, Aug. 1988. [Baecker, 1968] Baecker, H. D., ASERC--a code for ALGOL 68 basic tokens, ALGOL Bulletin AB28.3.5, J ul. ! 968. [Boom, 1972] Boom, H. J., IFIP WG 2.1 Working Paper 217 (Vienna 4), Sep. 1972. [Branquart, 1976] Branquart, E, Cardinael, J.-P., Lewi, J., Delescaille, J.-P., and Vanbegin, M., An optimized tratt~lation process and its ctpplication to ALGOL 68, LNCS 38. New York: Springer-Verlag, 1976. [Chastellier, 1969] De Chastellier, G., and Colmerauer, A., W-Grammar, Proc. 24th National Conference. New York: ACM Publication P-69, 1969. [Colrnerauer, 1996] Cohneraner A., and Roussel, P., The birth of Prolog, in these Proceedings. [Dahl, 1966] Dahl, O-J, A plea for multiprogramming, ALGOL Bulletin AB24.3.5, Sep. 1966. [Dahi, 1968] Dahl, O-J, Myhrhaug, B., and Nygaard, K., The Simula 67 Comnum Base Language. Oslo: Norwegian Computing Centre, Osio, 1%8. [De Morgan, 1976a] De Morgan, R. M., Hill, 1. D., and Wichman, B. A., A supplement to the ALGOL 60 revised report, Comp. Jour. 19:3, Aug. 1976, pp. 276--288; also SIGPLANNotices 12:1, January 1977, pp. 52---66. [De Morgan, 1976b] De Morgan, R. M., Modified report on the algorithmic language ALGOL 60, Comp. Jour. 19:4, Nov. 1976, pp. 364-379 ([Naur et aL 1962] as modified by [De Morgan 1976]). [De Morgan, 1978] De Morgan, R. M., Hill, 1. D., and Wichman, B., A. Modified ALGOL 60 and the step-until element, Comp. Jour. 21:3, Aug. 1978, p. 282 (essential errata to [De Morgan, 1976a] and Modified report [1976b]). [Dijkstra, 1968a] Dijkstra, E. W., Cooperating sequential processes, In Programming Languages, E Genuys, Ed., New York: Academic Press, 1968. [Dijkstra, 1968b] Dijkstra, E. W., Goto considered harmful, letter to the Editor, Comm. ACM 11:3, Mar. 1968. ]Duncan, 1964] Duncan, E G., and van Wijngaarden, A., Cleaning up ALGOL 60, ALGOL Bulletin AB16.3.3, May 1964. [Garwick, 1965] Garwick, J. V., The question of 1/O procedures, ALGOL Bulletin AB 19.3.8, Jan. i 965. [GOST 27974/9-88] Programming language ALGOL 68 and ALGOL 68 extended, GOST 27974-88 and GOST 27975-88, USSR State Committee for Standards, Moscow, 1989. [Grane, 1979] Grune, D, The Revised MC ALGOL 68 test set, IW 122/79, Amsterdam: Mathematisch Centrum, 1979. [Hansen, 1977] Hansen, Wilfred J., and Boom, Hendrik, The report on the standard hardware representation for ALGOL 68, SIGPLAN Notices 12:5, May, 1977; also Acta lnformatica 9, 1978, pp. 105-119. [Hibbard, 1977] Hibbard, P. G., A sublanguage of ALGOL 68, SIGPLAN Notices 12:5, May 1977. [Hoare, 1964] Hoare, C. A. R., Case expressions, ALGOL Bulletin AB 18.3.7, Oct. 1964. [Hoare, i 965a] Hoare, C. A. R., Cleaning up the for statement, ALGOL Bulletin AB21.3.4, Nov. 1965. [Hoare, 1965b] Hoare, C. A. R., Record Handling, ALGOL Bulletin AB21.3.6, Nov. 1965. [Hoare, 1966] Hoare, C. A. R., Further thoughts on record handling AB21.3.6, ALGOL Bulletin AB23.3.2, May 1966. [Hoare, 1968] Hoare, C. A. R., Critique of ALGOL 68, ALGOL Bulletin AB29.3.4, Nov. 1968. 80
CHAPTER II
PAPER: A HISTORY OF ALGOL 68 [Hoare, 1981] Hoare, C, A. R., The emperor's old clothes (the 1980 ACM Turing award lecture), Comm. ACM 24:2, Feb. 1981, pp. 75-83. [King, 1974] King, P. R., WG 2.1 subcommittee on ALGOL 68 support, ALGOL Bulletin AB37.3.1, Jul. ! 974. [Knuth et al., 1964] Knuth D. (Chairman), Bumgarner, L. L., Hamilton, D. E., lngerman, P. Z., Lietzke, M. P., Memer, J. N., and Ross, D. T., A proposal for input-output conventions in ALGOL 60, Comm. ACM 7:5, May 1964, pp. 273-283. [Koster, 1969] Koster, C. H. A., On infinite modes, ALGOL Bulletin AB30.3.3, Feb. 1969. [Koster, 1971] Koster, C. H. A., Affix-grammars, in ALGOL 68 Implementation, J. E. L. Peck, FEd., North Holland, 1971, pp. 95-109. [Lindsey, 1968] Lindsey, C. H., ALGOL 68 with fewer tears, ALGOL Bulletin AB28.3.1, Jul, 1968. [Lindsey, 1971] Lindsey, C. H., and Van der Me ulen, S. G., Informal Introduction to ALGOL 68, North Holland, 1971. [Lindsey, i 972] Lindsey, C. H., ALGOL 68 with fewer tears, Comp. Jour. 15:2, May 1972. [Lindsey, 1976] Lindsey, C. H., Specification of partial parametrizatioo proposal, ALGOL Bulletin AB39.3.1, Feb. 1976. [Lindsey, 1977] Lindsey, C. H., and Van der Meulen, S, G., Informal Introduction to ALGOL 68 Revised Edition, North Holland, 1977. [Lindsey, 1978] Lindsey, C. H., and Boom, H. J., A modules and separate compilation facility for ALGOL 68, ALGOL Bulletin AB43.3.2, Dec. 1978; also 1W 105/'78, MathematLsch Centrum, Amsterdam, 1978. [Lrf, 1984] Martin-Lrf, P., Constructive mathematics and computer programming, in Mathematical logic and programming languages, Hoare, C. A. R., and Shepherdson, J. C., Eds. New York: Prentice-Hall, 1985. [Lucas, 1969] Lucas, P., and Walk, K., On the formal description of PL/I, in Annual review in automatic programming 6:3, Pergammon, 1969, pp. 105-182. [Mailloux, 1968] Mailloux, B. J., On the implementation of ALGOL 68, Mathematisch Centrum, Amsterdam, 1968. [McCarthy, 1964] McCarthy, J., Definition of new data types in ALGOL X, ALGOL Bulletin ABI 8.3.12, Oct. 1964. [Meertens, 1969] Meertens, L. G. L. T., On the generation of ALGOL 68 programs involving infinite modes, ALGOL Bulletin AB30.3.4, Feb. 1969. [Merrier, 1966] Merrier, J. M., Garwiek, J. V., lngerman, P. Z., and Paul, M., Report of the ALGOL X 1-O subcommittee, IFIP WG 2.1 Working Paper 48 (Warsaw 3), July 1966. [Milner, 1990] Milner, R., Tofte, M., and Harper, R., The definition ~fstandardML, Cambridge, MA: MIT Press, 1990. [MR 76] Van Wijngaarden, A., Orthogonal design and description of a formal language, MR 76, Mathematisch C.entrum, Amsterdam, Oct. 1965. [W-2] Van Wijngaarden, A., and Mailloux, B. J., A draft proposal for the algorithmic language ALGOL X, IFIP WG 2.1 Working Paper 47 (Warsaw 2), Oct. 1966. [MR 88] Van Wijngaarden, A., Mailloux, B. J., and Peck, J. E. L., A draft proposal for the algorithmic language ALGOL 67, MR 88, Mathematisch Centrum, Amsterdam, May 1967. [MR 93] Van Wijngaarden, A., Ed., Mailloux, B. J., Peck, J. E. L., and Koster, C. H. A., Draft report on the algorithmic language ALGOL 68, MR 93, Mathematisch Centrum, Amsterdam, Jan. 1968. [MR 95] Van Wijngaarden, A., Ed., Mailloux, B. J., Peck, J. E. L., and Koster, C. H. A., Working document on the algorithmic language ALGOL 68, MR 95, Mathematisch Centrum, Amsterdam, Jul. 1968. [MR 99] Van Wijngaarden, A., Ed., Mailloux, B. J., Peck,J. E. L., and Koster, C, H. A., Penultimate draft report on the algorithmic language ALGOL 68, MR 99, Mathematisch Centrum, Amsterdam, Oct. 1968. [MR 100] Van Wijngaarden, A., Ed., Mailloux, B. J., Peck, J. E. L., and Koster, C. H. A., Final draft report on the algorithmic language ALGOL 68, MR 100, Mathematisch Centrnm, Amsterdam, Dec. 1968. [MR 101] The first printing of [Van Wijngaarden 1969]. [Naur et al., 1960] Backus, J. W., Bauer, F. L., Green, J., Katz, C., McCarthy, J., Naur, P. Ed., Perlis, A. J., Rutishauser, H., Samelson, K., Vauquois, B., Wegstein, J. H., Van Wijngaarden, A., and Woodger, M., Report on the algorithmic language ALGOL 60, Numerische Mathematik 2: 1960, pp. 106--136; also Comm. ACM 3:5, May 1960, pp. 299-314. [Naur et al., 1962] Backus, J. W., Bauer, F. L., Green, J., Katz, C., McCarthy, J., Naur, P. Ed., Perlis, A. J., Rutishauser, H., Samelson, K., Vauquois, B., Wegstein, J. H., Van Wijngaarden, A., and Woodger, M., Revised report on the algorithmic language ALGOL 60, Numerische Mathematik 4: 1963, pp. 420-453; also Comm. ACM 6:1, Jan. 1963, pp. 1-17; also Comp. Jour., 5:1, Jan. 1963, pp. 349-367. [Naur, 1964] Naur, P., Proposals for a new language, ALGOL Bulletin AB 18.3.9, Oct. 1964. [Naur, !966] - - . , The form of specifications, ALGOL Bulletin AB22.3.7, Feb. 1966 [Naur, 1968] - - - , Successes and failures of the ALGOL effort, ALGOL Bulletin AB28.3.3, Jul. 1968. [Naur, 1981] , The European side of the last phase of the development of ALGOL 60, in Hismry of Programming Languages, Richard L. Wexelblat, Ed. New York: Academic Press, 1981. [Pair, 1970] Pair, C., Concerning the syntax of ALGOL 68, ALGOL Bulletin AB31.3.2, Mar. 1970. [Peck, 1971] Peck J. E. L., ed., ALGOL 68 Implementation, North Holland, 1971.
ALGOL 68 SESSION
81
C. H. LINDSEY [R] See [Van Wijngaalden i 969]. [RR] See [Van Wijngaarden 1975]. [Ritchie, 1993] Ritchie, D. M., The development of the C language, in these Proceedings. [Ross, 1961] Ross, D. T., A generalized technique for symbol manipulation and numerical calculation, Comm. ACM, 4:3, Mar. 1961, pp. 147-50. [Ross, 1969] Ross, D. 'r., Concerning a minority report on ALGOL 68, ALGOL Bulletin AB30.2.3, Feb. 1969. [Samelson, 1965] Sameison, K., Fanctionals and functional transformations, ALGOL Bulletin AB20.3.3, Jul. 1965. [Seegmtlller, i 965a] ScegmUller, G., Some proposals for ALGOL X, ALGOL Bulletin AB21.3.1, Nov. 1965. [Seegmiiller, 1965b] Seegmiiller, G., A proposal for a basis for a report on a successor to ALGOL 60, Bavarian Acad. Sci., Munich, Oct. 1965. [Sintzoff, 1967] Sintzoff, M., Existence o f f Van Wijngaarden syntax for every recursively enumerable set, Annales Sot;. Sci. Bruxelles, 11, 1967, pp. 115-118. [Schuman, 1974] Schuman, S. A., Toward modular programming in high-level languages, ALGOL Bulletin AB37.4. I, Jill. 1974. [Stroustrup, 1996] Stroustrnp, B., A history of C++, in these Proceedings. [TR 74-3] The first palpatingof [Van Wijngaarden 1975], published as Technical Report TR74-3, Dept. of Computing Science, University of Alberta, Mar. 1974; subject to errata published inALGOL Bulletin AB37,5 Jul. 1974, AB38.5.1 Dec. 1974, and AB39.5.1 Feb. 1976. [Turski, 1968] Turski, W. M., Some remarks on a chapter from a document, ALGOL Bulletin AB29.2.4, Nov. 1968. [Turski, 1981] Turski, W. M., ALGOL 68 revisited twelve years later or from AAD to ADA, in Algorithmic Languages, J. W. de Bakker and J. C. van Vliet, Eds., North Holland, 1981. [Van der Meulen, ! 978] Van der Meulen, S. G. and Veldhorst, M., TORRIX--a programming systemJor operations on vectors and matrices over arbitrary fieMs and of variable size 14~L1, Mathematical Centre Tracts 86, Mathematisch Centrum, Amsterdam, 1978. [Van der Poel, 1965] Van der Poel, W. L., extract from WG 2.1 Activity Report, ALGOL Bulletin AB21.1.1. [Van der Poei, 1986] V~tnder Poel, W. L., Some notes on the history of ALGOL, in A quarter century ofiFIP, H. Zemanek, Ed., North Holland, 1986. [Van Vliet, 1979] Van Vliet, J. C., ALGOL 68 transput, Pt 1: Historical review and discussion of the implementation model, Pt 2: An implementation model, Mathematical Centre Tracts 110 and I 1 i, Mathematiseh Centrum, 1979. [Van Wijngaarden, 1969] Van Wijngaarden, A., Ed., Mailloux, B. J., Peck, J. E. L., and Koster, C. H. A., Report on the algorithmic lans:uage ALGOL 68, Numerische Mathematik 14: 1969, pp. 79-218; also A. P. Ershov and A. Bahrs, transl., Kybernetica 6, 1969, and 7, i 970, bilingual; also I. O. Kerner (transl.), Bericht fiber die algorithmische sprache ALGOL 68, Akademie-Verlag, Berlin, 1972, bilingual; also J. Buffet, P. Areal and A. Qu~r~ (transl.), DEfinition du langage algorithmique ALGOL 668,Hermann, Paris, 1972; also Lu Ru Qian (transl.), l [ t ~ g ALGOL 68 liter, Beijing, Science Press, 1977. [Van Wijngaarden, 1975] Van Wijngaarden, A., Mailloux, B. J., Peck, J. E. L., Koster, C. H. A., Sintzoff, M., Lindsey, C. H., Meertens, L. G. L. T., and Fisker, R. G,, Revised report on the algorithmic language ALGOL 68, Acta lnjq~rmatica 5:1-3, 1975; also Mathematical Centre Tract 50, Mathematisch Centrum, Amsterdam; also SIGPLAN Notices 12:5, May 1977; also I. O. Kemer, (transl.), Revidierter bericht fiber die algorithmische sprache ALGOL 68, Akademie-Verlag, Berlin, 1978; also A. A. Bahrs (transl.) and A. P. Ershov (Ed.), Peresmotrenoye So'obszczeniye ob ALGOLE 68, Izdatelstvo "Mlft," Moscow, 1979; also Lu Ru Qian (transl.), lllt~Utff ALGOL68 ~ R ~ l ~ , Beijing, Science Press, Aug. 1982. [W-2] Van Wijngaarden, A., and Mailloux, B. J., A draft proposal for the algorithmic language ALGOL X, IFI P WG 2. I Working Paper 47 (Warsaw 2), Oct. 1966. [WG 2.1, 1964a] Report on SUBSET ALGOL 60 (IFIP), Numerische Mathematik 6: (1964), pp. 454-458; also Comm. ACM 7:10, OCt. 1964, I?, 626. [WG 2.1, 1964b] Report on input-output procedures for ALGOL 60, Numerische Mathematik 6: pp. 459-462; also Comm. ACM 7:10, OCt. 1964, p 628. [WG 2.1, 1971a] Report of the subcommittee on data processing and transput, ALGOL Bulletin AB32.3.3, May 1971. [WG 2.1, 1971b] Report of the subcommittee on maintenance and improvements to ALGOL 68, ALGOL Bulletin AB32.3.4, May 1971. [WG 2.1, 1971c] Letter concerning ALGOL 68 to the readers of the ALGOL Bulletin, ALGOL Bulletin AB 32.2.8, May i 971. [WG 2.1, 1972a] WG 2. i formal resolution: Revised report on ALGOL 68, ALGOL Bulletin A B33.1.1, Mar. 1972. [WG 2.1, 1972b] Report of the subcommittee on maintenance of and improvements to ALGOL 68, August 1971, ALGOL Bulletin AB33.3.3, Mar. 1972. [WG 2.1, 1972c] Report of the subcommittee on data processing and transput, August 1971, ALGOL Bulletin AB33.3.4, Mar. 1972. [WG 2.1, 1972d] Report an the meeting of working group 2.1 held at Fontainebleau, ALGOL Bulletin AB34.3.1, Jul. 1972. 82
CHAPTER II
PAPER: A HISTORY OF ALGOL 68
[WG 2.1, 1972e] Report on considered improvements, ALGOL Bulletin AB34.3.2, Jul. 1972. [WG 2.1, 1972q Proposals for revision of the transput section of the report, ALGOL Bulletin AB34.3.3, Jul. 1972. [WG 2.1, 1973a] Further report on improvements to ALGOL 68, ALGOL Bulletin AB35.3.1, Mar. 1973. [WG 2.1, 1973b] Final report on improvements to ALGOL 68, ALGOL Bulletin AB36.3.1, Nov. 1973. [WG 2.1, 1975] IFIP WG 2.1 Working Paper 287 (TUM 10), Munich, Aug. 1975. [WG 2.1, 1978] Commentaries on the revised report, ALGOL Bulletin AB43.3.1, Dec. 1978. [WG 2.1, i 979] Commentaries on the revised report, ALGOL Bulletin AB44.3.1, May 1979. [Wirth, 1965] Wirth, N., A proposal for a report on a successor of ALGOL 60, MR 75, Mathematisch Centrum, Amsterdam, Oct. 1965. [Wirth, 1966a] Wirth, N., and Weber, H., EULER: A generalization of ALGOL, and its formal definition: Part I1, Comm. ACM 9:2, Feb. 1966, pp. 89-99. [Wirth, 1966b] Wirth, N., and Hoare, C. A. R., A contribution to the development of ALGOL, Comm. ACM 9:6, Jun. 1966, pp. 413.--431. [Wirth, 1966c] Wirth, N., Additional notes on "A contribution to the development of ALGOL," ALGOL Bulletin AB24.3.3, Sep. 1966. [Wirth, 1968] ALGOL colloquium---closing word, ALGOL Bulletin AB29.3.2, Nov. 1968.
APPENDIX A: THE COVERING LETTER Working Group 2.1 on ALGOL of the International Federation for Information Processing has been concerned for many years with the design of a common programming language and realises the magnitude and difficulty of this task. It has commissioned and guided the work of the four authors of this first Report on the Algorithmic Language ALGOL 68, and acknowledges the great effort which they have devoted to this task. The Report must be regarded as more than just the work of the four authors, for much of the content has been influenced by and has resulted from discussions in the Group. Consequently, this Report is submitted as the consolidated outcome of the work of the Group. This does not imply that every member of the Group, including the authors, agrees with every aspect of the undertaking. It is however the decision of the Group that, although there is a division of opinion amongst some of its members, the design has reached the stage to be submitted to the test of implementation and use by the computing community. The Group intends to keep continuously under review the experience thus obtained, in order that it may institute such corrections and revisions to the Report as may become desirable. To this end, it requests that all who wish to contribute to this work should do so both via the medium of the ALGOL Bulletin, and by writing to the Editor directly.
APPENDIX B: THE MINORITY REPORT We regard the current Report on Algorithmic Language ALGOL 68 as the fruit of an effort to apply a methodology for language definition to a newly designed programming language. We regard the effort as an experiment and professional honesty compels us to state that in our considered opinion we judge the experiment to be a failure in both respects. The failure of the description methodology is most readily demonstrated by the sheer size of the Report in which, as stated on many occasions by the authors, "every word and every symbol matters" and by the extreme difficulty of achieving correctness. The extensive new terminology and the typographical mannerisms are equally unmistakable symptoms of failure. We are aware of the tremendous amount of work that has gone into the production of the Report, but this confirms us in our opinion that adequacy is not the term that we should employ of its approach. We regard the high degree of inaccessibility of its contents as a warning that should not be ignored by dismissing the problems of "the uninitiated reader." That closer scrutiny has revealed grave deficiencies was only to be expected. Now the language itself, which should be judged, among other things, as a language, in which to compose programs Is/c]. Considered as such, a programming language implies a conception of the programmer's task. We recognize that over the last decade the processing power of commonly available machines has grown tremendously and that society has increased its ambition in their application in proportion to this growth, As a
ALGOL 68 SESSION
83
C. H. LINDSEY
result the programmer of today and tomorrow, finding his task in the field of tension between available equipment and desired applications, finds himself faced with tasks of completely different and still growing scope and scale. More than ever it will be required from an adequate programming tool that it assists, by structure, the programmer in the most difficult aspects of his job, that is, in the reliable creation of sophisticated programs. In this respect we fail to see how the language proposed here is a significant step forward: on the contrary, we feel that its implicit view of the programmer's task is very much the same as, say, ten years ago. This forces upon us the conclusion that, regarded as a programming tool, the language must be regarded as obsolete. The present minority report has been written by us because if we had not done so, we would have forsaken our professional responsibility towards the computing community. We therefore propose that this Report on the Algorithmic Language ALGOL 68 should not be published under IFIP sponsorship. If it is so published, we recommend that thin; "minority report" be included in the publication.
Signed by: Dijkstra, Duncan, Garwick, Hoare, Randell, Seegmiiller, Turski, Woodger. (In a letter dated Dec. 23 1968, Jan. V. Garwick, who had not been present at the Munich meeting, requested that his name be affixed to this Minority Report.)
TRANSCRIPT C)F PRESENTATION C. H. LINDSE¥: (SLIDE 1) My story starts with IFIE which is the International Federation for Information Processing. It is a hierarchical organization, as you see, with a layer of Technical Committees (TCL TC2 and so on), and finally a layer of Working Groups (such as Working Group 2.1, Working Groutp 2.2 and so on). And here we have the authors of the original A L G O L 60 Report. And, in 1962, tlaese authors in fact became Working Group 2.1 of IFIP. In due course Working Group 2.1 started out to produce a new language to follow A L G O L 60. Ideas for this future language, which became known as A L G O L X, were being discussed by the Working Group from 1964 onwards, culminating in a meeting at Princeton in May 1965. There was also a language A L G O L Y---originally it was a language which could modify its own programs, but in actual fact it turned out to be a "scapegoat" for features that would not fit into A L G O L X. At any rate, at Princeton they thought they were ready, and accordingly they solicited drafts of a complete language to be pre:~ented at the next meeting. (SLIDE 2) The next meeting, at St. Pierre de Chartreuse, there were three drafts on the table officially, but observe that a fourth document has crept in, and this was Hoare's paper on Records, which Wirth immediately accepted as an improvement on his own. Henceforth we must regard the Wirth/Hoare proposal as one, and it was eventually published in CACM as "A Contribution to the development of ALGOL," and in due course it became the language A L G O L W. Seegmialler's dccument was not a serious contender, but it did contain some interesting ideas for call-by-reference, of which more anon. Van Wijngaarden's document was entitled "Orthogonal design and description of a formal language." Its chief innovation was a new 2-1evel grammar, which so impressed the Working Group that they resolved formally, "Whatever language is finally decided upon by Working Group 2.1, it will be described by Van Wijngaarden's metalinguistic techniques." I find this rather surprising because Van Wijngaarden's document, in its original form, was both unreadable and buggy. These four authors were now charged to write THE Report for THE language, with the clear intention that the whole project would be completed within the next year. The history of what followed is very much concerned with parameter passing, so I propose to follow the development of this in some detail. It is said that an Irishman, when asked how to get to some remote place, answered that if you really want to get to that place, then you shouldn't start from
84
CHAPTER II
TRANSCRIPT OF ALGO 68 PRESENTATION
St. Pierre de Chartreuse (Oct 1965)
Political Background IFIP /
Authors of the ALGOL 60 Repod
t
Three draft proposals on the table:
sembly
1) Wirth D The=Contribution" Hoare's Records & ¥
Y
TCn
Ti2 ' \
v
~WG2.1
(ALgol)
v
= ALGOLW
2) Seegm0iler 3) Van Wijngaarden "Orthogonal Design ..."
,, ALGOL 68
v
WG2.2 WG2,3 WG2.4
...
Hoare, SeegmOller, van Wijngaarden and Wirth charged to wnte The Report.
SLIDE 1
SLIDE 2
here. In trying to find an acceptable parameter-passing mechanism, Working Group 2.1 started from ALGOL 60 which, it is well known, has two parameter-passing mechanisms---call-by-value and call-by-name. This was a grave mistake. (SLIDE 3) Here is call-by-name in ALGOL 60, and this example is straight out of the ALGOL 60 Report. There are two ways to use call-by-name: • y must be called by name, because it is a result parameter, • but a and b must be called by name because their corresponding actual-parameters in the call--xl[j] and yl[j]--are expressions that involve another actual-parameter, j, which corresponds to another formal-parameter p, also called by name, which is used in the loop counter of this for-statement, and the whole effect is then equivalent to this for-statement down at the bottom. And thatj stands for "Jensen." This technique was known as "Jensen's Device," and nowadays we should call it "Jensen's Hack." That is what it w a s - - a Neat Hack. But Hacks, however neat, should never be applied outside of their original context, but this is just what the Working Group now tried to do. (SLIDE 4) Well here is the Working Group's first attempt: • the result parameter y is now distinguished by the reserved word ioe, • but the need for call-by-name is now indicated, not in the procedure heading, but at the point of call, here, by this word expression. And the mysterious '~/" for Jensen is still there, so this is just a minor tinkering with Jensen's Device. (SLIDE 5) This is Seegmtiller's proposal, and it is call-by-reference much as we now know it: • y is now a reference parameter, • a and b are explicitly declared as procedures, • and at the point of call we have this word expression, here, to correspond to those procedure parameters. And Jensen's mysteriousj is still there as a parameter.
ALGOL 68 SESSION
85
C. H. LINDSEY Call-by-name In ALGOL 60
Call-by-name before St. Pierre
procedure lnnerproduct(a, b, k; p, y);
proc innerproduct = (real val a, b, Int vat k, int Ioc p, real Ioc y)
ve/ue k; Integer k, p; realy, a, b; begin reals; s := O; forp := I ~step l untilk dos := s+a*b; y:=s end lnnerproduct
void: begin real ver s := O; f o r p := 1 etep I untllk
dos:= s+a*b; y:=s end"
lore is a ¢~11:
teM array xl, yl [1 : n]; Integer j; real Z;
Innerproduct(xl ~], y l [j], n, j, z);
and here is a call:
Ioc [l:n] realxl, yl; Ioc intj; Ioc real z; innerproduct(ex~.'xl[j], expr:yl[j], n, j, z);
Which is equivalent to:
forj := 1 step 1 until k dos := s +xl[j]*yl[j]; SLIDE
3
SLIDE
4
(SLIDE 6) This is the scheme from the Hoare/Wirth proposal and the example is actually written in A L G O L W: • here y is now what they called an "anti-value" parameter, or call-by-value-result, as we should now say, •
but this x l ~ q , here, is just call-by-name, exactly as in A L G O L 60, so Jensen is still with us.
This then was the State-of-the-Art of parameter passing in October 1965, and its total confusion may be contrasted with the limited set of options to which modern programming language designers now confine themselves, and with the simplicity and elegance of the system that presently emerged for A L G O L 68. (SLIDE 7) Now we need to look at Hoare's Records. The concepts here should now seem quite familiar: •
we have a n~cord class with fields val and next,
• here we declare start as the start of an empty linked list, • and now, down here, when we say start := link, this is the only way to create new values of this link record class--and this means that links or records always live on the heap,
Call-by~'eference (SeegmOller)
proc innerproduct = (proc real a, b, Int k, hit reference p, real reference y) void: begin Ioc real s := O; forp := I a~ep I until k
dos := s+a*b; y:=s end; Ioc [ l : n ] realxL, y l ; Ioc i n t j ; Ioc realz; innerproduct ( expr: x l [j], expr. y l [j],
n, refj, refz);
86
procedure innerproduct (real a, real b, Integer value k, Integer p, real result y); begin y := O; p := 1; while p~k do beginy := y + a *b; p := p + I and and; a is by-name and b by-procedure.
And here is the call:
SLIDE
Call-by-value/result (ALGOL W)
5
Here is the call: reel arrey [ l : n ] x l , y l ; Integer j ; real z;
innerproduct(xl[j], yl[j], n, j, z);
SLIDE 6 CHAPTER II
TRANSCRIPT OF ALGOL 68 PRESENTATION Orthogonality
Hoare's Records
link; begin Integer val; reference next (link) end;
record class
begin reference start, temp (link); start := null; temp := start; start := link; comment creates new link; val(start) := 99; next(start) := temp;
end
SLIDE 7
-
A record c/ass was a type. :. record vadables, parameters, and results.
- ref x was a type, for any x. :. r e f r e f x w a s a type. - refs could be used for call-by-reference. :. refs to local variables. -
p r o c s could be used for parameters
... proc variables, parameters, and results. :. also constructors for anonymous p r o c s . - The left hand of an assignation had been a variable. Now it would be any ref valued expression.
SLIDE 8
• and these references, here and here, are nothing at all to do with Seegmiiller's references--as they cannot point to local variables and they are certainly not to be used for call-by-reference. Well, there should have been a full Working Group meeting in April 1966 to consider the report of the subcommittee, but the subcommittee Report was nowhere near ready. Instead, it was the subcommittee itself--Wirth, Hoare, Van Wijngaarden and Seegmiiller--that met at Kootwijk. Now, it had been agreed at St. PielTe that Van Wijngaarden should write the Draft Report for the subcommittee, using his formalism, but instead there were two documents on the table. The Wirth/Hoare one was called "A Contribution to the development of ALGOL," and indeed it bore more resemblance to the language that the Working Group intended, but it wasn't in Van Wijngaarden's formalism. Well, discussions proceeded amicably enough, many points were agreed, until they came to the parameter passing mechanism. And at this point a complete split developed within the subcommittee. So, what was all the fuss about? (SLIDE 8) Van Wijngaarden was pressing the parameter-passing mechanism that arose from his principle of "orthogonality." (Remember his original document "Orthogonal design and description of a formal language.") Now, according to the principle of orthogonality, •
A r e c o r d c l a s s was a type; therefore we could have record variables, record parameters and
record results. Nowadays we should say that a record was a "l st class citizen" of the language. • Similarly, we have references, so r e f x was a type, for any x; therefore it follows that ref ' r e f x ' was a type. • These references were values, so they could be used for call-by-reference, just as Seegmialler had proposed; therefore we needed to be able to have references to local variables, which Hoare did not allow for his references. • Similarly, you could pass procedures as parameters; therefore a procedure was a 1st class citizen. You could have procedure variables, procedure parameters and procedure results, and also constructors for a n o n y m o u s procedures. • And now, you see, traditionally in the older languages, the left hand side of an assignation had been a variable. Now it would simply be any ref valued expression.
ALGOL 68 SESSION
87
C. H. LINDSEY
Everything Is call-by-value
pro¢ innerproduct = (proc ( int) reel a, b, int k, ref real y) void: begin Ioc real s := O; fori tok d o s + : = a(i) * b(i) od; y:=s
end; And here is the call:
Ioc [ l : n ] realxl, yl; Ioc real z;
innerproduct( (intj) real: xl[j], (Int k) real: yl[kl, n, z); SLIDE
9
(SLIDE 9) So Hoare's records and Seegmiiller's references had now been coalesced into one grandiose scheme, in which everything was going to be called by value. This example is now written in true A L G O L 68: • y is declared as a ref parameter: the value we pass is simply a reference, • a and b are now
procedureparameters,
• and the conesponding actual parameter is now a constructed procedure, that is, a procedure of w h i c h j is just an ordinary formal-parameter. So Jensen is finally dead. It was orthogonality, and the use (or misuse) of references, that caused the split in the subcommittee, and Wirth and Hoare could not accept them at all. Of course all this came up again at the next meeting in Warsaw. The document Warsaw-2 had Van Wijngaarden as its only author. Could this be accepted as the document that had been commissioned from a subcommittee of four? Hoare was dubious at best and Wirth had resigned from the subcommittee and didn't even attend this meeting. Now came the great "Orthogonality" vs "Diagonality" debate. The discussion lasted the best part of a day, but Van Wijngaarden was able to demonstrate that his system was entirely self-consistent. The other thing which came up at Warsaw was McCarthy's scheme for overloaded operators. This was an entirely new topic, and it was resisted by Van Wijngaarden on the grounds that it was too late for such a major change. Clearly, the document Warsaw-2 was not going to be finalized that week, as some had initially imagined. So these are the decisions that the Working Group took at Warsaw: • First of all, l:he document was to be amended, with proper pragmatics. Note that "pragmatics" are to a Report as "comments" are to a program. • Then the document was to be published in the Algol Bulletin for all the world to see. • And implementation studies were to be incorporated in it. • Van Wijngaarden was to be the sole editor. • And at the next meeting they would get a chance to talk about A L G O L Y, and the meeting after that would take the final decision. • Oh! and McCarthy's overloading could be incorporated, if Van Wijngaarden found it to be feasible. 88
CHAPTER II
TRANSCRIPT OF ALGOL 68 PRESENTATION
The next meeting was at Zandvoort, and it was quite a constructive meeting (relatively speaking) although it didn't actually discuss much A L G O L Y. And there was no sign of rebellion. McCarthy's overloading was now in "in all its glory." Here I should say that those who were eventually to urge rejection of the Report all shared an exasperation with Van Wijngaarden's style, and with his obsessional behaviour in trying to get his way. He would resist change, both to the language and to the document, until pressed into it. • The standard reply to a colleague who wanted a new feature was first to say that it was too late to introduce such an upheaval to the document. • Then that the colleague should himself prepare the new syntax and semantics to go with it. • But then, at the next meeting, he would show with great glee how he had restructured the entire Report to accommodate the new feature and how beautifully it now fitted in. McCarthy's overloading, which required an enormous upheaval to the Report, provides the finest example of this behaviour. Well, the draft Report, as commissioned at Warsaw for publication in the Algol Bulletin, was dropped onto an unsuspecting public in February of 1968, and was the cause of much shock, horror, and dissent, even (and perhaps especially) among the membership of Working Group 2.1. At an A L G O L 58 Anniversary meeting at Zurich in May, •
it was attacked for its alleged "obscurity, complexity, inadequacy, and length,"
•
and defended by its authors for its alleged "clarity, simplicity, generality, and conciseness."
And both Naur and Wirth resigned from the Working Group at this time. The next meeting at Tirrenia was a stormy one, and the Report was the sticking point. As Randell said at that meeting, "From our discussions .... it seems to follow that there is reasonable agreement on the language, but there is the need for an investigation of alternative methods of description." So what to do? Well, it was decided, • First, that the present document could not go upwards to TC2; • But second, nevertheless, it was the document that had been commissioned at Warsaw, and so the author had fulfilled his obligation. Now what? Well, in the last hours of the meeting, Van Wijngaarden offered to prepare one last edition for final acceptance or rejection in December 1968. But there was one more meeting before that, at North Berwick, just before the IFIP Congress in Edinburgh. This was the first meeting I attended myself. It was a rude introduction into five days of continuous politics--Oh? there was one afternoon devoted to technical discussion. And the possibility of a Minority Report was being raised. The next meeting at Munich was relatively calm. Of course we had a decision to reach. A covering letter was prepared and its tenor was that This Report is submitted as the consolidated outcome of the work of the Group. It is ... the decision of the Group that, although there is a division of opinion amongst some of its members, the design has reached the stage to be submitted to the test of implementation and use by the computing community. (SLIDE 10) However, in the last hour of the meeting, some who were unhappy with the final form of the Covenng Letter, and with interpretations which were being put upon it, produced a minority
ALGOL 68 SESSION
89
C. H. LINDSEY The Minority Report
Signed by Dijkstra Duncan Garwick Hoare Randell Seegm011er Turski Woodger
The Editorial Team Kees Koster John Peck Barry Mailloux Aad van Wijngaarden
Transputer Syntaxer Implementer Party Ideologist
The Brussels Brainstormers
Note that Naur and Wirth had already resigned. TC2 declined to publish it.
SLIDE 10
M. Sintzoff P. Branquart J. Lewi ! P. Wodon
SLIDE 11
report. The text of that minority report is in the paper, and as you see, it was signed by some very worthy names. It was clearly intended to be published alongside the full Report, and the decision by TC2 not to do so I can only describe as Unethical and Inexcusable. (SLIDE 11) Well, there is the team that actually wrote the Report: •
Kees Koster (transputer) was a student at the Mathematisch Centrum under Van Wijngaarden.
• John Peck Isyntaxer) was on sabbatical leave from the University of Calgary. • Barry Mailloux (implementer) had been Van Wijngaarden's doctoral student from the time of Kootwijk. • And, of course, Aad van Wijngaarden himself (party ideologist) kept the whole thing together. Now, during tile preparation of the Report, drafts and comments were being circulated among an "inner circle," of whom the group of Branquart, Lewi, Sintzoff, and Wodon at MBLE in Brussels is especially to be ~Loted. Effectively, you see, there were two teams: One in Amsterdam creating the text, and another in Brussels taking it apart again, and this mechanism was actually very fruitful. (SLIDE 12) These are some of the new language features that appeared in A L G O L 68. • There were many new types and type constructors (references, unions, and so on), leading to the possibility of dynamic data structures. • There were lots of new operators. • There were environment enquiries. • The if was matched by fi, and other similar things. That solved the "dangling else" problem. • There were decent multi-dimensional arrays with nice slicing facilities. • There was a constant-declaratlon. As an example, here you could not assign to this pi as declared here because it is declared as a constant with this value. • Coercions. The three coercions shown here were known as 'widening' (integer to real), 'dereferencing' (reference to real to real), and 'deproceduring' (procedure returning real down to real). • And there was overloading of operators such as these two versions of + declared here, one for integers and one for reals.
90
CHAPTER II
TRANSCRIPT OF ALGOL 68 PRESENTATION The new Featurfm
New typos compl bits long.., string Type constructors ref struck...) union(...) proc(..J leading to dynamic data structures New operators
rood =be sign odd ...
Environmentenquiries max int smafl real ... No dangling else if... c u e . . . e u c do...od Slices
as[2:3, 4]
Constant-declaration real pi = 4.arctan(1); Coercion x :-- 2; y := x; x := random; Overloading op + = (Inta, b)int: ...; op + = (real a, b)real: ...;
The Revision
Habay-la-Neuve(July 1970) Manchester (Apr 1971) ; Novosibirsk(Aug 1971) Fontainebleau (Apr 1972) Vancouver(July 1972)
"l'imescale established
Editors appointed Editors' meeting
Vienna (Sep 1972)
Dresden (Apr 1973) Edmonton (July 1973) Los Angeles (Sap 1973)
Editors' meeting [RR] accepted
Revised Report publishedin Acts Informatica late 1975.
SLIDE 12
SLIDE 13
(SLIDE 13) The style of Working Group meetings became much less confrontational after 1968. The first implementation of something like ALGOL 68, by the Royal Radar Establishment at Malvern, appeared early in 1970. It now became clear that there were many irksome features of the language that hindered implementation and upwards-compatible extensions, while not providing any user benefit, and thus a revision was called for. The slide shows the timescale up to the point where Editors were appointed in 1972. The new Editors included Michel Sintzoff, from Brussels, and myself, later to be joined by Lambert Meertens and Richard Fisker. Van Wijngaarden and Koster, on the other hand, withdrew from any active role. Our brief was to consider, and to incorporate as far as possible" the points from various subcommittee reports and, having corrected all known errors in the Report, "also to endeavour to make its study easier for the uninitiated reader. The new editors got together in Vancouver in July of 1972, and it soon became apparent that, to make the language definition both watertight and readable, a major rewrite was going to be necessary. I therefore intend to take a look at the method of description used in the Report, starting with the 2-level van Wijngaarden grammar. (SLIDE 14) I am going to explain W-Grammars in terms of Prolog, since Prolog itself can be traced back to some early work by Colmerauer using W-Grammars. • So this rule is written in Prolog. We have a goal "do we see an assignation here?", and to answer this we must test subgoals "do we see a destination here?", "do we see a bec o m e s _ s y m b o l here?", and so on. And in Prolog, the values of variables such as MODE may be deduced from the subgoals, or they may be imposed with the question--in Prolog the distinction does not matter: the value of the variable just has to be consistent throughout. • In the corresponding ALGOL 68 rule, a goal is just a free string of characters, in which variables such as M O D E stand for strings produced by a separate context-free 'metagrammar'. • So M O D E can produce real, or integral, or reference to some other MODE, and so on (metagrammar is usually recursive). • So by choosing for ' M O D E ' the value 'real' you get the following production rule: a reference to real assignation is a reference to real destination, a becomes symbol and a real source. • Of course, this can produce things like x := 3.142. ALGOL 68 SESSION
91
C. H. LINDSEY
W-Grammars Here is a rule written in Prolog: assignation ( r e f ~ l O D E ) ) :destination (ref(MODE)), becomes_symbol, source(MODE). Corresponding W-Gray,mar: retercnce to MODE assignation : reference to MODE destination, becomessymbol,MODEsource.
Predicates Grammar:
where (NOTETY)is (NOTETY) : EMPTY. Example:
Where MODE :: real ; i~ltegroi ; reference to MODE ; ... Hence reference to real assignation : reference to real destination, becomes symbol, real source.
Whichcan producex ::= 3.142
strong MOlD FORM coercee : where (FORM) is (MORF), STRONG MOlD MORF ; where (FORM) is (COMORF), STRONG MOlD COMORF, unless (STRONG MOLD) is (deprocedurcd to void).
SLIDE 14
SLIDE 15
But observe how we have insisted that the M O D E of the destination x must be reference to real because the M O D E of the source 3.142 is reel(or you could argue the other way round--3.142 must be r e a l b e c a u s e x is known to be reference to r e e l - - y o u can argue both ways round just as in Prolog). (SLIDE 15) In the Revision, we found newer and cleaner ways to use W-Grammars, most notably through the use of "predicates." Here we have a rule to produce a thing called a s t r o n g - M O I D FORM-coercee. Now it so happens that F O R M s can be various things--some of them are called M O R F s , some of' them are called C O M O R F s . And the whole purpose of this rule is actually to forbid deproceduring of certain C O M O R F S , so I f the particularr F O R M we are dealing with happens to be a M O R F • this so-called "predicate" where ( F O R M ) is ( M O R F ) produces E M P T Y , so then we go ahead and produce what we wanted to produce. But if the ' F O R M ' is a ' C O M O R F ' • then we satisfy this predicate where ( F O R M ) is ( C O M O R F ) , • after which we also have to satisfy this one, which says that "unless the ' S T R O N G M O L D ' happens to be ' d e p r o c e d u r e d to void'." And that is so arranged that/fthe ' S T R O N G M O L D ' is not ' d e p r o c e d u r e d to void', then it does produce E M P T Y , but not so if the ' S T R O N G M O L D ' is ' d e p r o c e d u r e d to void'. • And in that case, since it doesn't produce anything at all, I am prevented from producing a deprocedun'ed-to-COMORF, as intended. Well, the point is that, with predicates, you can do the most amazing things, once you have learned how to use them. In the original Report, a whole chapter had been devoted to what we now call "static semantics." But we found too many bugs--shocks and surprises--in this chapter to have any confidence in its correctness. We were now determined that the Report should be written in such a way that we could successfully argue the correctness of any part of it. Hence the static semantics was put into the grammar, using predicates. Here is how it was done. (SLIDE 16) • Here again is the syntax of an assignation. Now you see that the assignation is accompanied by a ' N E S T ' containing all the declarations visible at that point in the program, and the d e s t i n a t i o n is accompanied by the same ' N E S T ' , and likewise the source,
92
C H A P T E R II
TRANSCRIPT OF ALGOL 68 PRESENTATION NESTS
~rsmm~r:
REF to MODE NEST assignation : REF to MODE NEST destination, becomes token, MODE NEST source.
Step 3: If the home containsan operator-deningoccurrence O I, in an operation-declaration (7.5.l.a,b),l of a terminal productionT of 'PRAM ADIC operator' which is the same terminal productionof 'ADIC indkation' as the given occurrence,and which {, the identicationof all descendent identlers , Indications and operators of the operand(s) of F having been made,} is such that some formula exists which is the same sequence of symbolsas F. whoseoperator is an occurrenceof T and which is such that the originalof each descendentidontler , Indication and operator of its operand(s) is the same notion as the original of the corresponding identler , indlration and operator contained in F {, which, if the program is a proper program, is uniquely determined by virtue of 4.4.1.a}, then the givenoccurrenceidenties O; otherwise, Step2 is taken.
SLIDE 16
SLIDE 17
And if the d e s t i n a t i o n or the source contains any identifiers, then predicates in the grammar ensure that each i d e n t i f i e r occurs properly in its ' N E S T ' , and the syntax of d e c l a r a t i o n s , of course, ensures that the ' N E S T ' corresponds to the things that actually were declared. And suitable ' N E S T ' s are propagated throughout the whole of the grammar, so that all the static semantics are incorporated. Well, that is the grammar, but the real problem with the original Report was n o t the W-Grammar; it was the style of the semantics, which was pedantic, verbose, and turgid. (SLIDE 17) Here is a nice example from the Original Report, which is concerned with the static semantics o f overloaded operators. Let me read it to you. [Dramatic reading of the slide, with applause]. Now that text happens to be both necessary and sufficient for its purpose, but I hope you can see why we concluded that the static semantics would be more safely described in the Syntax. (SLIDE 18) So we treated the Report as a large-scale programming project, consciously applying the principles of structured programming. Here, for example, is the original semantics of assignment. •
It is made up of all these Steps, and it is clearly a program full of gotos, and it conveys a general feeling of wall-to-wall verbosity.
(SLIDE 19) Here is the revised semantics of assignment, and I hope you will believe, from its layout alone, that you could readily set about understanding it if you had to. •
You see it has nice indentation, cases, local declarations, and for-loops.
Well, we took some examples of the new style of syntax and semantics to the next Working Group meeting in Vienna, where they were greeted with horror by some members. A "Petition for the Status Quo of A L G O L 68" was presented, claiming that the Revised Report had become a pointless undertaking and that the idea should be abandoned. This was debated on the very last day of the meeting, the motion being that the Revision should merely consist of the Old Report plus an addendum. • Well, we pointed out that some errors were almost impossible to correct in the old framework. • We pointed out that, to have a basis for upwards-compatible future extensions, we would need at least twice the list o f changes proposed by the petitioners. • We pointed out that it would then require an addendum half the size of the Report. • We were getting nowhere. Now it was time for the vote.
ALGOL 68 SESSION
93
C. H. LINDSEY From the Odginal FIoport:
And now from the Revised Report:
An tmstan~ of = value is ~ g n e d to • ~
A v=tue W is "=Siltned t,¢*• name N, w ~
in the fotluwing item:
Step l: If the given value d~es nol tern io • component of • meleOe rate* having one or nl~m: clams eqmtl to O ( 2.2.3.3,b|, i f the s~3fe of the 8ivcn ~ is nol ~q~'r than the ~ e of the given ~ l u e 12.2.4.2| ~ ff the ~ven m.u~=,is not nl~ then Step 2 is taken; cmerwise, the furlhe: eishecaem is endennnd; Step 2: The Ingaft ~e o( the value refereed to by the given name is ¢onddered; if the mode of the give• Atme hegin s with ' t'~rerettoe to s4rut'hl t,'NI w l i ' tit wlLh tt~ferenc~ Io row o~, Ih~n Step 3 is laken; ethe~wise, he conisden~d in•triBe Is mlpe~sednd 11) by • copy of the given inlum~ end ~e amdlplme~I hag been a~omllplir~ed; Step 3: If Ihe zonMdemd value is a s~ctured value, then Step 5 Is taken; ~herwite, applyln8 tnd noettk,n of 2.2.33,b Io it0 deecifpt~r, if for" rome I, 1=$~ . . , It. 111=$ (I1=~) and It (UI) is no~ e0/~l to the conespondld g boolM in the del, ~'iptor of me given vide*, then the further elabont lion is L~efih~nd: Step 4: If some ~ = 0 or t[80, mer~ licit. • ~ew bllttn~e of • multiple vile* M is ¢.~ead~dv ~ del~plor is • copy of the d e ~ of dt~l=given value mud fled by setting it= states to the ~.¢csponding staAcs in Ihe det~'l plm of me t~t•l~de~td value, and who* element= are copies o f el*meaty If my, of the cemldernd ~lae, and, et he~wi=:, =le new i~tanees of v a l u ~ w h ~ mode Is, or • mode 6ore w~ch is unlmd, the mode obndnnd by deklin8 all initial 'row oPs from the modc of the c(mlidcr Slep 5: Each nero ( e k ~ r ~ If any,) of t ~ given vahm is u ~ g n e d {in an order which is left und~fl ned ) to the name ~ f e r d q to me ~ ( ~ d i n g field (ekment, U ~y,) of the comidemd value m d Ihe lumlgnment lure been ac¢l~pUche~LAn i n ~ n ~ o f • value is im~Rnnd io • name in the followlag stcps:cd value; next M is mnde In be ~ f©nnd to by the I l i o n name and is ~as~t~etl inJqtad; Step 5: P ~ h a d d (*is•all, if ~y,) el"the given v•ltte is •reigned |in an tr~de~which is Icfl undenned I a, the name referring to the ctwo~spoading field (*leant, i f any,) of me (~nsidered v•tue and the • ,,d~l ~ beer •x'~empUd~d.
~ J e is wme 'REF tu MOIIE'. = J'qd k,w~
11is requiitvi thet • N be n~ Idl, u d Uml • W he m~ newer In ~cope *ban N; A: °MODE' is =role 'm'ueheml with IrlELIICi i m d t ': For each "TAG' wle~tag • field ta W, • thai fndd it mliMned to the subname select~J by 'TAG' in N: C a n U: ' ~ ' is tome 'ldoW$ er M O I ~ I': • k l V he Ihe Ctdd} value ~fcrred Io ~ N; • tt is leq4dlnd thel ~e de•clip•rim of W and V he idenical; V~reach intkx I ~ k~ltn 8 an element in W, • the• eldment it agdgnnd to Ihe mbname ~locted by I in N; Cue L*:* M O l l ~ * is scrub ' l l e ] d ~ ldOWS d MOIggl *: let V he I ~ I(~d | vldue referlea to by N; N is m t ~ to ~fer Ire• melllpl~ v•hle comtx-4ed of (t) the ~ t p k x of W. (il) Vldanls 14.4.2.c1 of = ~ * l e n t o I p ~.tdbly • ghoNIc l c ~ n t ) of • Nisendtnvndwilh~l'atame= 2.1.3.4.g~; K n ©~'h indtnt ~ l ~ , l i n l j ~ elemcm in W . • that element Is m i l ~ n d to ~e tubrame teleclnd by | tn N: C)tlll~ ( 2 ~ [e.g., whese ' M O I ) E * is some ' P L A I N * or ~ • N ~mnde vJmrer 12.1.3.2=1 ~ J W
SLIDE 18
' IJNITElY :
SLIDE 19
It had long been a Working Group tradition that straw votes were phrased in the form "Who could live w i t h . . . ? " rather than "Who prefers...?". So to let everybody see the full consequences before taking the formal vote, I proposed these questions. "Who could live with the state if the resolution was passed?" •
12 could live with it, 5 could not live with it, and 1 abstained.
"Who could live with the opposite state?" •
12 could live with the opposite state, 1 could not, and 5 abstained.
Now van Wijn~aarden was always a superb politician. Having observed who had actually voted, he pointed out that passing the resolution "would cause the death of five of the six editors, which seemed a most unproductive situation." And then the formal motion was put. [6-6-6] And we were through. By the next meeting in Dresden, all the fuss bad subsided, and people even complimented us on the improved clarity. The editors held a second three-week get-together in Edmonton, and the Revised Report was accepted, subject to polishing, in September 1973 in Los Angeles. So here are my recommendations to people who essay to design programming languages. • The work should be done by a small group of people (four or five is plenty). • There is considerable advantage in geographical separation, as between Amsterdam and Brussels the first time, or between Manchester, Vancouver, and Edmonton the second time. • The Editors need tidy and pernickety minds and, incidentally, good editors are not necessarily good language designers, nor vice versa. • You should construct a formal definition of the language at the s a m e time. I believe ALGOL 68 is the only major language in which the Formal Definition was not a retrofit. • There is considerable benefit in doing the whole job twice. We had that advice this morning also. • And we most certainly observed that large committees are unstable (although they may be necessary for democratic reasons). 94
C H A P T E R It
TRANSCRIPT OF QUESTION AND ANSWER SESSION
And here are my recommendations for writing Reports. * There must be copious pragmatic remarks, well delineated from the formal text. The purpose of these remarks is to educate the reader. * Motivation should be given for why things are as they are. This means that we have redundancy, but redundancy is no bad thing. • The syntax should be fully cross referenced, forwards, backwards, and every which-way; and the semantics likewise. • And the Report should not take itself too seriously. The Report is not going to be perfect. Our Report contained some good jokes, many quotations from Shakespeare, Lewis Carroll, A. A. Milne and others, and even a picture of Eeyore. • So, above all, the Report should be fun to write. Unfortunately, Standards Bodies and Government Departments do not always encourage these practices in their guidelines. I invite you to consider the extent to which they have been followed, or otherwise, in more recent programming language definitions, together with the perceived success of those definitions. On that basis I will rest my case.
TRANSCRIPT OF QUESTION AND ANSWER SESSION HERBERT KLAEREN (University of Tubingen): Could you explain the hipping coercion a bit. In your example, x := ifp then y else goto error fi, I would expect that x doesn't change i f p is false. How does the coercion come in? LINDSEY: The hipping coercion was a dirty piece of syntax in the original Report. It is simply that, if you have got a conditional expression, one half of it itsome condition then some value, then that presumably is the mode of the result. If the else part says goto error, what is the mode of goto error? So there was a fictitious coercion to make everything look tidy. It was syntactic tidiness. STAVROS MACRAKIS (OSF Research Institute): or bad?
Was the schedule of three meetings per year good
LINDSEY: It would average nearer two, except when things got hectic in 1968. The work has to be done off-line by a small group of four or five people. The function of a committee is simply to oversee. So two meetings a year is plenty. This matter might come up again with Colonel Whitaker this afternoon. MARTIN CAMPBELL-KELLY (University of Warwick): dying language?
Is ALGOL 68 completely dead, or just a
LINDSEY: It is a matter of common knowledge--it is not currently in widespread use, but, there are places that still use it. If you want a compiler, see me afterwards. Incidentally, there are some documents at the back, and one of them is a copy of the Algol Bulletin (AB 52, August 1988) listing all the implementations that currently exist, or did exist a few years ago. MIKE WILLIAMS (University of Calgary): I once asked John Peck if ALGOL 68 was ever intended to be used or if it was an intellectual exercise. LINDSEY: It was quite definitely intended as a language to be used. The reasons why languages do, or do not, get used bear little resemblance to the goodness or badness of the language. And which is ALGOL 68 SESSION
95
BIOGRAPHY OF C. H. LINDSEY
the most commonly used language at the moment, and is it a good one? I won't name it, but I am sure you all have you]r ideas. Yes, it was definitely intended to be used, and the reasons it wasn't are as much political as technical, I think. HERBERT KLAEREN (University of Tubingen): ALGOL 68 has been criticized as being a committee-designed language, and looking that way. From your history of the original ALGOL 68 Report, I got the impression that it was much more Van Wijngaarden's language than it was a committee language. Could '.youcomment on that? LINDSEY: I think it was a well-designed language in spite of being designed by a committee. You say that a camel is a horse designed by a committee. ALGOL 68 was no camel. It was Van Wijngaarden's personality, I think, which kept it clean in spite of the committee. Nevertheless, many of the odd little features which are in, are in because the committee said--voted--"we want this X in like this"; and there it is if you look. Usually, where there are unfortunate little holes in the language, they are usually small little things--nothing to do with the orthogonality. Many of those, I think, were put in because sudtdenly the Working Group said "I want this," and they got it. Van Wij ngaarden always reserved to himself the right as to how the thing was described. I am not sure whether this was necessarily a good thing or not. It was done in spite of a rather large and somewhat unruly committee. But, in a democr~tcy, committees are necessary. HERBERT KLAEREN (University of Tubingen): Why is the rowing coercion "clearly" a mistake? In connection wiith string processing, it would seem natural to coerce a character "A" into a one-element string, if necessary. LINDSEY." Because its effect is counter-intuitive (my students were always surprised when it did not produce an array of some appropriate size with all the elements initialized to the given value). It was put in to fix a hole in the syntax. Indeed, it also turns a ¢harinto a one-element string, but that could have been brought about in other ways. No other language has had to do it this way.
BIOGRAPHY OF C. H. LINDSEY Charles Lindsey was born in Manchester, UK, in 1931. He obtained his Bachelor's degree in Physics at Cambridge University in 1953, and his PhD in 1957 for a thesis exploring use of the newly invented ferrite cores for logical purposes rather than for storage. At that time, he was clearly an engineer, although he did write some programs for the EDSAC. From 1957, he., worked for Ferranti (now a part of ICL), becoming project leader for the Orion computer (that was actually the first commercial time-sharing computer, although it was never a commercial success). After that, he worked on "Design Automation" (or Computer Aided Design, as we should now say), and designed his first programming language for simulating hardware. In 1967, he joined the staff of the recently created Department of Computer Science at the University of Manchester, where he immediately became interested in the language ALGOL 67 (as it then was) under development by IFIP Working Group 2.1. A paper "ALGOL 68 with fewer tears" written to explain the new language informally to the "uninitiated reader" brought him to the notice of WG 2.1, of which he soon became a full member. Enhancement and development of ALGOL 68 kept him fully occupied until about 1983. This was followed by some work on extensible languages, and participation in the continuing work of WG 2.1, which was now centered around specification languages. He retired from the University in 1992, but took his computer home with him, so as to be able to continue working in Computer Science. 96
CHAPTER II
III Pascal Session
Chairman: Jacques Cohen Discussant: Andrew B. Mikel
RECOLLECTIONS ABOUT THE DEVELOPMENT OF PASCAL N. Wirth Institut for Computersysteme, ETH Zudch CH-8092 Zurich
ABSTRACT Pascal was defined in 1970 and, after a slow start, became one of the most widely used languages in introductory programming courses. This article first summarizes the events leading to Pascal's design and implementation, and then proceeds with a discussion of some of the language's merits and deficiencies. In the last part, developments that followed its release are recounted. Its influence chiefly derived from its being a vehicle for structured programming and a basis for further development of languages and for experiments in program verification. CONTENTS 3.1 Early History 3.2 The Language 3.3 Later Developments 3.4 In Retrospect Acknowledgments References
3.1
EARLY HISTORY
The programming language Pascal was designed in the years 1968-1969, and I named it after the French philosopher and mathematician, who in i 642 designed one of the first gadgets that might truly be called a digital calculator. The first compiler for Pascal was operational in early 1970, at which time the language definition also was published [Wirth 1970]. These facts apparently constitute the anchor points of the history of Pascal. However, its genuine beginnings date much further back. It is perhaps equally interesting to shed some light on the events and trends of the times preceding its birth, as it is to recount the steps that led to its widespread use. I shall therefore start with a more or less chronological narrative of the early history of Pascal. In the early 1960s, there existed two principal scientific languages: FORTRAN and ALGOL 60 [Naur 1963]. The former was already in wide use and supported by large computer manufacturers. The latter--designed by an international committee of computing experts--lacked such support, but 97
NIKLAUS WIRTH
attracted attention by its systematic structure and its concise, formalized definition. It was obvious that ALGOL deserved more attention and a wider field of applications. In order to achieve it, ALGOL needed additional constructs to make it suitable for purposes other than numerical computation. To this end, IFIP established a Working Group with the charter of defining a successor to ALGOL. There was hope that the undesirable canyon between scientific and commercial programming, by the mid-1960s epitomized as the FORTRAN and COBOL worlds, could be bridged. I had the privilege of joining Working Group 2.1 in 1964. Several meetings with seemingly endless discussions about general philosophies of language design, about formal definition methods, about syntactic details, character sets, and the whole spectrum of topics connected with programming revealed a discouraging lack of consensus about the approach to be taken. However, the wealth of ideas and experience presented also provided encouragement to coalesce them into a powerful ensemble. As the number of meetings grew, it became evident that two main factions emerged from the roughly two dozen members of the Working Group. One party consisted of the ambitious members, unwilling to build upon the framework of ALGOL 60 and unafraid of constructing features that were largely untried and whose consequences for implementors remained a matter of speculation, who were eager to erect another milestone similar to the one set by ALGOL 60. The opponents were more pragmatic. They were anxious to retain the body of ALGOL 60 and to extend it with well-understood features, widening the area of applications for the envisaged successor language, but retaining the orderly structure of its ancestor. In this spirit, the addition of basic data types for double precision real numbers and for complex numbers was proposed, as well as the record structure known from COBOL, the replacement of ALGOUs call-by-name with a call-by-reference parameter, and the replacement of ALGOL's overly general for-statement by a restricted but more efficient version. They hesitated to incorporate novel, untested ideas into an official language, well aware that otherwise a milestone might easily turn into a millstone. In 1965, I was commissioned to submit a proposal to the WG, which reflected the views of the pragmatists. In a meeting in October of the same year, however, a majority of the members favored a competing proposal submitted by A. van Wijngaarden, former member of the ALGOL 60 team, and decided to select it as the basis for ALGOL X in a meeting in Warsaw in the fall of 1966 [van Wijngaarden, 1969]. Unfortunately, but as foreseen by many, the complexity of ALGOL 68 caused many delays, with the consequence that, at the time of its implementation in the early 1970s, many users of ALGOL 60 had already adopted other languages [Hoare 1980]. I proceeded to implement my own proposal in spite of its rejection, and to incorporate the concept of dynamic data st~ructures and pointer binding suggested by C. A. R. Hoare. The implementation was made at Stanford University for the new IBM 360 computer. The project was supported by a grant from the U.S. National Science Foundation. The outcome was published and became known as ALGOL W [Wirth 1966]. The system was adopted at many universities for teaching programming courses, but the language remained confined to IBM 360/370 computers. Essentially, ALGOL W had extended ALGOL 60 with new data types representing double precision floating..point and complex numbers, with bit strings and with dynamic data structures linked by pointers;. In spite of pragmatic precautions, the implementation turned out to be rather complex, requiring a run-time support package. It failed to be an adequate tool for systems programming, partly because it was burdened with features unnecessary for systems programming tasks, and partly because it lacked adequately flexible data structuring facilities. I therefore decided to pursue my original goal of designing a general-purpose language without the heavy constraints imposed by the necessity of fi~kding a consensus among two dozen experts about each and every little detail. Past experience had given me a life-long mistrust in the products of committees, where many participate in debating and decision making, and few perform the actual work--made difficult by the many. In 98
CHAPTER Ul
PAPER: RECOLLECTIONS ABOUT THE DEVELOPMENT OF PASCAL
1968, I assumed a professorship at the Federal Institute of Technology in Zurich (ETH), where ALGOL 60 had been the language of choice among researchers in numeric computation. The acquisition of CDC computers in 1965 (and even more so in 1970), made this preference hard to justify, because ALGOL compilers for these computers were rather poorly designed and could not compete with their FORTRAN counterparts. Furthermore, the task of teaching programming-in particular, systems programming--appeared highly unattractive, given the choice between FORTRAN and assembler code as the only available tools. After all, it was high time to not only preach the virtues of structured programming, but to make them applicable in actual practice by providing a language and compilers offering appropriate constructs. The discipline of structured programming had been outlined by E. W. Dijkstra [Dijkstra 1966] and represented a major step forward in the battle against what became known as the "Software Crisis." It was felt that the discipline was to be taught at the level of introductory programming courses, rather than as an afterthought while trying to retrain old hands. This insight is still valid today. Structured programming and stepwise refinement [Wirth 1971 a] marked the beginnings of a methodologyof programming, and became a cornerstone in helping program design become a subject of intellectual respectability. Hence, the definition of a new language and the development of its compiler were not a mere research project in language design, but rather a blunt necessity. The situation was to recur several times in the following decades, when the best advice was: Lacking adequate tools, build your own! In 1968, the goals were twofold: The language was to be suitable for expressing the fundamental constructs known at the time in a concise and logical way, and its implementation was to be efficient and competitive with existing FORTRAN compilers. The latter requirement turned out to be rather demanding, given a computer (the CDC 6000) that was designed very much with FORTRAN in mind. In particular, dynamic arrays and recursive procedures appeared as formidable obstacles, and were therefore excluded from an initial draft of the language. The prohibition of recursion was a mistake and was soon to be rectified, in due recognition that it is unwise to be influenced severely by an inadequate tool of a transitory nature. The task of writing the compiler was assigned to a single graduate student (E. Marmier) in 1969. As his programming experience was restricted to FORTRAN, the compiler was to be expressed in FORTRAN, with its translation into Pascal and subsequent self-compilation planned after its completion. This, as it turned out, was another grave mistake. The inadequacy of FORTRAN to express the complex data structures of a compiler caused the program to become contorted and its translation amounted to a redesign, because the structures inherent in the problem had become invisible in the FORTRAN formulation. The compiler relied on syntax analysis based on the table-driven bottom-up (LR) scheme adopted from the ALGOL W compiler. Sophistication in syntax analysis was very much in style in the 1960s, allegedly because of the power and flexibility required to process high-level languages. It occurred to me then that a much simpler and more perspicuous method could well be used, if the syntax of a language was chosen with the process of its analysis in mind. The second attempt at building a compiler therefore began with its formulation in the source language itself, which by that time had evolved into what was published as Pascal in 1970 [Wirth 1970]. The compiler was to be a single-pass system based on the proven top-down, recursive-descent principle for syntax analysis. We note here that this method was eligible because the ban against recursion had been lifted: recursivity of procedures was to be the normal case. The team of implementors consisted of U. Ammann, E. Marmier, and R. Schild. After the program was completed--a healthy experience in programming in an unimplemented language!--Schild was banished to his home for two weeks, the time it took him to translate the program into an auxiliary, low-level language available on the CDC computer. Thereafter, the bootstrapping process could begin [Wirth 1971b]. PASCAL SESSION
99
NIKLAUS WlRTH
This compiler was completed by mid- 1970, and at this time the language definition was published. With the exception of some slight revisions in 1972, it remained stable thereafter. We began using Pascal in introductory programming courses in late 1971. As ETH did not offer a computer science program until ten years later, the use of Pascal for teaching programming to engineers and physicists caused a certain amount of controversy. My argument was that the request to teach the methods used in industry, combined with the fact that industry uses the methods taught at universities, constitutes a vicious circle bax~ng progress. But it was probably my stubborn persistence rather than any reasoned argument that kept Pascal in use. Ten years later, nobody minded. In order to assist in the teaching effort, Kathy Jensen started to write a tutorial text explaining the primary programming concepts of Pascal by means of many examples. This text was first printed as a technical report and thereafter appeared in Springer-Verlag's Lecture Notes Series [Jensen 1974]. 3.2
THE LANGUAGE
The principal role of a language designer is that of a judicious collector of features or concepts. Once these concepts are selected, forms of expressing them must be found, that is, a syntax must be defined. The forms expressing individual concepts must be carefully molded into a whole. This is most important, as otherwise the language will appear as incoherent, as a skeleton onto which individual constructs were grafted, perhaps as afterthoughts. Sufficient time had elapsed that the main flaws of ALGOL were known and could be eliminated. For example, the importance of avoiding ambiguities had been recognized. In many instances, a decision had to be taken whether to solve a case in a clear-cut fashion, or to remain compatible with ALGOL. These options sometimes were mutually exclusive. In retrospect, the decisions in favor of compatibility were unfortunate, as they kept inadequacies of the past alive. The., importance of compatibility was overestimated, just as the relevance and size of the ALGOL 60 community had been. Examples of such cases are the syntactic form of structured statements without closing symbol, the way in which the result of a function procedure is specified (assignment to the function identifier), and the incomplete specification of parameters of formal procedures. All these deficiencies were later corrected in Pascal's successor language, Modula-2 [Wirth 1982]. For example, ALGOL's ambiguous conditional statement was retained. Consider IF p THEN
I'F q T H E N
A ELSE
B
which can, according to the specified syntax, be interpreted in the following two ways: IF p THEN IF p THEN
[:IF q T H E N A E L S E BI [ IF q THEN A ] ELSE
B
Pascal retained this syntactic ambiguity, selecting, however, the interpretation that every ELSE be associated with the closest THEN at its left. The remedy, known but rejected at the time, consists of requiring an explicit closing symbol for each structured statement, resulting in the two distinct forms for the two cases a,s shown below: IF
p THEN IF
END
q TR'EN A E L S E
IF p THEN B END ELSE
IF q THEN B
A
END
END
Pascal also retaiined the incomplete specification of parameter types of a formal procedure, leaving open a dangerous ]loophole for breaching type checks. Consider the declarations
100
CHAPTER III
PAPER: RECOLLECTIONS ABOUT THE DEVELOPMENT OF PASCAL PROCEDURE BEGIN
P
q(x,
PROCEDURE BEGIN ...
(PROCEDURE y)
END
q);
;
Q (x: R E A L ) ; END ;
and the call P(Q). Then q is called with the wrong number of parameters, which cannot in general be detected at the time of compilation. In contrast to such concessions to tradition stood the elimination of conditional expressions. Thereby the symbol IF clearly becomes a marker of the beginning of a statement, and bewildering constructs of the form IF p THEN
x
:= I F q T H E N
y ELSE
z ELSE
w
are banished from the language. The baroque for-statement of ALGOL was replaced by a tamed version, which is efficiently implementable, restricting the control variable to be a simple variable and the limit to be evaluated only once instead of before each repetition. For more general cases of repetitions, the while statement was introduced. Thus it became impossible to formulate misleading, nonterminating statements, as, for example FOR
I
:= 0 S T E P
1 UNTIL
I DO
S
and the rather obscure formulation FOR
I
:= n - l ,
I-i
WHILE
I > 0 DO
S
could be expressed more clearly by I
:=
WHILE
n;
I • 0 DO
BEGIN
I
:= I - l ;
S END
The primary innovation of Pascal was to incorporate a variety of data types and data structures, similar to ALGOL's introduction of a variety of statement structures. ALGOL offered only three basic data types: integers, real numbers, and truth values, and the array structure; Pascal introduced additional basic types and the possibility to define new basic types (enumerations, subranges), as well as new forms of structuring: record, set, and file (sequence), several of which had been present in COBOL. Most important was of course the recursivity of structural definitions and the consequent possibility to combine and nest structures freely. Along with programmer-defined data types came the clear distinction between type definition and variable declaration, variables being instances of a type. The concept of strong typing--already present in ALGOL---emerged as an important catalyst for secure programming. A type was to be understood as a template for variables specifying all properties that remain fixed during the time span of a variable's existence. Whereas its value changes (through assignments), its range of possible values remains fixed, as well as its structure. This explicitness of static properties allows compilers to verify whether rules governing types are respected. The binding of properties to variables in the program text is called early binding and is the hallmark of high-level languages, because it gives clear expression to the intention of the programmer, unobscured by the dynamics of program execution. However, the strict adherence to the notion of(static) type led to some less fortunate consequences. We refer here to the absence of dynamic arrays. These can be understood as static arrays with the number of elements (or the bounding index values) as a parameter. Pascal did not include parameter-
PASCAL SESSION
101
NIKLAUS WIRTH
ized types, primarily for reasons of implementation, although the concept was well understood. Whereas the lack of dynamic array variables may perhaps not have been too serious, the lack of dynamic array parameters is clearly recognized as a defect, if not in the view of the compiler-designer, then certainly in the view of the programmer of numerical algorithms. For example, the following declarations do not permit procedure P to be called with x as its actual parameter: TYPE VAR
A0
=: ARRAY
[3...
A1
= ARRAY
[0
x:
Ai;
PROCEDURE
P(x:
A0);
..
BEGIN
3.00]
OF REAL;
999]
OF
...
REAL;
END
Another important contribution of Pascal was the clear conceptual and denotational separation of the notions of structure and access method. Whereas in ALGOL W, arrays could only be declared as static variables and hence could only be accessed directly, record structured variables could only be accessed via references (pointers), that is, indirectly. In Pascal, all structures can be either accessed directly or via pointers, indirection being specified by an explicit dereferencing operator. This separation of concerns was known as "orthogonal design," and was pursued (perhaps to extreme) in ALGOL 68. The introduction of explicit pointers, that is, variables of pointer type, was the key to a significant widening of the scope of application. Using pointers, dynamic data structures can be built, as in list-processing languages. It is remarkable that the flexibility in data structuring was made possible without sacrificing strict static type checking. This was due to the concept of pointer binding, that is, of declaring each pointer type as being bound tothe type of the referenced objects, as proposed by [Hoare 1972]. Consider, for instance, the declarations TYPE
Pt Rec
VAR
p,
=
~ Ree; = RECORD
q:
x,
y:
REAL
END
;
Pt;
Then p and q, provided they had been properly initialized, are guaranteed to hold either values referring to a record of type Ree, or the constant NIL. A statement of the form p'r.x
:=
pT.y + qT.x
turns out to be as type-safe as the simple x := x + y. Indeed, pointers and dynamic structures were considerably more important than dynamic arrays in all applications except numeric computation. Intricately connected to pointers is the mechanism of storage allocation. As Pascal was to be suitable as a system-building language, it tried not to rely on a built-in run-time garbage collection mechanism, as had been necessary for ALGOL W. The solution adopted was to provide an intrinsic procedure NEW for allocating a variable in a storage area called "the heap," and a complementary one for deallocation (DISPOSE). NEW is easy to implement, and DISPOSE can be i~;nored, and indeed it turned out to be wise to do so, because system procedures depending on prog~rammer's information are inherently unsafe. The idea of providing a garbage collection scheme was not considered in view of its complexity. After all, the presence of local variables and of programmer-defined data types and structures requires a rather sophisticated and complex scheme, crucially depending on system integrity. A collector must be able to rely on information about all variables and their types. This information must be generated by the compiler and, moreover, it must be impossible to invalidate it during program execution. The subject of parameter-passing ~aethods had already been a source of endless debates and hassles in the days of the search for a successor to ALGOL 60. The impracticality of its name parameter had been clearly established, and the indispensability of the value parameter was generally accepted. Yet there were
102
CHAPTER III
PAPER: RECOLLECTIONS ABOUT THE DEVELOPMENT OF PASCAL
valid arguments for a reference parameter, in particular for structured operands on the one hand, and good reasons for result parameters on the other. In the former case the formal parameter constitutes a hidden pointer to the actual variable; in the latter the formal parameter is a local variable to be assigned to the actual variable upon termination of the procedure. The choice of the reference parameter (in Pascal called VAR-parameter) as the only alternative to the value parameter turned out to be simple, appropriate, and successful. And last but not least, Pascal included statements for input and output, whose omission from ALGOL had been a source of continuing criticism. Particularly with regard to Pascal's role as a language for instruction, a simple form of such statements was chosen. Their first parameter designates a file and, if omitted, causes the data to be read from or written to the default medium, such as keyboard and printer. The reason for including a special statement for this purpose in the language definition, rather than postulating special, standard procedures, was the desire to allow for a variable number and different types of parameters: Read(x, y ) ;
...
; Write(x,
y,
z)
As mentioned before, a language designer collects frequently used programming constructs from his or her own experience, from the literature, or from other languages, and molds them into syntactic forms in such a way that they together form an integrated language. Whereas the basic framework of Pascal stems from ALGOL W, many of the new features emerged from suggestions made by C. A. R. Hoare, including enumeration, subrange, set, and file types. The form of COBOL-like record types was due to Hoare, as well as the idea to represent a computer's "logical words" by a well-known abstraction--namely, sets (of small integers). These "bits and pieces" were typically presented and discussed during meetings of the IFIP Working Group 2.1 (ALGOL), and thereafter appeared as communications in the ALGOL Bulletin. They were collected in Hoare's Notes on Data Structuring [Hoare 1972]. In Pascal, they were distilled into a coherent and consistent framework of syntax and semantics, such that the structures were freely combinable. Pascal permits the definitions of arrays of records, records of arrays, arrays of sets, and arrays of records with files, to name just a few possibilities. Naturally, implementations would have to impose certain limits as to the depth of nesting due to finite resources, and certain combinations, such as a file of files, might not be accepted at all. This case may serve as an example of the distinction between the general concepts defined by the language, and supplementary, restrictive rules governing specific implementations. Although the wealth of data types and structuring forms was the principal asset of Pascal, not all of the components were equally successful. We keep in mind that success is a subjective quality, and opinions may differ widely. I therefore concentrate on an "evaluation" of a few constructs where history has given a reasonably clear verdict. The most vociferous criticism came from Habermann, who correctly pointed out that Pascal was not the last word on language design. Apart from taking issue with types and structures being merged into a single concept, and with the lack of constructs such as conditional expressions, the exponentiation operator, and local blocks, which were all present in ALGOL 60, he reproached Pascal for retaining the much-cursed goto statement [Habermann 1973]. In hindsight, one cannot but agree; at the time, its absence would have deterred too many people from trying to use Pascal. The bold step of proposing a goto-less language was taken ten years later by Pascal's successor Modula-2, which remedied many shortcomings and eliminated several remaining compatibility concessions to ALGOL 60, particularly with regard to syntax [Wirth 1982]. A detailed and well-judged reply to the critique by Habermann was written by Lecarme, who judged the merits and deficiencies on the basis of his experience with Pascal in both teaching and compiler design
PASCAL SESSION
103
NIKLAUS WIRTH
[Lecarme 1975]. Another significant critique [Welsh 1977] discusses the issue of structural versus name equivalence of data types, a distinction that had unfortunately been left open in the definition of Pascal. It caused many debates un.til it was resolved by the standards committee. Perhaps the single most unfortunate construct was the variant record. It was provided for the purpose of constructing nonhomogeneous data structures. Both for array and for dynamic structures in Pascal, the element types must be fixed by type declarations. The variant record allows variations of the element types. The unfortunate aspect of the variant record of Pascal stems from the fact that it provides more flexibility than required to achieve this legitimate goal. In a dynamic structure, typically every element remains of the same type as defined by its creation. The variant record, however, allows more than the construction of heterogeneous structures, that is, of structures with elements of different, although related types. It allows the type of elements themselves to change at any time. This additional flexibility has the regrettable property of requiring type checking at run-time for each access to such a variable or to one of its components. Most implementors of Pascal decided that this checking would be too expensive, enlarging code and deteriorating program efficiency. As a consequence, the variant record became a favorite feature to breach the type system by all programmers in love with t~ricks, which usually turn into pitfalls and calamities. Variant records also became a major hindrance ~tothe notion of portability of programs. Consider, for example, the declaration V A R R:
RECORD maxspeed: INTEGER; C A S E v: V e h i c l e O F truck: (nofwheels : INTEGER) ; vessel: ( h o m e p o r t : S t r i n g ) END
Here, the designator R.nofwheels is applicable only ifR.v has the value truck, and R.homeport only if R.v = vessel. No compiler checks can safeguard against erroneous use of designators, which, in the case of assig~nment, may be disastrous, because the variant facility is used by implementations to save storage by overlaying the fields nofwheels and homeport. With regard to input and output operations, Pascal separated the notions of data transfer (to or from an external medium) and of representation conversion (binary to decimal and vice versa). External, legible media were to be represented as files (sequences) of characters. Representation conversion was expressed by special read and write statements that have the appearance of procedures but allowed a variable number ~,f parameters. Whereas the latter was essentially a concession to programmers used to FORTRAN's I/O statements, the notion of sequence as a structural form was fundamental. Perhaps also in this case, providing sequences of any (even programmer-defined) element types was more than what was genuinely needed in practice. The consequence was that, in contrast to all other data types, files require a cert~in amount of support from built-in run-time routines, mechanisms not explicitly visible from the pro gram text. The successors of Pascal--Mod ula-2 and Oberon--later retreated from the notion of the file as a structural form at the same level as array and record. This became possible, because implemenl~ations of sequencing mechanisms could be provided through modules (library packages). In Pascal, however, the notion of modules was not yet present; Pascal programs were to be regarded as single, monolithic texts. This view may be acceptable for teaching purposes where exercises are reasonably compact, but it is not tenable for the construction of large systems. Nevertheless and surprisingly, Pascal compilers could be written as single Pascal programs.
104
CHAPTER III
PAPER: RECOLLECTIONS ABOUT THE DEVELOPMENT OF PASCAL
3.3
LATER DEVELOPMENTS
Even though Pascal appeared to fulfill our expectations in regard to teaching, the compiler still failed to satisfy the stated goals with regard to efficiency in two aspects: First, the compiler as a relatively large stand-alone program resulted in fairly long "turn-around times" for students. In order to alleviate the problem, I designed a subset of the language containing those features that we believed were to be covered in introductory courses, and a compiler/interpreter package that fitted into a 16K-word block of store, which fell under the most-favored program status of the computation center. The Pascal S package was published in a report, and was one of the early comprehensive systems made widely available in source form [Wirth 1981]. Comparable FORTRAN programs were still substantially faster, an undeniable argument in the hands of the Pascal adversaries. As we were of the opinion that structured programming, supported by a structured language and efficiency of compilation and of produced code were not necessarily mutually exclusive, a project for a third compiler was launched, which on the one hand was to demonstrate the advantage of structured top-down design with step-wise refinement [Ammann 1974], and on the other hand was to pay attention to generating high-quality code. This compiler was written by U. Ammann and achieved both goals quite admirably. It was completed in 1976 [Ammann 1977]. Although the result was a sophisticated compiler of high quality and reliability, in hindsight we must honestly confess that the effort invested was not commensurate with its effect. It did not win over many engineers and even fewer physicists. The argument that FORTRAN programs "ran faster" was simply replaced by "our programs are written in FORTRAN." And what authorizes us to teach structured, "better" programming to experts of ten years' standing? Also, the code was generated for the CDC 6000 computer which--with its 60-bit word and super-RISC structure--was simply not well suited for the task. Much of Ammann's efforts went into implementing the attribute packet of records. Although semantically irrelevant, it was requested by considerations of storage economy on a computer with very long words. Having had the freedom to design not only the language but also the computer would have simplified the project considerably. In any event, the spread of Pascal came from another front. Not long after the publication of the Pascal definition, we received correspondence indicating interest in that language and requesting assistance in compiler construction, mainly from people who were not users of CDC computers. It was this stimulus that encouraged me to design a suitable computer architecture. A version of Ammann's compiler---easily derived from an early stage of the sequence of refinements--would generate code for this "ideal" architecture, which was described in the form of a Pascal program representing an interpreter. In 1973, the architecture became known as the P-machine, the code as P-code, and the compiler as the P-compiler. The P-kit consisted of the compiler in P-code and the interpreter as a Pascal source program [Nori 1981]. Recipients could restrict their labor to coding the interpreter in their favorite assembler code, or proceed to modify the source of the P-compiler and replace its code-generating routines. This P-system turned out to be the key to Pascal's spread onto many computers, but the reluctance of many to proceed beyond the interpretive scheme also gave rise to Pascal's classification as a "slow language," restricted to use in teaching. Among the recipients of the P-kit was the team ofK. Bowles at the University of California at San Diego (UCSD) around 1975. He had the foresight to see that a Pascal compiler for an interpretive system might well fit into the memory of a microcomputer, and he mustered the courage to try. Moreover, the idea of P-code made it easy to port Pascal to a whole family of micros and to provide
PASCAL SESSION
105
NIKLAUS WIRTH
a common basis o~h all of them for teaching. Microcomputers had just started to emerge, using early microprocessors such as Intel's 8080, DEC's LSI-11, and Rockwell's 6502; in Europe, they were hardly known at the time. Bowles not only ported our compiler. His team built an entire system around the compiler, including a program editor, a file system, and a debugger, thereby reducing the time needed for an edit-compile-test step dramatically over any other system in educational use. Starting in 1978, this UCSD-Pascal system spread Pascal very rapidly to a growing number of users [Bowles 1980; Clark 1982]. It won more "Pascal friends" in a year than the systems used on large "mainframes" had won in the previous decade. This phenomenal success had three sources: (1) a high-level language, which would pervade educational institutions, was available on microcomputers; (2) Pascal became supported by an integrated system instead of a "stand-alone" compiler; and (3), perhaps most importantly, Pascal was offered to a large number of computer novices, that is, people who were not burdened by previous programming habits. In order to adopt Pascal, they did not have to give up a large previous investment in learning all the idiosyncracies of assembler or FORTRAN coding. The microcomputer made programming a public activity, hitherto exclusively reserved to the high priests of computing centers, and Pascal effectively beat FORTRAN on microcomputers. By 1978, there existed over 80 distinct Pascal implementations on hosts ranging from the Inte18080 microprocessor to the Cray- 1 supercomputer. But Pascal's usefulness was not restricted to educational institutions; by 1980, all four major manufacturers of workstations (Three Rivers, HP, Apollo, Tektronix) were using Pascal for system programming. Besides being the major agent for the spread of Pascal implementations, the P-system was significant in demonstrating how comprehensible, portable, and reliable a compiler and system program could be made. Many programmers learned a great deal from the P-system, including implementors who did not base their work on the P-system, and others who had never before been able to study a compiler in detail. The fact that a compiler was available in source form caused the P-system to become an influential vehicle of extracurricular education. Several years earlier, attempts had been made to transport the Pascal compiler to other mainframe computers. In these projects no interpreter or intermediate code was used; instead they required the design of new generators of native code. The first of these projects was also the most successful. It was undertaken by I. Welsh and C. Quinn from Queen's University, Belfast [Welsh 1972]. The target was the ICL 1900 computer. The project deserves special mention, because it should be considered as one of the earliest, genuinely successful ventures that were later to be called software engineering efforts. As no CDC cornputer was available at Belfast, the goal was to employ a method that required as little work on a CDC machine as possible. What remained unavoidable would be performed during a short visit to ETH in Zurich. Welsh and Quinn modified the CDC-Pascal compiler, written in Pascal, by replacing all statements affecting code generation. In addition, they wrote a loader and an interpreter of the ICL architecture, allowing some tests to be performed on the CDC computer. All these components were programmed before the crucial visit, and were completed without any possibility of testing. In Zurich, the programs were compiled and a few minor errors were corrected within a week. Back in Belfast, the generated compiler code was executable directly by the ICL-machine after correction of a single remaining error. This achievement was due to a very careful programming and checking effort, and it substantiated the claimed advantages to be gained by programming in a high-level language such as Pascal, which provides full, static type checking. The feat was even more remarkable, because more than half of the week had to be spent on finding a way to read the programs brought from Belfast. Aware of the incompatibilities of character sets and tape formats of the two machines (seven- versus nine-track 106
CHAPTER III
PAPER: RECOLLECTIONSABOUT THE DEVELOPMENTOF PASCAL
tapes), Welsh and Quinn decided to use punched cards as the data carrier. Yet, the obstacles encountered were probably no less formidable. It turned out to be a tricky, if not downright impossible, task to read cards punched by an ICL machine with the CDC reader. Not only did the machines use different sets of characters and different encodings, but certain hole combinations were interpreted directly by the reader as end of records. The manufacturers had done their utmost best to ensure incompatibility! Apart from these perils, the travelers had failed to reckon with the thoroughness of the Swiss customs officers. The two boxes filled with some four thousand cards surely had to arouse their deep suspicion, particularly because these cards contained empty cubicles irregularly spaced by punched holes. Nevertheless, after assurances that these valuable possessions were to be reexported anyway, the two might-be smugglers were allowed to proceed to perform their mission. Upon their return, the fact that now the holes were differently positioned luckily went unnoticed. Other efforts to port the compiler followed; among them were those for the IBM 360 computers at Grenoble, the PDP-11 at Twente [Bron 1976], and the PDP-10 at Hamburg [Grosse-Lindemann 1976]. By 1973, Pascal had started to become more widely known and was being used in classrooms as well as for smaller software projects. An essential prerequisite for such acceptance was the availability of a user manual including tutorial material in addition to the language definition. Kathy Jensen embarked on providing the tutorial part, and by 1973 the booklet was published by Springer-Verlag, first in their Lecture Notes Series, and, after selling very quickly, as an issue on its own [Jensen 1974]. It was soon to be accompanied by a growing number of introductory textbooks from authors from many countries. The User Manual itself was later to be translated into many different languages, and it became a bestseller. A dedicated group of Pascal fans was located at the University of Minnesota's computer center. Under the leadership and with the enthusiasm of Andy Mickel, a Pascal Users' Group (PUG) was formed, whose vehicle of communication was the Pascal Newsletter, at first edited by G. H. Richmond (University of Colorado) and later by Mickel. The first issue appeared in January 1974. It served as a bulletin board for new Pascal implementations, for new experiences and---of course--for ideas of improving and extending the language. Its most important contribution consisted in tracking all the emerging implementations. This helped both consumers to find compilers for their computers and implementors to coordinate their efforts. At ETH Zurich, we had decided to move on towards other projects and to discontinue distribution of the compiler, and the Minnesota group was ready to take over its maintenance and distribution. Maintenance here refers to adaptation to continually changing operating system versions, as well as to the advent of the Pascal standard. Around 1977, a committee had been formed to define a standard. At the Southampton conference on Pascal, A. M. Addyman asked for help in forming a standards committee under the British Standards Institute (BSI). In 1978, representatives from industry met at a conference in San Diego hosted by K. Bowles to define a number of extensions to Pascal. This hastened the formation of a standards committee under the wings of IEEE and ANSI/X3. The formation of a Working Group within ISO followed in late 1979, and finally the IEEE and ANSI/X3 committees were merged into the single Joint Pascal Committee. Significant conflicts arose between the U.S. committee and the British and ISO committees, particularly over the issue of conformant array parameters (dynamic arrays). The latter became the major difference between the original Pascal and the one adopted by ISO, the other being the requirement of complete parameter specifications for parametric procedures and functions. The conflict on the issue of dynamic arrays eventually led to a difference between the standards adopted by ANSI on one hand, and BSI and ISO on the other. The unextended standard was adopted by IEEE PASCAL SESSION
107
NIKLAUS WIRTH
in 1981 and by ANSI in 1982 [Cooper 1983; Ledgard 1984]. The differing standard was published by BSI in 1982 and approved by ISO in 1983 [ISO 1983; Jensen 1991]. In the meantime, several companies had implemented Pascal and added their own, supposedly indispensable extensions. The standard was to bring them back under a single umbrella. If anything might have had a chance to make this dream come true, it would have been the speedy action of declaring the original language as the standard, perhaps with the addition of a few clarifications about obscure points. Instead, several members of the group had fallen prey to the devil's temptations: They extended the language with their own favorite features. Most of these features I had already contemplated in the original design, but dropped either because of difficulties in clear definition or efficient implementation, or because of questionable benefit to the programmer [Wirth 1975]. As a result, long debates started, requiring many meetings. When the committee finally submitted a document, the language had almost found its way back to the original Pascal. However, a decade had elapsed since publiication of the report, during which individuals and companies had produced and distributed compilers; and they were not keen to modify them in order to comply with the late standard, and even less keen to give up their own extensions. An implementation of the standard was later published in Welsh [1986]. Even before publication of the standard, however, a validation suite of programs was established and played a signi~icant role in promoting compatibility across various implementations [Wichmann, 1983]. Its role even increased after the adoption of the standard, and in the United States it made a Federal Information Processing Standard for Pascal possible. The early 1970s were the time when, in the aftermath of spectacular failures of large projects, terms such as structured programming and software engineering were coined. They acted as symbols of hope for the drownling, and too often were believed to be panaceas for all the troubles of the past. This trend further raised interest in Pascal, which--after all--was exhibiting a lucid structure and had been strongly influenced by E. W. Dijkstra's teachings on structured design. The 1970s were also the years when, in the same vein, it was believed that formal development of correctness proofs for programs was the ultimate goal. C. A. R. Hoare had postulated axioms and rules of inference about programming notations (it later l~ecame known as Hoare-logic). He and I undertook the task of defining Pascal's semantics formally using this logic. However, we had to concede that a number of features had to be omitted from the formal definition (e.g., pointers) [Hoare 1973]. Pascal thereafter served as a vehicle for the realization of program validators in at least two places-namely, Stanford University and ETH Zurich. E. Marmier had augmented the compiler to accept assertions (in the form of marked comments) of relations among a program's variables holding after (or before) executable statements. The task of the assertion checker was to verify or refute the consistency of assertions and statements according to Hoare-logic [Marmier, 1975]. His was one of the earliest endeavors in this direction. Although it was able to establish correctness for various reasonably simple programs, its main contribution was to dispel the simple-minded belief that everything can be automated. Pascal exerted a strong influence on the field of language design. It acted as a catalyst for new ideas and as a vehicle to experiment with them, and in this capacity gave rise to several successor languages. Perhaps the first was E Brinch Hansen's Concurrent Pascal [Brinch Hansen 1975]. It embedded the concepts of concu~rrent processes and synchronization primitives within the sequential language Pascal. A similar goal, but with emphasis on simulation of discrete event systems based on (quasi-) concurrent processes, led to Pascal-Plus, developed by J. Welsh and J. Elder at Belfast [Welsh 1984]. A considerably larger language was the result of an ambitious project by Lampson et al., whose goal was to cover all the needs of modern, large-scale software engineering. Although deviating in many
108
CHAPTER lU
PAPER: RECOLLECTIONSABOUT THE DEVELOPMENTOF PASCAL
details and also in syntax, this language, Mesa, had Pascal as its ancestor [Mitchell 1978]. It added the revolutionary concept of modules with import and export relationships, that is, of information hiding. Its compiler introduced the notion of separate--as distinct from independent---compilation of modules or packages. This idea was adopted later in Modula-2 [Wirth 1982], a language that in contrast to Mesa retained the principles of simplicity, economy of concepts, and compactness that had led Pascal to success. Another derivative of Pascal is the language Euclid [London 1978]. The definition of its semantics is based on a formalism, just as the syntax of ALGOL 60 had been defined by the formalism BNF. Euclid carefully omits features that were not formally definable. Object Pascal is an extension of Pascal incorporating the notion of object-oriented programming, that is, of the abstract data type binding data and operators together [Tesler 1985]. And last but not least, the language Ada [Barnes 1980] must be mentioned. Its design was started in 1977 and was distinctly influenced by Pascal. It lacked, however, an economy of design without which definitions became cumbersome and implementations monstrous.
3.4
IN RETROSPECT
I have been encouraged to state my assessment of the merits and weaknesses of Pascal, of the mistaken decisions in its design, and of its prospects and place in the future. I prefer not to do so explicitly, and instead to refer the reader to my own successive designs, the languages Modula-2 [Wirth 1982] and Oberon [Wirth 1988]. Had I named them Pascal-2 and Pascal-3 instead, the questions might not have been asked, because the evolutionary line of these languages would have been evident. It is also fruitless to question and debate early design decisions; better solutions are often quite obvious in hindsight. Perhaps the most important point was that someone did make decisions, in spite of uncertainties. Basically, the principle to include features that were well understood, in particular by implementors, and to leave out those that were still untried and unimplemented, proved to be the most successful single guideline. The second important principle was to publish the language definition after a complete implementation had been established. Publication of work done is always more valuable than publication of work planned. Although Pascal had no support from industry, professional societies, or government agencies, it became widely used. The important reason for this success was that many people capable of recognizing its potential actively engaged themselves in its promotion. As crucial as the existence of good implementation is the availability of documentation. The conciseness of the original report made it attractive for many teachers to expand it into valuable textbooks. Innumerable books appeared in many languages between 1977 and 1985, effectively promoting Pascal to become the most widespread language used in introductory programming courses, Good course material and implementations are the indispensable prerequisites for such an evolution. Pascal is still widely used in teaching at the time of this writing. It may appear that it undergoes the same fate as FORTRAN, standing in the way of progress. A more benevolent view assigns Pascal the role of paving the way for successors.
ACKNOWLEDGMENTS I heartily thank the many contributors whose work played an indispensable role in making the Pascal effort a success, and who thereby directly or indirectly helped to advance the discipline of program design. Particular thanks go to C. A. R. Hoare for providing many enlightening ideas that flowed into Pascal's design; to U. Ammann, E. Marmier, and R. Schild for their valiant efforts to create an effective and robust compiler; to A. PASCAL SESSION
109
NIKLAUSWIRTH
Mickel and his crew for their enthusiasm and untinng engagement in making Pascal widely known by establishing a user group and a newsletter; and to K. Bowles for recognizing that our Pascal compiler was also suitable for microcomputers and for acting on this insight. I also thank the innumerable authors of textbooks, without whose introductory texts F'ascal could not have received the acceptance that it did.
REFERENCES [Ammann, 1974] Ammann, U., The Method of Structured Programming Applied to the Development of a Compiler, in International Computing Symposium 1973, Amsterdam: North-Holland, 1974, pp. 93--99. [Ammann, 1977] Ammann, U., On Code Generation in a Pascal Compiler, Software--Practice and Experience, Vol. 7, 1977, pp. 391--423. [Barnes, 1980] Barnes,, An Overwiew of Ada, Software--Practice and Experience, Vol. 10, 1980, pp. 851-887. [Bowles, 1980] Bowlcs, K. L., Problem Solving Using Pascal. Spdnger-Verlag, 1977. [Brinch Hansen, 1975] Brinch Hansen, E, The Programming Language Concurrent Pascal, IEEE Transactions on Software Engineering, Vol. 1, No. 2, 1975, pp. 199-207. [Bron, 1976] Bron, C., and W. de Vries, A Pascal Compiler for the PDP- 11 Minicomputers, Software--Practice and Experience, Vol. 6, 1976, pp. 109-116. [Clark, 1982] Clark, 1~., and S. Koehler, The UCSD Pascal Handbook, Englewood Cliffs, NJ: Prentice-Hall, 1982. [Cooper, 1983] Cooper, D., Standard Pascal User ReJ~rence Manual Norton, 1983. [Dijkstra, 1966] Dijkstra, E. W., Structured Programming, Technical Report, University of Eindhoven, 1966. Also in Dahl, O.-J. et al,. Structured Programming, London: Academic Press, 1972. [Grosse-Lindemann, 11976] Grosse-Lindemann, C. O., and H. H. Nagel, Postlude to a Pascal-Compiler Bootstrap on a DECSystem-10, Software--Practice and Experience, Vol. 6, 1976, pp. 29---42. [Habermann, 1973] Habermann, A. N., Critical Comments on the Programming Language Pascal, Acta Infi~rmatica Vol. 3, 1973, pp. 47-57. [Hoare, 1972] Hoare, C. A. R., Notes on Data Structuring, in Dahl, O.-J. et aL, Structured Programming, London: Academic Press, 1972. [Hoare, 1973] Hoare, C. A. R. and N. Wirth, An Axiomatic Definition of the Programming Language Pascal, Acta Informatica, Voi. 2, 1973, pp. 335-355. [Hoare, 1980] Hoare, C. A. R., The Emperor's Old Clothes. Communications ~gf'theACM, Vol. 24, No. 2, Feb. 1980, pp. 75-83. [ISO, 1983] lntematiolaal Organization for Standardization, Specification for Computer Programming Language Pascal, ISO 7185, 1982. [Jensen, 1974] Jensen, K., and N. Wirth, Pascal--User Manual and Report, Springer-Vedag, 1974. [Jensen, 1991] Jensen, K., and N. Wirth, revised by A. B. Mickel and J. E Miner, Pascal--User Manualand Report, ISO Pascal Standard, Springer-Verlag, 1991. [Lecarme, 1975] Lecarme, O., and P. Desjardins, More Comments on the Programming Language Pascal, Acta lnfiJrmatica, Vol. 4, 1975, pp. 231-243. [Ledgard, 1984] Ledg~xd, H., The American Pascal Standard, Springer-Verlag, 1984. [London, 1978] London, R. L., J. V. Guttag, J. J. Homing, B. W. Lampson, J. G. Mitchell, and G. J. Popek, Proof Rules for the Programming Language Euclid, Acta Informatica, Vol. i 0, 1978, pp. i-26. [Marmier, 1975] Marmier, E., Automatic Verification t~fPascal Prograrg¢, ETH Dissertation No. 5629, Zurich, 1975. [Mitchell, 1978] Mitchell, J. G., W. Maybury, R. Sweet, Mesa Language Manual, Xerox PARC Report CSL-78-1, 1978. [Nanr, 1963] Naur, P., Ed., Revised Report on the Algorithmic Language ALGOL 60, Communications of the ACM, Vol. 3, 1960, pp. 299-316; Communications t~fthe ACM, Vol. 6, 1963, pp. 1-17. [Nori, 1981] Nod, K.V. et al., The Pascal P-code Compiler: Implementation Notes, in Pascal--The Language and Its Implementation. D.W. Barton, ed., New York: John Wiley & Sons, 1981. [Tesler, 1985] Tesler, L., Object Pascal Report,. Structured Programming (formerly Structured Language World), Vol. 9, No. 3, 1985, pp. 10-14. [van Wijngaarden, 196!)] van Wijngaarden, A., Ed., Report on the Algorithmic Language ALGOL 68, Numer. Math. Vol. 14, 1969, pp, 79-2]8. [Welsh, 1972] Welsh, J., and C. Quinn, A Pascal Compiler for ICL 1900 Series Computers, Software--Practice and Experience, Vol. 2, 1972, pp. 73-77. [Welsh, 1977] Welsh, J., W. J. Snecringer, and C. A. R. Hoar¢, Ambiguities and Insecurities in Pascal, SoJhvare--Practice and Experience, Vol. 7, 1977, pp. 685--696. Also in D. W. Barron, Ed., Pascal--The Language and its Implementation, New York: John Wiley & Sons, 1981.
110
CHAPTER III
TRANSCRIPTOF DISSCUSSANT'S REMARKS [Welsh, 1984] Welsh, J., and D. Bustard, SequentialProgram Structures, EnglewoodCliffs, NJ: Prentice-Hall, 1984. [Welsh, 1986]Welsh,J., and A. Hay,A Model Implementationof Standard Pascal. EnglewoodCliffs, NJ: Prentice-Hall, 1986. [Wichmann, 1983]Wichmann,B., and Ciechanowicz,Pascal Compiler Validation, New York:John Wiley& Sons, 1983. [Wirth, 1966] Wirth, N. and C. A. R. Hoare, A Contribution to the Developmentof ALGOL, Comraunications t~fthe ACM, Voi. 9, No. 6, June 1966, pp. 413---432. [Wirth, 1970]Wirth, N., The Programming Language Pascal,TechicalReport 1, FachgruppeComputer-Wissenschaften,ETH, Nov. 1970;Acta lnformatica, Vol. 1,1971, pp. 35.--63. [Wirth, 1971a] Wirth, N., Program Developmentby Step-wise Refinement, Commnications of the ACM, Vol. 14, No. 4, Apr. 1977, pp. 221-227. [Wirth, 197l b] Wirth, N., The Design of a Pascal Compiler,Sofftware--Practiceand Experience, Vol. 1,1971, pp. 309-333. [Wirth, 1975]Wirth, N. An assessment of the programminglanguagePascal.IEEE Transactions on SoftwareEngineering,Vol. 1, No. 2, June 1975,pp. 192-198. [Wirth, 1981]Wirth, N., Pascal-S:A Subsetand its Implementation,in Pascal--The Language and its Implementation, D. W. Barton, FEd.,New York:John Wiley& Sons, 1981. [Wirth, 1982] Wirth, N., Programming in Modula-2, Springer-Verlag, 1982. [Wirth, 1988] Wirth, N., The ProgrammingLanguageOberon, Stortware--Practiceand Experience, Vol. 18, No. 7, July 1988, pp. 671-690.
TRANSCRIPT OF PRESENTATION Editor's note: Niklaus Wirth 's presentation close/y followed his paper and we have omitted it with his permission.
TRANSCRIPT OF DISSCUSSANT'S REMARKS SESSION CHAIR JACQUES COHEN: The discussant is Andy Mickel, who is the Computer Center Director at the Minneapolis College of Art and Design. Prior to his current position, he worked for ten years at the University of Minnesota Computer Center, where he managed the language processor's group supporting micros through CDC and VAX mainframes, up to the Cray-1. He cofounded the Pascal Users Group at ACM '75, and assumed editorship of the Pascal Newsletter in the summer of 1976. Through 1979, he coordinated the Users Group and edited the quarterly, Pascal News. Beginning with the Southampton Pascal Conference in 1977, he facilitated the international effort to standardize and promote the use of Pascal. After the standard was complete in 1983, he and his colleague, Jim Miner, revised the popular tutorial, Pascal User Manual and Report, in a third edition to conform to the standard. From 1983 to 1989, he worked at Apollo Computer, where in 1986 he led the project to develop the first commercial, two-pass Modula-2 compiler. ANDREW B. MIKEL: My talk is on the origins of the Pascal Users Group and its effect on the use and dissemination of Pascal. I was introduced to programming languages by Daniel Friedman (who is here today), in my senior year at the University of Texas at Austin, 1971. He taught me language definition and programming language semantics. I went on to grad school at the University of Minnesota, where I got a job at the Computer Center and became interested in promoting the use of good, practical, general-purpose programming languages, but we had a Control Data machine. And that was a good thing, but along came Pascal and my efforts to promote it were met with resistance from FORTRAN users and other skeptics. So, my goal became to make the world safe for a language, that I, a nonguru, mortal programmer enjoyed using. (SLIDE l) I have a slide here where I have listed the sort of situation we found ourselves in 1970. Even though there were some Pascal compilers coming into use, there was a reluctance, particularly by American computer science departments, to teach Pascal. Along came George Richmond, from the University of Colorado, who started the Pascal Newsletter and created some momentum in our
PASCAL SESSION
111
ANDREW B. MIKEL
Origins: Pascal User's Group A. Situation, 1972, first compilers widespread. B. 1972-1976 reludanca by CS Depts to teach Pascal. C. Early 1975--good rsomentum--3 newslstters]l 3 months. D. Eady 1976--Io¢ing momentum. 1. Habermann'== spiteful article touted as truth. 2. No newsletters for over a year. 3. Pascal-P4 compiler writers duplicating efforts.
SLIDE
I!
Ex::>. 9 : 5 0
1
SLIDE 2
eyes by producing three newsletters in 13 months. But, then the newsletters stopped and people were quoting Habermann's article as if they had read it and had not studied Pascal. A lot of people using Pascal-P4 to build compilers were duplicating each others' efforts. (SLIDE 2) We have a photocopy of the original sign used by Richard Cichelli at ACM '75 in Minneapolis, announcing a Pascal Users Group. I had never heard of this before. But I went. Bob Johnson, his friend from Saint Cloud State (Richard was from Lehigh University), Charles Fischer and Richard LeBhmc (who is here) from the University of Wisconsin, and 31 other people showed up in a hotel room. We talked about what to do. A lot of us were pretty angry. (SLIDE 3) We formed a strategy. We decided to follow William Waite's advice in the Software--Practice atd Experience article editorial about programming languages as organisms in an ecosystem. And if FORTRAN was a tough weed, we needed to grow a successful competing organism and starve FORTRAN at the roots. So we talked about forming little clubs like Society to Help Abolish FORTRAN Teaching (that's SHAFT), or the American COBOL Society "dedicated to the elimination of COBOL in our ]lifetime" (like the American Cancer Society). I was fresh from working at George McGovern's political campaign and you have to remember that the early seventies was the era of Watergate and the truth, integrity and full disclosure. So, in 1976, I decided to pro-actively mail directly to every college with a math department a notice that we had a Pascal Users Group. We rapidly built a large mailing list. We used the newsletter as a means to organize this whole activity. It was
Origins: Pascal User's Group ......... ..:::: ; A. Solution: Follow winiam Waite's ecosystem analogy. B. Found S.H.A.F.T and A.C.S. C. Use political-organizing skills developed in McGovern's campaign. D. Organize and nelwork supports via stronger Newsletter, E. Add structure to I=PascalNewsletter: 1. Here and There with Pascal (includes roster). 2. Open Fomm/Adicles/Implementation Notes.
SLIDE 3
112
~rd.
f
pr eat, nal ~o P. C/. G,
SLIDE
4
CHAPTER III
T R A N S C R I P T O F DISSCUSSANT'S R E M A R K S
much like the language supplements to SIGPLAN Notices. The average size was 150 pages. (SLIDE 4) We didn't take ourselves too seriously. Here is what the guardian of rational programming, the PUG mascot looked like. It is sort of a weakling looking dog, a pug dog. (SLIDE 5) We started getting things back on track. We had an aggressive attitude. In the 90s we would say we were a User Group with "an attitude." We indulged in self-fulfilling prophesies. We tried to make it look like there was a lot going on around Pascal by publishing everything that we could find on it. And lo and behold, there was a lot going on with Pascal because some of the neutral bystanders became less afraid and started joining in. David Barron in Southampton scheduled the first Pascal Conference. One hundred and forty people attended. At that conference, Tony Addyman teased people with the idea of starting a formal standards effort. That was the beginning of standards, which took place in Europe, something a little different from what most American computer manufacturers were used to. Some of the early influences at that time were Wilhelm Burger at the University of Texas at Austin; John Strait, Jim Miner, and John Easton at Minnesota; Judy Bishop with David Barron at Southampton; Arthur H. J. Sale at the University of Tasmania in Australia; and Helmet Weber at the Bavarian University of Munich. (SLIDE 6) This is an sample cover of Pascal News, which sort of illustrates its use of a selforganizing tool. The newsletters contain information about users, compilers, standards, vendors, applications, teaching, textbooks, and even the roster of all the members. My plan was if my Computer Center jerked the support out from under me, anybody could pick up the User Group and keep going. (SLIDE 7) So, we were finally on a roll. The American committee starts, we get them cooperating without trying to dominate the standards process--we argued that it was a European Language being standardized by Europeans. We derailed the UCSD conference and "extensionswith-Pascal" people. The people at UCSD (the PASCAL SESSION
PUG
Effects
A. Newsletters:July 76, Sept 76, Nov 76. B. a la 90's: "a user group with an Attitudsf" C. Roberto Minio at Springer. lower pdce of PUM&R. D. Start standards effort withoutthe powerful vendors. E. Create self-fulfillingprophesyof explosionof activity. F. SouthhamptonConference, Feb 77, 140 people. G. Tony Addyman, U of Manchester,UK, BSI Standsrds.
SLIDE
5
JUNE
; i ? " "~:.I. : ~ . L P U ~ [ . C , ~ ' :a [~l~'s~n~l~]~
•
4
:
, .
-
"
-
ttf t [ ,tim ' ~ E ~ tlz ~ tJ~c,'u.:
& ,7 • 9 • " II Iz
, "~
• . ,
t~lCklEl~]|$ht (r~ltl~t~ft"~BchpIl~l I d ~ e t l ' ~ Itt,l ~ r
ti,ld A r t i c l e s
•
l~¢rment
~
: .
•
~.2'~"~-,.
SLIDE
..,~!!fll
P
6
113
ANDREW B. MIKEL
PUG Effects •' ~........... A. U of Colorado, Boulder, ANSI/IEEE (JPC) Apt 78. B. UCSD Confer~ee on Extension, July 78. C. PascalNewsls~;ues: Feb, May, Sep 77: circ. 1500. D. Move to canonical compiler development 1. Tracking 84 different Implementations. 2. From Intel 80,130to Cray-1. E. Develop Suite of Software Toole/Valldatlon Suite. F. Develop Subprogram Libraries and Applications.
SLIDE 7
SLIDE 8
114
....
bad guys) were confusing the language definition with its implementation. Circulation of Pascal News increased. We also sorted out a lot of duplicated efforts among the PDP-11 and IBM 370 implementations: There were 20 different compiler efforts. That is not counted in the total of 84; that is just the ones that weren't canonical. There was a lot of software written in Pascal becoming available. (SLIDE 8) Then all hell broke loose. This article appeared in ComputerWorld in Apnl 1978 and down here it says, "You can join the two thousand members of the Pascal Underground by sending four dollars to the Pascal Users Group." My mail went from 15 pieces a day to 80-something pieces a day. (SLIDE 9) This is a picture of me up against a wall pasted with copies of all the articles on Pascal out of the industry journals. (SLIDE 10) This is sample of what kind of coverage we were starting to get in the industry press in 1978: ComputerWorld, Byte, Electron-
ics Magazine, IEEE Computer, and Datamation. By the next year, our circulation was up to 4,600 in 43 countries. (SLIDE 11) So we were riding high. Arthur Sale produced a little cartoon, "Pascal Riding on the Microwave." (SLIDE 12) From an American point of view, industry led over academia, and here are some of the projects. A lot of them were internal to the companies over here that nobody really knew about. It was only in 1981, that the commercial versions of UCSD Pascal started to appear. I want to point out that Three Rivers PERQ, Tektronix, and the Hewlett-Packard 9000 are workstations. (SLIDE 13) This may be controversial, too. It may be fortuitous that the first compiler was on Control Data equipment because at that time in the seventies, CDC had a disproportionately large instal led base at universities. For example, the size of the student body at Minnesota was 55,000, at UT Austin it was 40,000, 45,000 at UC Berkeley, and all had Control Data equip-
CHAPTER III
TRANSCRIPT OF DISSCUSSANT'S REMARKS
PUG E f f e c t s - Press A. Industn] Press articles. 1. ComputerWorld, page 24, 1 page, April, 1978. 2. Byte: cover =on], August, 1978. 3. Electronics: cover mention, October, 1978. 4. IEEE Computer: cover mention, Apdl, 1979. 5. Datamation: cover mention, July 1979. B. Pascal News: Jan, Sap, Oct 79: clrc 4600 In 43 countries.
SLIDE
9
PASCAL
SLIDE
10
PUG Effects - I n d u s t r y o v e r A c a d e m e
-R m.G.o. "r.E M, oWAvE A. Control Data 1700, 1975. B. Texas Instruments, ASC, 990 and 9900, 1976. C. Control Data/NCR Joint Project, 1979. D. Three Rivers PERQ, 1978. E. Tektronix, 1978. F. Apollo DOMAIN, 1980. G. Apple Apple ][, 1981. H. Hewlatt Packard 9000, 1981.
SLIDE
11
SLIDE
12
F.ruquea~f ef Use ~ Mosl Popular Lualfuu/e ]Pro~eauors
PUG Effects - I n d u s t r y o v e r A c a d e m e A. CDC 6000/7000/Cyber sites at large universities in USA. 1. U of Minnesota, 55,000. z. U of Texas at Austin, 40,000. 3. U of California, Berkeley, 35,000. B. Last to teach Pascal. 1. M.I.T. 2. Stanford U. 3. Camegle-Mstlon U.
SLIDE
PASCAL SESSION
13
SLIDE
14
115
A N D R E W B, M I K E L
Does Not Compute
PUG Accomplishments nl .....
~
=
I think, Brian, you'd be of grt,ntter service, tit least f(Ir a while, bussing lables, eating crayfish, anything bul reviewing film & people in so many wolds, I see the outline:
:~:
A. No bureaucracy, simply vast bulletin board. S. Pascal News ga~veharmless outlet to frustrated designers. C. Rick Shaw, Mar~May/Sep/Dec, 80; Apr/Sep, 81, Oct 82. D. Chadie Gaffney, JardApr/Jul/Nov 83. E. Users organizecl before standards process began. R Portable Soffwa4re Tools, Validation Suite. G. In 1980's Pascall used to teach programming at U's.
SLIDE
ProcedureLamhenWdte; I~gln ConlnctmeFocal Point(film/person) vs. Industry; 'a dlstressthgly pinstdped bntlontlow~ Industry' ReadYeat'bo(~; 'l~tfing through the yeattxx~' AddAdJe,clives; 'disuessillgly I~nslrlped' "fiscleallng trivia bits' 'tb~,.:cp41velytmimlx~ing'
( klielallze;'It ismy experiencethaim o s t legelmls10re anticlimax in pt'fson. It is their ~'¢alkms which reflect gicalllP.~,' Print; 'End; (* of Procedure LamberlWd¢*)
15
SLIDE
16
ment exceeding those small, more elite schools. I was chagrined that the last universities in the United States to use Pascal as a teaching language were MIT, Stanford, and Carnegie Mellon. (SLIDE 14) Thiis is an example of the usage at the University of Minnesota and of the number of compilations by language from 1974 to 1983. If we just take 1975 as a baseline, there were 900,000 FORTRAN compilations to 100,000 to Pascal. And by 1983, it was 1.3 million FORTRAN to 1.4 million Pascal--that is, not including all the compiles that were done on TERAK (which were LSI-I 1 's and Appl,e II's running UCSD Pascal). (SLIDE 15) So, what were our accomplishments? This is sort of a summary. The Users Group was not a bureaucracy. We could fold it up at any time. It was simply a vast bulletin board. I hope I can reassure Niklaus that the Pascal News articles provided a harmless outlet to frustrated language designers who wanted to extend Pascal. It dissipated their energy harmlessly. My successors were Rick Shaw (not a tzansportation vehicle) and Charlie Gaffney. One of the important things about the standards process is that the users were organized before the standards process began. (SLIDE 16) Thi s is a letter to the editor of a mainstream newspaper in the Twin Cities that is in the form of a Pascal program--so that by 1983, Pascal had even leaked out into the common culture. It's a critique of a movie or film critic.
Post-PUG--Pascal Today A. Seamless transition to MODUS Quarlerty, Jan 85. B. Borland Turbo Pascal on DOS-PC's. C. Think Pascal on Apple Macintosh. D. HP/Apollo, Silicon Graphics, DEC, SUN workstations. E. U of Minnesota Intemet Gopher, 1992. 1. Intemet public sewer browser. 2. Macintosh, DOS-PC, VAX, VM all in Pascalt 3. NeXT and other UNIX, NOTt
SLIDE
116
17
CHAPTER
III
TRANSCRIPT OF QUESTION AND ANSWER SESSION
(SLIDE 17) It turns out that Pascal News may have stopped publishing in 84 but there was a seamless transition to MODUS Quarterly, the Modula-2 Users Society. Here is the list of the current Pascal compilers, and the most famous application newly written in Pascal: the University of Minnesota Internet Gopher. And the versions for clients for Macintosh, DOS PC, VAX, and IBM VM are all in Pascal, but none of the UNIX boxes.
TRANSCRIPT OF QUESTION AND ANSWER SESSION ANDREW BLACK (Digital Cambridge Research Laboratory): The omission of dynamic arrays from Pascal was as much a mistake as the omission of recursion. True or False? WIRTH: In hindsight, true. You have to recall that I had not only to make language design decisions but also to implement them. Under these circumstances it is a question of whether to include more features, or to get ahead first with those needed to implement the compiler. In principle, you are right: Dynamic arrays should have been included. (Note: Recursion was excluded in a preliminary version only.) HERBERT KLAEREN (University of Tubingen): The current ISO draft of Modula-2 contains a full formal semantics. Do you consider this useful? WIRTH: Not really. It makes the report too voluminous for the reader. The Modula-2 report is 45 pages and the formal standardization document is about one thousand pages long. The definition of the empty statement alone takes a full page. The difference is intolerable. MARTIN CAMPBELL-KELLY (University of Warwick): If, on a scale of excellence in programming language design, FORTRAN was awarded two, and Pascal was awarded five, what score would Modula-2 deserve? WIRTH: Six. (In the Swiss school system, one is the worst and six is the best grade.) BRENT HAILPERN (IBM Research): Did you foresee the type "abuse" resulting from variant records? If not, what crossed your mind when the loophole was discovered? WIRTH: I did not foresee it, but I was told so by Tony Hoare. The reason for including the variant record was simply the need for it, and the lack of knowledge of how to do better. In the compiler itself several variants of records occur in the symbol table. For reasons of storage economy, variants are needed in order to avoid unused record fields. With memory having become available in abundance, the facility is now less important. Furthermore, better, type-safe constructs are known, such as type extensions (in Oberon). RANDY HUDSON (Infometrics): design of Ada?
What relationship do you see between the design of Pascal and the
WIRTH: I believe Ada did inherit a few ideas from Pascal, such as structures, concepts, and perhaps philosophy. I think the main differences stem from the fact that I, as an individual, could pick the prime areas of application, namely teaching and the design of systems of moderate complexity. Ada was devised according to a large document of requirements that the designers could not control. These requirements were difficult, extensive, partly inconsistent, and some were even contradictory. As a result, its complexity grew beyond what I considered acceptable. BOB ROSIN: Was the P-code concept inspired by earlier work? For example, the Snobol-4 implementation? PASCAL SESSION
117
TRANSCRIPT OF QUESTION AND ANSWER SESSION
WIRTH: It wasn't particularly the Snobol-4 implementation. The technique of interpreters was well known at the time. ALLEN KAY (Apple Computers): Your thesis and Euler were going in a pretty interesting direction. Why did you go back to more static languages? WlRTIt: For a thesis topic you have to do something that is new and original, you are expected to explore new way~s.Afterwards, as an engineer, I felt the need for creating something that is pragmatic and useful. Ross HAMILTON (University Of Warwick): across multiple files (as in FORTRAN II)?
Why did Pascal not allow source code to be split
WIRTH: We didn't perceive a need to provide such a facility. It is an implementation consideration, but not one of language design. ELLEN SPERTUS (MIT): You discussed the IEEE/ANSI standard for Pascal. There is also the de facto Borland Tu~rboPascal definition. Could you comment on the differences, in effect and content, of standards from democratic committees and from single companies? WIRTH: I thinl,: that would take too much time here. But the point is well taken that the actual standard for Pascal has been defined by Borland, just by producing a compiler and distributing it cheaply and widely. If you talk to anyone about Pascal today, probably Turbol Pascal from Borland is meant. Borland extended Pascal over the years, and some of these extensions were not as well integrated into the language as I would have wished. I was less compromising with my extensions and therefore gave the new design a new name. For example, what Borland calls Units we call Modules. However, Units are inclusions in the form of source code, whereas Modules are separate units of compilation, fully type checked and linked at load time. JEAN SAMMET (Programming Language Consultant): You mentioned COBOL twice-- once in connection with control structures and once in connection with records. Please clarify whether COBOL had any influence on Pascal and if so, in what way? WIRTH: Pascal inherited from COBOL the record structure, in fact indirectly via Tony Hoare's proposal includedt in Pascal's predecessor, ALGOL W. DANIEL J. SALOrdON (University of Manitoba): Although the pragmatic members ofthe ALGOL 68 Working Group have been shown, by time, to be correct, has not the ALGOL 68 report been valuable, flaws arid all? WIRTH: It has f'ostered a method of defining languages with precision and without reference to implementations. Its failure was probably due to driving certain ideas, such as "orthogonality" (mutual independence of properties) to extremes. The design was too dogmatic to be practical.
STAVROS MACRAKIS (OSF Research Institute): The original Pascal was small, limited in function, and completely defined. ISO's Pascal is large, comprehensive, and presumably well defined. What happened? ]Esit fair to consider ISO Pascal a diagnosis of Pascal's failings? WIRTH: I rather consider the standard as the belated result of a long-winded effort to make the definition more precise, and at the same time, of extending the language.
118
CHAPTER III
BIOGRAPHY OF NIKLAUS WlRTH
HERBERT KLAEREN (University of Tubingen): I always wondered why Pascal's dynamic data structures did not turn recursive data structures into "first class citizens." Instead of having the programmer himself handle explicit pointers (and doing all kinds of mischief with them), the compiler could have detected the need of introducing implicit pointers automatically (and transparently). Did this idea ever come up and if so, why did you reject it? WIRTH: We did not see a way to incorporate recursive structures in a way that was as flexible and as effective as explicit pointers. I could not wait until a solution appeared; time was precious and the need for an implementation language pressing. HERBERT KLAEREN(UniversityofTubingen): Given your comments on the Pascal standardization, what are your feelings about the ongoing ISO standardization of Modula-2? Wouldn't it be a good idea if the creator of a programming language gave, along with its definition, a list of the features contemplated, but dropped, along with the reasons for dropping them?
WIRTH: I am sure this would be a good idea, preventing later designers from having to repeat the same considerations.
ADAM RIFKIN (California Institute of Technology):
Why do you think the minority report signed in Munich (December 1968) had so many followers? Can you cite one main reason?
WIRTH: The Working Group 2.1 had been divided since the advent of A. van Wijngaarden's initial draft design in late 1965. The decision to pursue his draft rather than mine was taken in Warsaw in late 1966. The principal difference was that I had followed the goal of creating a successor to ALGOL 60 by essentially building upon ALGOL 60 and widening its range of application by adding data structures. Van Wijngaarden wanted to create an entirely new design, in fact another milestone (not millstone) in language design. The faction of"pragmatists" foresaw that it would take a long time to implement van Wijngaarden's proposal, and that by the time of its completion the majority of ALGOL users would have chosen another language already. (Note that ALGOL 68 compilers did not become available before 1972.)
Question is to ANDY MICKEL: The speaker mentioned an early anti-Pascal letter. Could you say more about that? MIKEL: That was an article that appeared in Acta lnformatica by A. N. Habermann, who wrote the paper called "Critical Comments on the Programming Language in Pascal" that Niklaus Wirth cited in his talk. It was countered by a reply from Oliver Lacarme and Pierre Dejardins. A lot of the self appointed experts at the University of Minnesota Computer Science Department preferred to beat us up in Computer Center about how Pascal should not have been taught, based on Habermann's paper, rather than even trying to use Pascal and see for themselves.
BIOGRAPHY OF NIKLAUS WlRTH Niklaus Wirth received the degree of Electronics Engineer from the Swiss Federal Institute of Technology (ETH) in Zurich in 1958. Thereafter he studied at Laval University in Quebec, Canada, and received the M.Sc. degree in 1960. At the University of California at Berkeley he pursued his studies, leading to the Ph.D. degree in 1963. Until 1967, he was Assistant Professor at the newly created Computer Science Department at Stanford University, where he designed the programming languages PL360 and--in conjunction with the IFIP Working Group 2.1--ALGOL W. In 1967, he
PASCAL SESSION
119
BIOGRAPHY OF NIKLAUS WIRTH
became Assistant Professor at the University of Zurich, and in 1968 he joined ETH Zurich, where he developed the languages Pascal between 1968 and 1970 and Modula-2 between 1979 and 1981. Further projects include the design and development of the Personal Computer Lilith, a high-performance workstation, in conjunction with the programming language Modula-2 (1978-1982), and the 32-bit workstation computer Ceres (1984.--1986). His most recent works produced the language Oberon, a descendant of Modula-2, which served to design the operating system with the same name (1986-1989). He was Chairman of the Division of Computer Science (Informatik) of ETH from 1982 until 1984, and again from 1988 until 1990. Since 1990, he has been head of the Institute of Computer Systems of ETH. In 1978, Professor Wirth received Honorary Doctorates from York University, England, and the Federal Institute of Technology at Lausanne, Switzerland, in recognition of his work in the fields of programming languages and methodology. In 1983, he was awarded the Emanuel Priore prize by the IEEE, in 1984 tlhe A. M. Turing prize by the ACM, and in 1987 the award for Outstanding Contributions to Computer Science Education by ACM. In 1987, he was awarded an Honorary Doctorate by the Universite Lavai, Canada, and in 1993 by the Johannes Kepler Universitat in Linz, Austria. In 1988, he was named a Computer Pioneer by the IEEE Computer Society. In 1989, Professor Wirth was awarded the Max Petitpierre Prize for outstanding contributions made by Swiss noted abroad, and he received the Science and Technology Prize from IBM Europe. He was awarded the Marcel Benoist Prize in 1990. In 1992, he was honored as a Distinguished Alumnus of the University of California at Berkeley. He is a member of the Swiss Academy of Technical Sciences and a Foreign Associate of the U.S. Academy of Engineering.
120
CHAPTER III
IV Monitors and Concurrent Pascal Session
Chair:
Michael Feldman
MONITORS AND C O N C U R R E N T PASCAL: A PERSONAL HISTORY
Per Brinch Hansen School of Computer and Information Science Syracuse University Syracuse, NY
ABSTRACT This is a personal history of the early development of the monitor concept and its implementation in the programming language Concurrent Pascal. The paper explains how monitors evolved from the ideas of Dahl, Dijkstra, Hoare, and the author (1971-1973). At Caltech the author and his students developed and implemented Concurrent Pascal and used it to write several model operating systems (1974-1975). A portable implementation of Concurrent Pascal was widely distributed and used for system design (1976-1990). The monitor paradigm was also disseminated in survey papers and textbooks. The author ends the story by expressing his own mixed feelings about monitors and Concurrent Pascal. CONTENTS 4.1 A Programming Revolution 4.2 Monitors 4.3 Concurrent Pascal 4.4 Further Development 4.5 In Retrospect Acknowledgments Appendix: Reviewers' Comments References
4.1 A PROGRAMMING REVOLUTION In the 1970s new programming languages were developed to express asynchronous, concurrent processes. These languages support the now familiar paradigms for process communication known as monitors, remote procedure calls, and synchronous communication. The most influential early idea was the monitor concept and its implementation in the programming language Concurrent Pascal. This is a personal history of how monitors and Concurrent Pascal were invented. I have tried to write the history of an idea--Low it arose and spread through the scientific community. I have also 121
PER BRINCH HANSEN
described the strutggles of the creative process, how you grope your way through obscurities and blind alleys until you find an elegant way of expressing an idea. The story of Concurrent Pascal frequently refers to my own work. However, I have let other researchers assess the merits and flaws of the language through quotations from the published literature. At the end of the paper I express my own reservations about the monitor concept and Concurrent Pascal. The appendix includes the personal comments of computer scientists who reviewed earlier ,drafts of this paper. As someone who participated in these discoveries, I cannot claim to have written a complete and unbiased history of these events. In many cases my knowledge of related work is derived solely from the literature. I hope that historians will take care of these flaws by comparing my story with other sources. From my perspective there are three distinct phases in the early history of monitors: 1971-1973. Monitors evolved from the ideas of Ole-Johan Dahl, Edsger Dijkstra, Tony Hoare, and me. In 1973 Hoare and I independently published programming notations for monitors. 1974-1975. Working with a few students and a professional programmer at Caltech, I developed and implemented the first programming language with monitors. My ambition was to do for operating systems what Pascal (and other programming languages) had done for compilers: to reduce the programming effort by an order of magnitude compared to assembly language. This was indeed achieved for small operating systems (but not for larger ones). 1976-1990. A portable implementation of Concurrent Pascal was widely distributed and used for system design. The monitor paradigm was now disseminated throughout the computer science community in survey papers and textbooks on operating systems, concurrent programming, and programming languages.
Each phase will be described in a separate section of the paper. After 1975 the monitor concept inspired other researchers to develop verification rules, monitor variants, and more programming languages [Andrews 1983]. Originally I intended to include a broad review of these later developments, which I know only from the literature. However, after writing several earlier drafts of this paper, I realized that I can only provide meaningful historical remarks on ideas and events which I have firsthand knowledge about. The reviewers' comments confirmed this impression. I will therefore limit the scope of this personal history to the discovery of the monitor concept and the development and use of the first monitor language Concurrent Pascal. Since I can only speak for myself, I have not imposed the same restriction on the reviewers' comments quoted in the appendix. 4.2 MONITOFIS On the road toward monitors, several alternatives were considered. It may be easier to appreciate the piecemeal discovery if I briefly summarize the final idea. Monitors enable concurrent processes to share data and resources in an orderly manner. A monitor is a combination of shared variables and procedures. Processes must call these procedures to operate on the shared variables. The monitor procedures, which are executed one at a time, may delay the calling processes until resources or data become available.
122
CHAPTER IV
PAPER: MONITORS AND CONCURRENT PASCAL
Beginner's Luck I started out in industry as a systems programmer for the Danish computer manufacturer Regnecentralen in Copenhagen. In 1967 I became responsible for the development of the RC 4000 multiprogramming system. In the 1960s most operating systems were huge unreliable programs that were extremely difficult to understand and modify. The RC 4000 system was a radical departure from this state of affairs. It was not a complete operating system, but a small kernel upon which operating systems for different purposes could be built in an orderly manner. The kernel provided the basic mechanisms for creating a hierarchy of parallel processes that communicated by messages. The idea of designing a general kernel for operating system design was due to JOrn Jensen, SCren Lauesen, and me [Brinch Hansen 1969]. I consider myself lucky to have started in industry. The RC 4000 project convinced me that a fundamental understanding of operating systems would change computer programming radically. I was so certain of this that I decided to leave industry and become a researcher. In November 1970 I became a Research Associate in the Department of Computer Science at Carnegie-Mellon University. My goal was to write the first comprehensive textbook on operating system principles [Brinch Hansen 1973b]. As soon as I started writing, it became clear that I needed an algorithmic language to express operating system functions concisely without unnecessary trivia. In an outline of the book I explained my choice of description language [Brinch Hansen 1971a]: So far nearly all operating systems have been written partly or completely in machine language. This makes them unnecessarily difficult to understand, test and modify. I believe it is desirable and possible to write efficient operating systems almost entirely in a high-level language. This language must permit hierarchal structuring of data and program, extensive error checking at compile time, and production of efficient machine code. To support this belief, I have used the programming language Pascal throughout the text to define operating system concepts concisely by algorithms. Pascal combines the clarity needed for teaching with the efficiency required for design. It is easily understood by programmers familiar with Algol 60 or Fortran, but is a far more natural tool than these for the description of operating systems because of the presence of data structures of type record.., and pointer. At the moment, Pascal is designed for sequential programming only, but I extend it with a suitable notation for multiprogramming and resource sharing. Bold words indeed from a programmer who had never designed a programming language before, who did not have access to a Pascal compiler, and who had no way of knowing whether Pascal would ever be used for teaching! Niklaus Wirth [ 1971 ] had just published the first paper on Pascal, and there were, of course, no textbooks based on this new language. A Beautiful Idea
The key problem in concurrent programming was to invent language concepts for asynchronous processes that share data in a common memory. Dijkstra [1965] had argued that it is essential to treat operations on shared variables as critical regions that must be performed strictly one at a time in arbitrary order. He had also shown how to implement critical regions using semaphores. But he had not suggested a notation for this idea.
MONITORS AND CONCURRENT PASCAL SESSION
123
PER BRINCH HANSEN
Hoare [1971b] proposed a notation that identifies a variable as a resource shared by concurrent processes. A good example is a ring buffer represented by an array with input/output indices and a message counter: B: r e c o r d ~Lnpointer, o u t p o i n t e r , count: buff~r: a r r a y 0..N-i of T end; {resource 13; P r o d u c e r / / C o n s u m e r }
integer;
The buffer is shared by two concurrent processes which produce and consume messages, respectively. (In most examples, including this one, I have used the programming notation of the original papers.) In his paper Hoare also introduced the elegant concept of a conditional critical region that is delayed until a resource satisfies a particular condition (defined by a Boolean expression). The send operation on the ring buffer is a conditional critical region that is executed when the buffer is not full: with
B when begin
count
~ N do := next
buffer[inpointer]
inpointer := ( i n p o i n t e r count := c o u n t + 1
value;
+ i)
mod
N;
end
The receive operation is similar: with
B whe:a c o u n t
begin
> 0 do
this v a l u e outpointer count
:-- b u f f e r [ o u t p o i n t e r ] ; := ( o u t p o i n t e r + i) m o d N;
:= c o u n t
- 1
end
A compiler must check that the resource is accessed only within critical regions. A computer must guarantee that these regions are executed one at a time without overlapping. In retrospect, the limitations of conditional critical regions are perhaps obvious: • The resource concept is unreliable. The same variable may be treated as a scheduled resource in some contexts and as an ordinary variable in other contexts. This may enable one process to refer directly to a variable while another process is within a "critical" region on the same variable. • The scheduling mechanism is too restrictive. When a process is delayed by a Boolean expression without side effects, it cannot indicate the urgency of its request to other processes. This complicates the programming of priority scheduling. • The context switching is inefficient. It did not seem possible to implement conditional critical regions efficiently. The problem was to limit the repeated reevaluation of Boolean expressions until they became true. • There is no precise idea of data abstraction. The declarati,an of a resource and the ol~erations associated with it are not combined into a single, syntactical form, but are distributed throughout the program text. Attempts to remove these problems eventually led to the discovery of monitors.
124
CHAPTER IV
PAPER: MONITORSAND CONCURRENT PASCAL
Readers and Writers During the International Summer School in Marktoberdorf, Germany, July 1971, I removed the first two limitations of conditional critical regions by solving an interesting problem [Brinch Hansen
1972a]. Two kinds of processes, called readers and writers, share a single resource. Readers can use it simultaneously, but a writer can use the resource only when nobody else is using it. When a writer is ready to use the resource, it should be enabled to do so as soon as possible [Courtois 1971 ]. This is, of course, a priority scheduling problem. First, I solved a slightly simpler problem that permits several writers to use the resource simultaneously. A shared variable was now introduced by a single declaration: vat
v:
shared
record
readers,
writers:
integer
end
This notation makes it clear that a shared variable may be accessed only within critical regions. A reader waits until writers are neither using the resource nor waiting for it: region
v when
readers read; region
v
writers
:= r e a d e r s do
readers
= 0 do + i;
:= r e a d e r s
-
1
A writer immediately announces itself and waits until no readers are using the resource: region
v
await
do
writers
readers
:= w r i t e r s
+ 1
:= w r i t e r s
- 1
= O;
write; region
v
do
writers
The scheduling condition may appear at the beginning or at the end of a critical region. The latter permits scheduling with side effects. It was an obvious extension to permit a scheduling condition to appear anywhere within a critical region [Brinch Hansen 1972b]. Courtois [1972] and others had strong reservations about conditional critical regions and my solution to the readers and writers problem [Brinch Hansen 1973a]. A New Paradigm The idea of monitors evolved through discussions and communications among E.W. Dijkstra, C.A.R. Hoare, and me during the summer and fall of 1971. My own ideas were particularly influenced by our discussions at the International Summer School in Marktoberdorf, Germany, July 19-30, 1971. Hoare and I continued the exchange of ideas at the Symposium on Operating Systems Techniques in Belfast, August 30-September 3, 1971. At Marktoberdorf, Dijkstra [ 1971] briefly outlined a paradigm of secretaries and directors: Instead of N sequential processes cooperating in critical sections via common variables, we take out the critical sections and combine them into a N + 1sl process, called a "secretary"; the remaining N processes are called "directors." A secretary presents itself primarily as a bunch of non-reentrant routines with a common state space. When a director calls a secretary.., the secretary may decide to keep him asleep, a decision that implies that she should wake him up in one of her later activities. As a result the identity of the calling program cannot remain anonymous as in the case of the normal subroutine. The secretaries must have variables of type "process identity." Whenever she is called the identity of the calling process is handed over in an implicit MONITORS AND CONCURRENTPASCALSESSION
125
PER BRINCH HANSEN
input parameter; when she signals a release---analogous to the return of the normal subroutinehshe will supply the identity of the process to be woken up. In Belfast I presented an outline of a course on operating system principles that included the following remarks [Brinch Hansen 197 la]: The conceptual simplicity of simple and conditional critical regions is achieved by ignonng the sequence in which waiting processes enter these regions. This abstraction is unrealistic for heavily used resources. In such cases, the operatJLng system must be able to identify competing processes and control the scheduling of resources among them. This can be done by means of a monitor--a set of shared procedures which can delay and activate individual processes and perform operations on shared data. During a discussion on monitors I added the following [Discussion 1971 ]: You can imagine the (monitor) calls as a queue of messages being served one at a time. The monitor will receive a message and try to carry out the request as deft ned by the procedure and its input parameters. If the request can immediately be granted the monitor will return parameters.., and allow the calling process to continue. However, if the request cannot be granted, the monitor will prevent the calling process from continuing, and enter a reference to this transaction in a queue local to itself. This enables the monitor, at a later time when it is called by another process, to inspect the queue and decide which interaction should be completed now. From the point of view of a process a monitor call will look like a procedure call. The calling process will be delayed until the monitor consults its request. The monitor then has a set of scheduling queues which are completely local to it, and therefore protected against user processes. The latter can only access the shared variables maintained by the monitor through a set of well defined operations.., the monitor procedures. At the Belfast Symposium, Hoare expressed his own reservations about conditional critical regions [Discussion 1971 ]: As a result of discussions with Brinch Hansen and Dijkstra, 1feel that this proposal is not suitable for operating system implementation. My proposed method encourages the programmer to ignore the question of which of several outstanding requests for a rescmrce should be granted. The scheduling dq~ision cannot always be expressed by means of a single Boolean expression without side effects. You sometimes need the power of a general procedural program with storage in order to make scheduling decisions. So it seems reasonable to take all these protected critical regions out, and put them together and call it a secretary or monitor. In the 1960s the resident part of an operating system was often known as a monitor. The kernel of the RC 4000 muitiprogramming system was called the monitor and was defined as a program that "can execute a sequence of instructions as an indivisible entity" [Brinch Hansen 1969]. At Belfast we discussed the disadvantages of the classical monitor written in assembly language [Discussion 1971 ]: Bdnch Hansen: The difficulty with the classical "monolithic" monitor is not the fact that while you are performing an operation of type A you cannot perform another operation of type A, but that if you implement them by a single critical section which inhibits further monitor calls then the fact that you are executing an operation A on one data set prevents all other operations on completely unrelated data sets. That is why I think the ability to have several monitors, each in charge of a single set of shared data, is quite important. Hoare: A monitor is a high-level language construction which has two properties which are not possessed by most monitors as actually implemented in machine code. Firstly, like all good programming ideas it can be called in at several levels: monitors can call other monitors declared in outer blocks. Secondly, the use of the high-level langualge feature enables you to associate with each monitor the particular variables and tables 126
CHAPTER IV
PAPER: MONITORS AND CONCURRENT PASCAL
which are relevant for that monitor in controlling the relative progress of the processes under its care. The protection, which prevents processes from corrupting this information and prevents monitors from gaining access to information which has no relevance, is established by Algol-like scope rules. These quotations show that Dijkstra, Hoare, and I had reached an informal understanding of monitors. But it was still no more than a verbal outline of the idea. The discovery of a queuing mechanism, a notation, and an implementation was left as an exercise for the reader. Abandoned Attempts When a programming concept is understood informally, it would seem to be a trivial matter to invent a language notation for it. But in practice this is hard to do. The main problem is to replace an intuitive, vague idea with a precise, unambiguous definition of its meaning and restrictions. In the search for a suitable monitor notation many ideas were considered and rejected, I will describe two proposals that were abandoned. You may find them hard to understand. In retrospect, so do I! At the Belfast Symposium, Hoare [ 1971 a] distributed an unpublished draft of a monitor proposal that included a single-buffer characterized as follows: status status status status
= = = =
-1 0 1 2
buffer buffer buffer buffer
empty (consumer waiting) empty (consumer not waiting) full (producer not waiting) full (producer waiting)
The send operation is defined by a monitor entry named p: p (prod) entry begin if status O)/T~-A[tlO0]
The definition of the series primitives and their permitted compositions is cleverly constrained so that they can always be compiled into efficient iterative code without the need for unboundedly large intermediate data structures at run time. Generators and gatherers are a method of encapsulating series (at the cost of run-time state) so that they look like input or output streams, respectively, that serve as sources or sinks of successive values by side effect. Thus (generator
(scan-range
:start 0 :below i00))
produces an object that delivers successive integers 0 through 99 when repeatedly given to the extraction function n e x t - i n . The complete example might be rendered as (let ( (hum (generator (scan-range :start 0 :below I00) ) ) ) (gathering ( (result collect-sum) ) (loop (let ((J (next-ln num (return result)))) (if (plusp J) (next-out result J))))))
This reminds one of the possibilities lists of Conniver [McDermott 1974] or of the generators of Alphard [Shaw 1981], though we know of no direct connection. Generators and gatherers emphasize use of control structure rather than functional relationships.
272
CHAPTER VI
PAPER:THE EVOLUTIONOF LISP
After much debate, X3J 13 applauded the development of series and generators but rejected them for standardization purposes, preferring to subject them first to the test of time. One other iteration construct that deserves discussion is the MacLisp "new-style" d o loop, introduced in March of 1972: (do
((varl initl step/) (var2 init2 step2) o o o
( varn initn stepn ) ) ( t e s t . result) body)
This evaluates all the init forms and binds the corresponding variables v a r to the resulting values. It then iterates the following sequence: if evaluating the test form produces a true value, evaluate the result forms and return the value of the last one; otherwise execute the body forms in sequence, give the variables of the values of the s t e p forms, and repeat. The beauty of this construct is that it allows the initialization and stepping of multiple variables without use of pseudo-English keywords. The awful part is that it uses multiple levels of parentheses as delimiters and you have to get them right or endure strange behavior; only a diehard Lisper could love such a syntax. Arguments over syntax aside, there is something to be said for recognizing that a loop that steps only one variable is pretty useless, in a n y programming language. It is almost always the case that one variable is used to generate successive values while another is used to accumulate a result. If the loop syntax steps only the generating variable, then the accumulating variable must be stepped "manually" by using assignment statements (as in the FORTRAN example) or some other side effect. The multiple-variable d o loop reflects an essential symmetry between generation and accumulation, allowing iteration to be expressed without explicit side effects: (define (factorial n) (do ((J n (- J i)) (f 1 (* J f))) ( ( = J 0) f ) ) )
It is indeed not unusual for a d o loop of this form to have an empty body, performing all its real work in the step forms. Although there is a pretty obvious translation of this d o construct in terms of p r o g and aetet, there is also a perspicuous model free of side effects: (labels
( (the-loop (la~hda
(cond
( v a r l var2 ... (test . result)
(t (progn
(the-loop
yarn)
. body)
(the-loop initl init2 . . . initn) )
step/ step2 . . .
stepn) ) ) ) ) )
Indeed, this is equivalent to the definition of d o adopted by Scheme [IEEE 1991], which resolves an outstanding ambiguity by requiring that the variables be updated by binding rather than by side effect. Thus the entire iteration process is free of side effects. With the advent of good Scheme compilers such as ORBIT [Kranz 1986] and good Common Lisp compilers, compiling the result of this side-effect-free translation produces exactly the same efficient machine-language code one would expect from the PROG-and-SETQ model.
LISP SESSION
273
GUY L. STEELE JR. & RICHARD R GABRIEL
6.3.3
Macros
Macros appear to have been introduced into Lisp by Timothy P. Hart in 1963 in a short M1T AI Memo [Hart 1963], which we quote here in its entirety (with permission): In LISP 1.5 spex:ial forms are used for three logically separate purposes: a) to reach the alist, b) to allow functions to have: an indefinite number of arguments, and c) to keep arguments from being evaluated. New LISP interp]reters can easily satisfy need (a) by making the alist a SPECIAL-type or APVAL-type entity. Uses (b) and (c) can be replaced by incorporating a MACROinstruction expander in d e f i n e . I am proposing such an expander. 1. The property list of a macro definition will have the indicator MACRO followed by a function of one argument, a form beginning with the macro's name, and whose value will replace the original form in all function definitions. 2. The function m a c r o [ 1] will define macros just as d e f i n e [ 1 ] defines functions. 3. d e f i n e
will be modified to make macro expansions.
Examples: 1. The existing FEXPR c s e t q
may be replaced by the macro definition:
MAcRo ( ( (CSETQ (LAMBDA (FORM} (LIST (CADDR PORM} } ) ) ))
2. A new macro s t a s h
(QUOTE CSET)
(LIST
(QUOTE QUOTE)
(CADR FORM) )
will generate the form found frequently in PROG's:
x :- cons[form;x] Using the macro stash, one might write instead of the above: (STASH
VORM X)
S t a s h may be defined by: MACRO ( ( (STASH (LAMBDA (FORM) (LIST (QUOTE SETQ) (CADAR FORM) (LIST (CONS (CADR FORM) (CADAR FORM)) ) } ) ) ))
3. New macros may be defined in terms of old. E n t e r is a macro for adding a new entry to a table (dotted p~firs) stored as the value of a program variable. MACRO enter [form] =list [STASH; list [CONS; cadr [form] ; c a d d r [form] ; c a d d d r [form] ]
Incidentally, use of macros will alleviate the present difficulty resulting from the 90 LISP compiler's only knowing about those fexprs in existence at its birth. The macro defining function m a c r o is easily defined: macro[ll
--- deflist[1;MACROl
The new d e f i n e is a little harder: d e f i n e [ l ] =- d e f l i s t [ m d e f [ l ] t E X P R ] mdef[l] E [ a t Q m [ l ] -e 11
274
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP e q [ c a r [ 1 1 ; Q U O T E ] --~ I; member[car[l]t(LAMBDA L A B E L P R O G ) ] --~ c o n s [c a r [ 1 ] ; c o n s [c a d r [ 1 ] ; m d e f [c a d d r [ 1] ] ] ] ; g e t [car [i] ; M A C R O ] -~ m d e f [get [car [i] ; M A C R O ] [i] ] ; T --~ m a p l i s t [ l ; k [ [ J ] ; m d e f [ c a r [ J ] ] ] ] ]
4. The macro for s e l e c t il]ustrat¢sthe use of macros as a means of el|owing functions of an arbitrary
number of arguments: MACRO select [form] -= k[ [g] ; list [list [LAMBDA; list [g] ;cons [COND; m a p l i s t [cddr [form] ;k[ [i] ; [null[cdrE1]] --~ list[Ttcar[l]]; T --~ l i s t [ l i s t [ E Q ; g ; c a a r [ 1 ] ] ; c a d a r [ 1 ] ] ] ] ] ] ] ;cadr [fermi ] ] [gensym[ ] ]
There are a number of points worth noting about Hart's proposal. It allows the macro expansion to be computed by an arbitrary user-defined function, rather than relying on substitution into a template, as so many other macro processors of the day did. He noted that macros, unlike fexprs, require no special knowledge for each one on the part of the compiler. Macros are expanded at function definition time, rather than on the fly as a function is interpreted or compiled. Note the switching off between S-expression and M-expression syntax. The STASH macro is the equivalent of the PUSH macro found in Interlisp [Teitelman 1978] and later in Common Lisp by way of Lisp-Machine Lisp; the verb"stash" was commonly used in the 1960s. There are two minor bugs in the definition of rode f: first, PROG is not properly handled, because it fails to process all the statements in a PROG form; second, COND is not handled specially, which can lead to mistakes i f a variable has the same name as a macro and the variable is used as the test part of a COND clause. (Perhaps this was an oversight, or perhaps it never occurred to Hart that anyone would have the bad taste to use a name for two such different purposes.) The last example illustrates the technique of generating a new name for a temporary binding to avoid multiple evaluations of an argument form. Finally, Hart achieved an amazing increase in expressive power with a deceptively simple change to the language, by encouraging the user to exploit the power of Lisp to serve as its own metalanguage. Hart's macro language was subsequently used in the Lisp system for the Q-32 [Saunders 1964b]. Inspection of the MDEF function in the compiler code [Saunders 1964a, p. 311 ] reveals that the error in processing P R O G statements had been repaired: m d e f [ c a d d r [ l ] ] was replaced by m d e f [ c d d r [1] ]. (In fact, this may be what Hart had originally intended; in Hart 1963 the " a " appears to have been written in by hand as a correction over another letter. Perhaps the typist had made the typographical error m d e f [ e c d d r [ 1 ] ] and subsequently a wrong correction was made.) Unfortunately, the use of male f [ e d d r [ 1 ] ] has its own problems: a variable whose value is returned by a LAMBDA expression or a tag at the head o f a PROG might be incorrectly recognized as the name of a macro, thereby treating the body of the LAMBDA or PROG form as a macro call. Picky, picky--but nowadays we do try to be careful about that sort of thing. Macros of this kind were an integral part of the design of Lisp 2. Abrahams et al. remark that by 1966 macros were an accepted part of Lisp 1.5 as well [Abrahams 1966]. A similar sort of computed macro appeared in the MIT PDP-6 Lisp, but macro calls were expanded on the fly as they were encountered by the compiler or the interpreter. In the case of the interpreter, if an explicitly named function in a function call form turned out to have a MACRO property on its property list (rather than one of the function indicators EXPR, SUBR, LSUBR, FEXPR, or FSUBR) then the function definition was given the original macro call form as an argument and was expected
LISP SESSION
27S
GUY L. STEELE JR. & RICHARD P. GABRIEL
to return another form to be evaluated in place of the call. The example given in the PDP-6 Lisp memo [PDP-6 Lisp 196711 was (DEFPROP C O N S C O N S (L A M B D A
(A)
(COND ((NULL (CDDR A)) (CADR A)) ((LIST (QUOTE CONS) (CADR A) (CONS (CAR A) (CDDR A)))))
MACRO) This defined a ma~cro equivalent in effect to the Common Lisp function list*. Note the use of DEFPROP to define a function, the use of QUOTE rather than a single quote character, and the omission of the now almost universally customary T in the second COND clause. An advantage of this scheme was that one could define some functions that use macros and later define (or redefine) the macro; a macro call would always use the latest macro definition. A drawback, however, was that the interpreter must constantly re-expand the same macro call every time it is repeated, reducing; speed of execution. A device called displacing macros soon became common among MacLisp users; it involved the utility function DISPLACE: (DEFUN D I S P L A C E (RPLACA OLD (RPLACD O L D OLD )
(OLD NEW) (CAR NEW)) (CDR NEW))
One would then write (DEFPROP CO~SeONS (I ~ M B D A (A) (DISPLACE A
(COND . . . ) ) ) MACRO )
The effect was to destructively alter the original list structure of the macro call so as to replace it with its expansion. This all-too-cle,ver trick had drawbacks of its own. First, it failed if a macro needed to expand to an atom (such as a number or variable reference); macro writers learned to produce (PROGN FOO) instead of FOO. Second, if a macro were redefined after a call to it had been displaced, subsequent executions of the call would not use the new definition. Third, the code was modified; the pretty-printing code that origiinally contained a macro call would display the expansion, not the original macro call. This last drawback was tolerable only because the MacLisp environment was so firmly file-based: displacing macros modified only the in-core copy of a program; it did not affect the master definition, which was considered to be the text in some file. Displacing macros of this kind would have been intolerable in Inte~rlisp. Around 1978, Lisp-Machine Lisp introduced an improvement to the displacement technique: (defun displace (rplacd n e w (rplaca old
(old new)
(list (cons (car old) 'si:displaced)
(cdr old)) new))
new) (defmacro si~displaced 276
(old new) new) CHAPTER Vl
PAPER:THE EVOLUTIONOF LISP
The idea is that the macro call is displaced by a list (si :displaced macro-call expansion). The macro s i : d i s p l a c e d transparently returns its second argument form, so everything behaves as if the expansion itself had replaced the macro call. Although expanding the call to s i : d i s p l a c e d is not free, it is presumably cheaper than continually re-expanding the original macro call (if not, then the macro writer shouldn't use d i s p l a c e ) . The Lisp Machine pretty-printer recognizes calls to s i : d i s p l a c e and prints only the original macro call. BBN-Lisp [Teitelman 1971 ] had three kinds of macro: open, computed, and substitution (described later). A macro definition was stored in the property list of its name under the MACRO property; the form of the property value determined which of three types of macro it was. Originally all three types were effective only in compiled code. Eventually, however, after BBN-Lisp became Interlisp [Teitelman 1978], a DWlM hack called MACROTRAN was added that made all three types of macro effective in interpreted code. If interpreting a function call resulted in an "undefined function" error, the DWIM system would step in. MACROTRAN would gain control, expand the macro, and evaluate the resulting expansion. The Interlisp manual duly notes that interpreted macros will work only if DWlM is enabled. Contrast this with the MIT approach of building macros directly into the interpreter (as well as the compiler) as a primitive language feature. A BBN-Lisp open macro simply caused the macro name to be replaced by a lambda expression, causing the function to be compiled "open" or in-line. Here is an open macro definition for ASS: (LAMBDA
(X)
(COND
( (GREATERP
X 0) X)
(T (MINUS X) ) ) )
Of course, this has exactly the same form as a function definition. A BBN-Lisp computed macro was similar to the kind in MIT PDP-6 Lisp, except that the expander function received the CDR of the macro call rather than the entire macro call. Here is a computed macro for LIST: (X (LIST
(QUOTE CONS) (CAR x ) (AND (CDR X) (CONS (QUOTE LIST) (CDR X]
The leading X is the name of a variable to be bound to the CDR of the macro call form. Note also the use of a closing superbracket in the definition. (See Section 6.2.3.) A BBN-Lisp substitution macro consisted of a simple pattern (a parameter list) and a substitution template; subforms of the macro call were substituted for occurrences in the template of corresponding parameter names. A substitution macro for ASS would look like this: ((X)
(COND
((OREATERP
X 0) X)
(T (MINUS X))))
However, the call (ABS (FO0 Z) ) would be expanded to (COND
( (GREATERP
(FOO Z) 0)
(FO0 Z) ) (T (MINUS
(FO0 Z) ) ) )
leading to multiple evaluations of (FOO Z), which would be unfortunate if (FOO Z) were an expensive computation or had side effects. By way of contrast, with an open macro the call (ABB (FOO Z) ) would be expanded to ((LAMBDA
(X)
(COND
((OREATERP
X 0) X)
(T (MINUS X))))
(FO0 Z))
which would evaluate (FOO Z) exactly once.
LISP SESSION
277
GUY L. STEELE JR. & RICHARD P. GABRIEL
Despite the care sometimes required to avoid multiple evaluation, however, the pattern/template methodology for defining macros is very convenient and visually appealing. Indeed, pattern matching and template methodologies were a pervasive topic in the development of languages for Artificial Intelligence throughout the 1960s and 1970s. (See Section 6.4.) We return to the topic of templatebased macros later. Muddle [Galley 1975], not surprisingly, had a macro facility very much like that of PDP-6 Lisp, with one slight difference. The macro expansion function, rather than being called with the macro form as its argument, was applied to the CDR of the form. This allowed Muddle's complex argument-list keywords to come into play, allowing certain simple kinds of pattern matching as for Interlisp's substitution macros: >
It was nevertheless necessary to laboriously construct the result as for a computed macro. The result of expanding (cadr x) (cddddr x)))))))
(cadddr x))
That's a lot to write for such a simple transformation. Eventually the gurus at various MacLisp sites developed dozens of similar but not quite compatible macro-defining macros. It was not unusual for several such packages to be in use at the same site, with the adherents of each sect using whatever their wizard had developed. Such packages usually included tools for destructuring argument forms and for constructing result forms. The tools for constructing result forms fell into two major categories: substitution and pseudo-quoting. Substitution techniques required separate mention in a template of certain symbols that were to be replaced by specified values. Pseudo-quoting allowed the code to compute a replacement value to occur within the template itself; it was called pseudo-quoting because the template was surrounded by a call to an operator that was "just like q u o t e " except for specially marked places within the template. Macros took a major step forward with Lisp-Machine Lisp, which consolidated the various macro-defining techniques into two standardized features that were adopted throughout the MacLisp community and eventually into Common Lisp. The macro-defining operator DEFMACRO provided list-structure destructuring to arbitrary depth; the backquote feature provided a convenient and concise pseudo-quoting facility. Here is the definition of the FOR macro using DEFMACRO alone: (defmacro for (var lower u p p e r . body) (cons 'do (cons var (cons lower (cons (list '+ var i) (cons (list '> var upper) body))))))
Notice that we can name the parts of the original form. Using the backquote pseudo-quoting syntax, which makes a copy of a template, filling in each place marked by a comma with the value of the following expression, we get a very concise and easy-to-read definition: (defmacro for (var lower u p p e r . body) "(do ,var ,lower (+ ,var i) (> ,var ,upper)
LISP SESSION
,@body))
279
GUY L. STEELE JFI. & RICHARD P. GABRIEL
Note the use c,f, @ to indicate splicing. The backquote syntax was particularly powerful when nested. This occurred primarily within macro-defining raacros; because these were coded primarily by wizards, the ability to write and interpret nested backquote expressions was soon surrounded by a certain mystique. Alan Bawden of MIT acquired a particular reputation as backquote-meister in the early days of the Lisp Machine. Backquote anti DEFMACRO made a big difference. This leap in expressive power, made available in a standard form, began a new surge of language extension because it was now much easier to define new language co~astructs in a standard, portable way so that experimental dialects could be shared. Some, including David Moon, have opined that the success of Lisp as a language designer's kit is largely due to the ability of the user to define macros that use Lisp as the processing language and list structure as the program representation, making it easy to extend the language syntax and semantics. In 1980 Kent Pitman wrote a very good summary of the advantages of macros over FEXPR's in defining new language syntax [Pitman 1980]. Not every macro was easy to express in this new format, however. Consider the INC macro discussed above. ,As of November of 1978, the Lisp Machine DEFMACRO destructuring was not quite rich enough to handle "optional" argument forms: (DEFUN INC M A C R O (VAR . R E S T ) " ( S E T Q ,VAR (+ , V A R , (IF R E S T
(CAR R E S T )
i))))
The optional part must be handled with an explicitly programmed conditional (expressed here using IF, which was itself introduced into Lisp-Machine Lisp, probably under the influence of Scheme, as a macro that expanded into an equivalent COND form). This deficiency was soon noticed and quickly remedied by allowing DEFMACRO to accept the same complex lambda-list syntax as DEFUN: (DEFUN INC M A C R O (VAR & O P T I O N A L "(SETQ ,VAR (+ ,VAR ,N)))
(N 1))
This occurred in January of 1979, according to Lisp Archive, at which time MacLisp absorbed DEFMACRO and DEFUN with &-keywords from Lisp-Machine Lisp. An additional problem was that repetitive syntax, of the kind that might be expressed in extended BNF with a Kleene star, was not captured by this framework and had to be programmed explicitly. Contemplate this simple definition of LET: let (bindings . body) • ((lamhda , (mapcar #'car bindings) , @ ( m a p c a r #'cadr bindings) ) )
(defmacro
,@body)
Note the use of M A P C A R for iterative processing of the bindings. This difficulty was not tackled by Lisp-Machine Lisp or Common Lisp; in that community DEFMACRO with &-keywords is the state of the art today. Common Lisp did, however, generalize DEFMACRO to allow recursive nesting of such lambda-lists. Further development of the theory and practice of Lisp macros was carried forward primarily by the Scheme com~aunity, which was interested in scoping issues. Macros are fraught with the same kinds of scoping problems and accidental name capture that had accompanied special variables. The problem with Lisp macros, from the time of Hart in 1963 to the mid- 1980s, is that a macro call expands into an expression that is composed of symbols that have no attached semantics. When substituted back into the program, a macro expansion could conceivably take on a quite surprising meaning depending on the local environment. (Macros in other languages--the C preprocessor [Kernighan 1978; Harbison 1991 ] is one example--have the same problem if they operate by straight substitution of text or tokens.) 280
CHAPTER Vl
PAPER:THE EVOLUTION OF LISP
One practical way to avoid such problems is for the macro writer to try to choose names that the user is unlikely to stumble across, either by picking strange names such as ~ f o o ~ (though it is surprising how often great minds will think alike), by using g e n s l r m (as Hart did in his s e l e c t example, shown in the preceding), or by using multiple obarrays or packages to avoid name clashes. However, none of these techniques provides an iron-clad guarantee. Steele pointed out that careful use of thunks could probably eliminate the problem, though not in all situations [Steele 1978a]. The proponents of Scheme regarded all of these arrangements as too flawed or too clumsy for "official" adoption into Scheme. The result was that Scheme diversified in the 1980s. Nearly every implementation had some kind of macro facility but no two were alike. Nearly everyone agreed that macro facilities were invaluable in principle and in practice but looked down upon each particular instance as a sort of shameful family secret. If only The Right Thing could be found! This question became more pressing as the possibility of developing a Scheme standard was bandied about. In the mid-1980s two new sorts of proposals were put forward: hygienic macros and syntactic closures. Both approaches involve the use of special syntactic environments to ensure that references are properly matched to definitions. A related line of work allows the programmer to control the expansion process by explicitly passing around and manipulating expander functions [Dybvig 1986]. All of these were intended as macro facilities for Scheme, previous methods being regarded as too deeply flawed for adoption into such an otherwise elegant language. Hygienic macros were developed in 1986 by Eugene Kohlbecker with assistance from Daniel Friedman, Matthias Felleisen, and Bruce Duba [Kohlbecker 1986a]. The idea is to label the occurrences of variables with a tag indicating whether it appeared in the original source code or was introduced as a result of macro expansion; if multiple macro expansions occur, the tag must indicate which expansion step was involved. The technique renames variables so that a variable reference cannot refer to a binding introduced at a different step. Kohlbecker's Ph.D. dissertation [Kohibecker 1986b] carried this a step further by proposing a pattern matching and template substitution language for defining macros; the underlying mechanism automatically used hygienic macro expansion to avoid name clashes. The macro-defining language was rich enough to express a wide variety of useful macros, but provided no facility for the execution of arbitrary user-specified Lisp code; this restriction was thought necessary to avoid subversion of the guarantee of good hygiene. This little language is interesting in its own right. Although not as general as the separate matching and substitution facilities of DEFMACRO and backquote (with the opportunity to perform arbitrary computations in between), it does allow for optional and repetitive forms by using a BNF-like notation, and allows for optional situations by permitting multiple productions and using the first one that matches. For example, INC might be defined as (extend-syntax (inc) () ((inc x) (inc x I)) ((inc x n) (setq x ( + x n ) ) ) ) and L E T as
(extend-syntax (let) () ((let ((var value) • . . ) body . . . ) ((lambda (var ...) body . . . ) v a l u e
...)))
The ellipsis " . . . " serves as a kind of Kleene star. Note the way in which variable-value pairs are implicitly destructured and rearranged into two separate lists in the expansion. The first list given to e x t e n d - s y n t a x is a list of keywords that are part of the macro syntax and not to be tagged as possible variable references. The second list mentions variables that may be introduced by the macro expansion but are intended to interact with the argument forms. For example, LISP SESSION
281
GUY L. STEELE JR. & RICHARD R GABRIEL
consider an implementation (using the Scheme call-with-current-continuation primitive) of a slight generalization o f the n+½ loop attributed to Dahl [Knuth 1974]; it executes statements repeatedly until its w h i l e clause (if any) fails or until e x i t is used. (extend-syntax (loop w h i l e repeat) (exit) ((loop el e2 ... repeat) ( c a l l / c u (1-mhda (exit) ( (label foo (1-minds () el e2 ... (foo))))))) ((loop el ... w h i l e p e2 ... repeat) ( c a 1 1 / c c ( l a m b d a (exit) ( (label foo ( 1 - m h d a () el ... (unless p (exit #f) ) e2 ... (foo))))))))
In this example l o o p , w h i l e , and r e p e a t are keywords and should not be confused with possible variable references; e x i t is bound by the macro but is intended for use in the argument forms of the macro call. The name f o o is not intended for such use, and the hygienic macro expander will rename it if necessary to avoid name clashes. (Note that you have to try hard to make a name available; the default is to play it safe, which makes e x t e n d - s y n t a x easier and safer for novice macro writers to use.) Note the use of the idiom " e l e2 . . . " to require that at least one form is present if there is no w h i l e clause. Syntactic closures were proposed in 1988 by Alan Bawden and Jonathan Rees [Bawden 1988]. Their idea bears a strong resemblance to the expansion-passing technique of Dybvig, Friedman, and Haynes [Dybvig 1986] but is more general. Syntactic contexts are represented not by the automatically managed tags of hygienic macro expansion but by environment objects; one may "close" a piece of code with respect to such a syntactic environment, thereby giving the macro writer explicit control over the correspondence between one occurrence of a symbol and another. Syntactic closures provide great power and flexibility but put the burden on the programmer to use them properly. In 1990, William Clinger (who used to be at Indiana University) joined forces with Rees to propose a grand synthesis that combines the benefits of hygienic macros and syntactic closures, with the added advantage of running in linear rather than quadratic time. Their technique is called, appropriately enough, "macros; that work" [Clinger 1991 ]. The key insight may be explained by analogy to reduction in the lambda ca]~culus [Church 1941 ]. Sometimes the rule of tx-conversion must be applied to rename variables in a lambda-caiculus expression so that a subsequent W-reduction will not produce a name clash. One cannot do such renaming all at once; it is necessary to intersperse renaming with the 13-reductions, because a W-reduction can make two copies of a lambda-expression (hence both bind the same name) and bnng the binding of one into conflict with that of the other. The same is true of macros: it is necessary to intersperse renaming with macro expansion. The contribution of Clinger and Rees was to clarify this problem and provide a fast, complete solution. The Scheme standard [IEEE 1991] was adopted without a macro facility, so confusion still officially reigns on this point. Macros remain an active research topic. Why are mac~rosso important to Lisp programmers? Not merely for the syntactic convenience they provide, but also because they are programs that manipulate programs, which has always been a central theme in the Lisp community. If FORTRAN is the language that pushes numbers around, and C is the language that pushes characters and pointers around, then Lisp is the language that pushes programs around. Its data structures are useful for representing and manipulating program text. The 282
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
macro is the most immediate example of a program written in a metalanguage. Because Lisp is its own metalanguage, the power of the entire programming language can be brought to bear on the task of transforming program text. By comparison, the C preprocessor is completely anemic; the macro language consists entirely of substitution and token concatenation. There are conditionals, and one may conditionally define a macro, but a C macro may not expand into such a conditional. There is neither recursion nor metarecursion, which is to say that a C macro can neither invoke itself nor define another macro. Lisp users find this laughable. They are very much concerned with the programming process as an object of discourse and an object of computation, and they insist on having the best possible means of expression for this purpose. Why settle for anything less than the full programming language itself? (We say this not only to illustrate the character of Lisp, but also to illustrate the character of Lispers. The Lisp community is motivated, in part, by a attitude of superiority to the competition, which might be another programming language or another dialect of Lisp.) 6.3.4
Numerical Facilities
In Lisp 1.6 and through PDP-6 Lisp, most Lisp systems offered at most single-word fi xnums (integers) and single-word flonums (floating-point numbers). (PDP-1 Lisp [Deutsch 1964] had only fixnums; apparently the same is true of the M-460 Lisp [Hart 1964]. Lisp 1.5 on the 7090 had floating-point [McCarthy 1962], as did Q-32 Lisp [Saunders 1964b] and PDP-6 Lisp [PDP-6 Lisp 1967].) We are still a little uncertain about the origin of bignums (a data type that uses a variable amount of storage to represent arbitrarily large integer values, subject to the total size of the heap, which is where bignums are stored). They seem to have appeared in MacLisp and Stanford Lisp 1.6 at roughly the same time, and perhaps also in Standard Lisp. They were needed for symbolic algebra programs such as REDUCE [Hearn 1971 ] and MACSYMA [Mathlab Group 1977]. Nowadays the handling of bignums is a distinguishing feature of Lisp, though not an absolute requirement. Both the Scheme Standard [IEEE 1991 ] and Common Lisp [CLTL2 1990] require them. Usually the algorithms detailed in Knuth Volume 2 are used [Knuth 1969, 1981 ]. Jon L White wrote a paper about a set of primitives that allow one to code most of bignum arithmetic efficiently in Lisp, instead of having to code the whole thing in assembly language [White 1986]. There is also a literature on BIGFLOAT arithmetic. It has been used in symbolic algebra systems [Mathlab Group 1977], but has not become a fixture of Lisp dialects. Lisp is often used as a platform for this kind of research because having bignums gets you 2/3 of the way there [Boehm 1986; Vuiilemin 1988]. The MacLisp functions HAULONG and HAIPART were introduced to support MACSYMA's bigfloat arithmetic; these became the Common Lisp functions INTEGER-LENGTH and (by way of Lisp-Machine Lisp) LDB. In the 1980s the developers of Common Lisp grappled with the introduction of the IEEE floating-point standard [IEEE 1985]. (It is notable that, as of this writing, most other high-level programming languages have n o t grappled seriously with the IEEE floating-point standard. Indeed, ANSI X3J3 (FORTRAN) rejected an explicit request to do so.) Although Lisp is not usually thought of as a numerical programming language, there were three strong influences in that direction: MACSYMA, the S-I project, and Gerald Sussman. The first good numerical Lisp compiler was developed for the MACSYMA group [Golden 1970; Steele 1977b, 1977c]; it was important to them and their users that numerical code be both fast and compact. The result was a Lisp compiler that was competitive with the DEC PDP-10 FORTRAN compiler [Fateman 1973].
LISP SESSION
283
GUY L. STEELE JR. & RICHARD R GABRIEL
The S-I was initially intended to be a fast signal processor. One of the envisioned applications was detection of submarines, which seemed to require a mix of numerical signal processing and artificial intelligence techniques. The project received advice from W. Kahan in the design of its floating-point arithmetic, so it ended up being quite similar to the eventual IEEE standard. It seemed appropriate to refine the techniques of the MacLisp compiler to produce good numerical code in S-I Lisp [Brooks 1982b]. The S-I offered four different floating-point formats (18, 36, 72, and 144 bits) [Correl11979]. Influenced by S-I Lisp, Common Lisp provides an expanded system of floating-point data types to accommodate such architectural variation. The inclusion of complex numbers in Common Lisp was also an inheritance from the S-1. This was something ,af a sticking point with Scott Fahlman. A running joke was an acceptance test for nascent Common Lisp implementations developed by Steele. It was in three parts. First you type T; if it responds T, it passes part 1. Second, you define the f a c t o r i a l function and then calculate (/ (factorial i000)
(factorial 999))
If it responds 10 0 0, it passes part 2. Third, you try ( a t a n h - 2 ). If it returns a complex number, it passes; extra credit if it returns the correct complex number. It was a long time before any Common Lisp implementation passed the third part. Steele broke an implementation or two on the trade-show floor with this three-part test. Gerald Sussman and his students (including Gerald Roylance and Matthew Haifant) became interested in numerical applications and in the use of Lisp to generate and transform numerical programs [Sussman 1988; Roylance 1988]. Sussman also spent a fair amount of time at MIT teaching Lisp to undergraduates. Sussman thought it was absolutely crazy to have to tell students that the quotient of 1 0 . 0 and 4 . 0 was 2 . 5 but the quotient of 10 and 4 was 2. Of course, nearly all other programming languages have the same problem (Pascal [Jensen 1974] and its derivatives being notable exceptions), but that is no excuse; Lisp aspires to better things, and centuries of mathematical precedent should outweigh the few decades of temporary aberration in the field of computers. At Sussman's urging, the / function was defined to return rationals when necessary, so ( / 10 4 ) in Common Lisp produces 5 / 2 . (This was not considered a radical change to the language. Rational numbers were already in use in symbolic algebra systems. The developers of Common Lisp were simply integrating into the language functionality frequently required by their clients, anyway.) All this provoked another debate, for in MacLisp and its descendants the slash was the characterquoter; moreow~r, backslash was the remainder operator. The committee eventually decided to swap the roles of slash and backslash, so that slash became alphabetic and backslash became the character quoter, thus allowing the division operation to be written " / " instead of " / / " and allowing rational numbers to be written in conventional notation. This also solved some problems caused by a then little-known and little-loved (in the Lisp community) operating system called Unix, which used backslash as a character-quoter and slash in file names. However, it was a major incompatible change from MacLisp and Zetalisp, which left Common Lisp open to criticism. Of course, this left Common Lisp without a truncating integer division operation, which is occasionally useful. Inspired by the many rounding modes of the S-1 [Correll 1979; Hailpern 1979] (which were influenced in turn by Kahan), Steele added four versions of the integer division operation to Common Lisp--- t r u n c a t e , r o u n d , c e i l i n g , and f l o o r , each of which accepts either one or two arguments and returns a quotient and remainder--thus bettering even Pascal. Overall, Common Lisp provides a much richer set of numerical primitives, and pays even closer attention to such details as the branch cuts of complex trigonometric functions, than FORTRAN ever has.
284
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
6.3.5 Some Notable Failures Despite Lisp's tendency to absorb new features over time, both from other programming languages and from experiments within the Lisp community, there are a few ideas that have been tried repeatedly in various forms but for some reason simply don't catch on in the Lisp community. Notable among these ideas are ALGOL-style syntax, generalized multiple values, and logic programming with unification of variables.
6.3.5.1
Algol-StyleSyntax
Ever since Steve Russell first hand-coded an implementation of EVAL, S-expressions have been the standard notation for writing programs. In almost any Lisp system of the last thirty years, one could write the function UNION (which computes the union of two sets represented as lists of elements) in roughly the following form: (defun u n i o n (x y) (cond ((null x) y) ( ( m e m b e r (car x) y) (union (cdr x) y)) (t (cons (car x) (union (cdr x) y)))))
The original intention, however, in the design of Lisp was that programs would be written as M-expressions; the S-expression syntax was intended only for representation of data. The UNION function in M-expression notation looks like this: union[xty]
=
[nu11[x]-~y; m e m b e r [c a r [x] ; y] -....->union[cdr [x] ;y] ; T--~cons [car [x] ; u n i o n [ c d r [x] ;y] ] ]
But as McCarthy [1981] noted: The unexpected appearance of an interpreter tended to freeze the form of the language . . . . The project of defining M-expressions precisely.., was neither finalized nor completely abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation [i.e., S-expressions] to any Fortran-like or Algol-like notation that could be devised. Yet that was not the end of the story. Since that time there have been many other efforts to provide Lisp with an ALGOL-like syntax. Time and again a Lisp user or implementor has felt a lack in the language and provided a solution--and not infrequently attracted a substantial group of users--and yet in the long run none of these has achieved acceptance. The earliest example of this--after M-expressions, of course--appears to have been Henneman's A-language [Henneman 1964]. Henneman gives the following definition of UNION: (DEFINE U N I O N (OF AND) (8) ( U N I O N O F X A N D Y) (IF X IS E M P T Y T H E N Y E L S E IF F I R S T OF X IS A M E M B E R OF Y T H E N U N I O N OF REST OF X AND Y ELSE CONNECT FIRST OF X TO BEGIN U N I O N OF R E S T O F X A N D Y
END))
LISP SESSION
285
GUY L. STEELE JR. & RICHARD R GABRIEL
The number 8 in this definition is the precedence of the UNION operator; note the use of BEGIN and END as parenthetical delimiters, necessary because the CONNECT... T O . . . operator (which means CONS) has higher precedence. We find it curious that Henneman went to the trouble of pretty-printing the M-expressions and S-expressions in his paper but presented all his examples of A-language in the sort of run-on, block-paragraph slLyleoften seen in the S-expressions of his contemporaries. Nowadays we would format such a pro~;ram in this manner for clarity: U N I O N (OF AND) (UNION O F X A N D Y)
(8)
(DEFINE
(IF X ELSE
I S ]IMPTY T H E N Y I F LPIRST O F X I S A M E M B E R O F Y THEIR U N I O N O F R E S T O F X A N D Y
ELSE
COk3~ECT F I R S T B]~GIN U N I O N
OF OF
X TO
R E S T OF X A N D
Y END
))
Such formatting was not unheard of; the ALGOL programmers of the day used similar indentation conventions in their published programs. The ARPA-supported LISP 2 project aimed at providing Lisp with a syntax resembling that of ALGOL 60, citing the advantage that "ALGOL algorithms can be utilized with little change" [Abrahams 1966]. LISP 2 code for UNION in the style of our running example would look like this: S Y M B O L F U N C T I O N UNION(X, IF
NULL
X THEN
ELSE
IF MEMBER(CAR
ELSE
CAR
X
Y);
S Y M B O L X, Y;
Y X,
. UNION(CDR
Y)
THEN
X,
UNION(CDR
X,
Y)
Y) ;
However, contemr~rary examples of LISP 2 code seem to emphasize the use of loops over recursion, so the following version might be more typical of the intended style: SYMBOL
F U N C T I O N UNION(X,
Y);
S Y M B O L X, Y;
BEGIN SYMBOL FOR IF
A
Z +-- Y; IN
NOT
RETURN
X DO ]~EMBER(A,
Y)
THEN
Z ~-- A
. Z;
Z;
END;
(Of course, this version produces a result that is different when regarded as a list, although the same when regarded as a set.) The EL1 language was designed by Ben Wegbreit as part of his Ph.D. research [Wegbreit 1970]. It may be loosely characterized as a Lisp with an ALGOL-like surface syntax and strong data typing. A complete programming system called ECL was built around ELI at Harvard in the early 1970s [Wegbreit 1971, 1!972, 1974]. The UNION function in EL1 looks like this: u n i o n y; M E M B E R ( C A R ( x ) , y) => union(CDR(x), y) ; C O N S ( C A R ( X ) , u n i o n ( C D R ( x ) , y)) (];
286
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
Note the type declarations of x, y, and the result as type FORM (pointer to dotted pair). The digraphs [ ) and ( ] are equivalent to BEGIN and END (they looked better on a Model 33 Teletype than they do here). Within a block the arrow = > indicates the conditional return of a value from the block, resulting in a notation reminiscent of McCarthy's conditional notation for M-expressions. Lisp itself was not widely used at Harvard's Center for Research in Computing Technology at that time; EL1 and PPL (Polymorphic Programming Language, a somewhat more JOSS-like interactive system) may have been Harvard's answer to Lisp at the time. ECL might have survived longer if Wegbreit had not left Harvard for Xerox in the middle of the project. As it was, ECL was used for research and course work at Harvard throughout the 1970s. We have already discussed Teitelman's CLISP (Conversational Lisp), which was part of Interlisp [Teitelman 1974]. The function UNION was built into Interlisp, but could have been defined using CLISP in this manner: DEFINEQ((UNION ( L A M B D A (X Y) (IF -X T H E N Y ELSEIF X=i MEMBER Y THEN UNION E L S E < X : I ! ( U N I O N X: :I Y)>I
X::i Y
In CLISP, ~ is a unary operator meaning NOT or NULL. X: n is element n of the list X, so X : 1 means (CAR X) ; similarly X: : 1 means (CDR X). The function MEMBER is predefined by CLISP to be an infix operator, but UNION is not (though the user may so define it if desired). Angle brackets indicate construction of a list; ! within such a list indicates splicing, so means (CONS A B). Finally, the use of a final ] to indicate the necessary number of closing parentheses (four, in this case), although not a feature of CLISP proper, is consistent with the Interlisp style. MLISP was an ALGOL-like syntax for Lisp, first implemented for the IBM 360 by Horace Enea and then re-implemented for the PDP-10 under Stanford Lisp 1.6 [Smith 1970]. It provided infix operators; a complex FOR construct for iteration; various subscripting notations such as A ( 1, 3 ) (element of a two-dimensional array) and L [ 1, 3 , 2 ] (equivalent to ( e a d r (eaddr (car L) ) ) ); "vector" operations (a concise notation for MAPCAR); and destructuring assignment. E X P R U N I O N (X,Y); I F -~X T H E N Y E L S E I F X[I] E Y T H E N U N I O N ( X ~ I , Y ) E L S E X[i] C O N S U N I O N ( X $ 1 , Y ) ;
~MLISP
version
of U N I O N
Vaughan Pratt developed an ALGOL-style notation for Lisp called CGOL [Pratt 1973]. Rather than embedding algebraic syntax within S-expressions, CGOL employed a separate full-blown tokenizer and parser. This was first implemented for Stanford Lisp 1.6 in 1970 when Pratt was at Stanford; at this time there was an exchange of ideas with the MLISP project. After Pratt went to MIT shortly thereafter, he implemented a version for MacLisp [Pratt 1976]. Versions of this parser were also used in the symbolic algebra systems SCRATCHPAD at IBM Yorktown and MACSYMA at MIT's Project MAC; Fred Blair, who also developed LISP370, did the reimplementation for SCRATCHPAD, and Michael Genesereth did it for MACSYMA. Our CGOL version of the rJNION function deft nes it as an in fix operator (the num bers 14 and 13 are left and right "binding powers" for the parser): define
x
if n o t
"UNION" x then
y,
14,
13;
y
e l s e if m A m h e r ( c a r x, y) t h e n c d r x u n i o n else car x . cdr x union y 0
LISP SESSION
y
287
GUY L. STEELE JR, & RICHARD R GABRIEL
Here we have assumed the version of CGOL implemented at MIT, which stuck to the standard ASCII character set; the :same definition using the Stanford extended character set would be: d e f i n e x "L;" y, 14, if -~x t h e n y e l s e
13; if ~ x
E
y then
~x u
y else
~x
. ~x U
y
0
The " . " repre.sents C O N S in both preceding examples; the delimiter 0 (actually the ASCII "altmode" character, nowadays called "escape") indicates the end of a top level expression. All unary Lisp functions are unary operators in CGOL, including CAR and CDR. In the definition preceding we have relied on the fact that such unary operators have very high precedence, so c d r x u n i o n y means ( c d r x ) u n i o n y, not c d r ( x u n i o n y ) . We also carefully chose the binding powers for UNION relative to " . " so that the last expression would be parsed as ( c a r x ) ( ( cdr x) u n i o n y ) ). It is not obvious that this is the best choice; Henneman chose to give CONS (in the form of CONNECT... T O . . . ) higher precedence than UNION. Pratt remarked [1976]: If you want to use the CGOL notation but don't want to have anything to do with binding powers, simply parenthesize every CGOL expression as though you were writing in Lisp. However, if you omit all parentheses you will not often go wrong• •
.
.
Compare this to Henneman's remark [1964]: The one great cause of most of the inco~ect results obtained in practice is an incorrect precedence being assigned to a function. During the 1970s a number of "AI languages" were designed to provide specific programming constructs then thought to be helpful in writing programs for AI applications• Some of these were embedded within Lisp and therefore simply inherited Lisp syntax (and in some cases influenced Lisp syntax--see Section 6.4 for a discussion of these). Those that were not embedded usually had a syntax related to that of ALGOL, while including some of the other features of Lisp (such as symbolic data structures and recursive functions). Among these were POP-2 [Burstall 1971 ], SAIL [Feldman 1972], and the Pascal-based TELOS [Travis 1977]. The idea of introducing ALGOL-like syntax into Lisp keeps popping up and has seldom failed to create enormous controversy between those who find the universal use of S-expressions a technical advantage (and don't mind the admitted relative clumsiness of S-expressions for numerical expressions) and those who are certain that algebraic syntax is more concise, more convenient, or even more natural (whatever that may mean, considering that all these notations are artificial). We conjecture ~lhatALGOL-style syntax has not really caught on in the Lisp community as a whole for two reasons• ]?irst, there are not enough special symbols to go around. When your domain of discourse is limited to numbers or characters, there are only so many operations of interest, so it is not difficult to assign one special character to each and be done with it. But Lisp has a much richer domain of discourse, and a Lisp programmer often approaches an application as yet another exercise in language design; the style typically involves designing new data structures and new functions to operate on them---perhaps dozens or hundreds--and it's too hard to invent that many distinct symbols (though the APL community certainly has tried). Ultimately one must always fall back on a general function-call notation; it's just that Lisp programmers don't wait until they fail. Second, and perhaps more important, ALGOL-style syntax makes programs look less like the data structures used to represent them. In a culture where the ability to manipulate representations of programs is a central paradigm, a notation that distances the appearance of a program from the appearance of its representation as data is not likely to be warmly received (and this was, and is, one of the principal objections to the inclusion of l o o p in Common Lisp).
288
CHAPTER Vl
PAPER:THE EVOLUTION OF LISP
On the other hand, precisely because Lisp makes it easy to play with program representations, it is always easy for the novice to experiment with alternative notations. Therefore we expect future generations of Lisp programmers to continue to reinvent ALGOL-style syntax for Lisp, over and over and over again, and we are equally confident that they will continue, after an initial period of infatuation, to reject it. (Perhaps this process should be regarded as a rite of passage for Lisp hackers.) 6.3.5.2
Generalized Multiple Values
Many Lisp extenders have independently gone down the following path. Sometimes it is desirable to return more than one item from a function. It is awkward to return some of the results through global variables, and inefficient to cons up a list of the results (pushing the system that much closer to its next garbage collection) when we know perfectly well that they could be returned in machine registers or pushed onto the machine control stack. Curiously, the prototypical example of a function that ought to return two results is not symbolic but numerical: integer division might conveniently return both a quotient and a remainder. (Actually, it would be just as convenient for the programmer to use two separate functions, but we know perfectly well that the computation of one produces the other practically for free--again it is an efficiency issue.) Suppose, then, that some primitive means of producing multiple values is provided. One way is to introduce new functions and/or special forms. Common Lisp, for example, following Lisp-Machine Lisp, has a primitive function called VALUES; the result of ( v a l u e s 3 4 5 ) is the three numbers 3, 4, and 5. The special form (multiple-value-bind
(p q r)
(foo) body)
executes its body with the variables p, q, and r locally bound to three values returned as the value of the form ( f o o ) . But this is all so ad hoc and inelegant. Perhaps multiple values can be made to emerge from the intrinsic structure of the language itself. Suppose, for example, that the body of a lambda expression were an implicit VALUES construct, returning the values of all its subforms, rather than an implicit PROGN, returning the values of only the last subform. That takes care of producing multiple values. Suppose further that function calls were redefined to use all the values returned by each subform, rather than just one value from each subform. Then one could write ((1-mhda
(quo rein) ...)
(/ 44 6))
thereby binding qaxo to the quotient 7 and rein to the remainder 2. That takes care of consuming multiple values. All very simple and tidy! Oops, two details to take care of. First, returning to lambda expressions, we see that, for consistency, they need to return all the values of all the subforms, not just one value from each subform. So the form ((Immhda
(quo rein) (/ quo rein) (/ rem quo))
(/ 44 6))
returns four values: 3, 1, 0, and 2. Second, there is still a need for sequencing forms that have side effects such as assignment. The simple solution is to make such forms as ( s e t q x 0) and (print x ) return zero values, so that ((1-mhda
(quo rem)
(print quo) rem)
(/ 44 6))
returns only the remainder 2 after printing the quotient 7. This all has a very simple and attractive stack-based implementation. Primitives simply push all their values, one after another, onto the stack. At the start of the processing for a function call, place a marker on the stack; after all subforms have
LISP SESSION
289
GUY L. STEELE JFI. & RICHARD P. GABRIEL
been processed, .,;imply search the stack for the most recent marker; everything above it should be used as argument~; for the function call--but be sure to remove or cancel the marker before transferring control to the function. Yes, this is all very neat and tidy--and as soon as you try to use it, you find that code becomes much, much harder to understand, both for the maintainer and for the compiler. Even if the programmer has the discipline not to write (cons
(/
44L 6 )
(setq
x 0))
which returns (7 2 ) after setting x to 0, the compiler can never be sure that no such atrocities lurk in the code it is processing. In the absence of fairly complete information about how many values are produced by ~mch function, including all user-defined functions, a compiler cannot verify that a function call will supply the correct number of arguments. An important practical check for Lisp programming errors is thus made all but impossible. Conditionals i]atroduce two further problems. First: what shall be the interpretation of (if (foo)
(bar))
if ( f o o ) returns ~twovalues? Shall the second value be discarded, or treated as the value to be returned if the first value is true? Perhaps the predicate should be required to return exactly one value. Very well, but there remains the fact that the two subforms might return different numbers of values: ( i f ( f o o ) 3 ( / 44 6) ) might return the single value 3 or the multiple values 7 and 2. It follows immediately that no compiler, even if presented with a complete program, can deduce in general how many values are returned by each function call; it is formally undecidable. Now all this might seem to be entirely in the spirit of Lisp as a weakly typed language; if the types of the values returned by functions may not be determinable until run time, why not their very cardinality? And declarations might indicate the number of values where efficiency is important, just as type declarations already assist many Lisp compilers. Nevertheless, as a matter of fact, nearly everyone who has', followed this path has given up at this point in the development, muttering, "This way madness lies," and returned home rather than fall into the tarpit. We ourselves have independently followed this line of thought and have had conversations with quite a few other l~¢ople who have also done so. There are few published sources we can cite, however, precisely because most of them eventually judged it a bad idea before publishing anything about it. (This is not to say that it actually is a bad idea, or that some variation cannot eliminate its disadvantages; he,re we wish merely to emphasize the similarity of thinking among many independent researchers.) Among the most notable efforts that did produce actual implementations before eventual abandonment are SEUS and POP-2 [Burstall 1971 ]. The designers and implementors of SEUS (Len Bosack, Ralph Goren, David Posner, William Scherlis, Carolyn Talcott, Richard Weyhrauch, and Gabriel) never published their results, although it was a novel language design, and had a fast, compiler- and microcode-based implementation, complete with programming environment. POP-2 was regarded by its designers as an AI language, one of the many produced in the late 1960s and eady 1970s, rather than as a variant of Lisp; it enjoyed some popularity in Europe and was used to implement the logic programming language POPLOG [Mellish 1984]. 6.3.5.3
LogicProgramming and Unification
During the 1970s and on into the 1980s there have been a number of attempts to integrate the advantages of the two perhaps foremost AI programming language families, Lisp and Prolog, into a single language. Such efforts were a feature of the software side of the Japanese Fifth Generation
290
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
project. Examples of this are Robinson's LOGLISP [Robinson 1982], the TAO project [Takeuchi 1983; Okuno 1984], and TABLOG [Malachi 1984]. There have also been related attempts to integrate functional programming and Prolog. (All these should be contrasted with the use of Lisp as a convenient language for implementingProlog, as exemplified by Komorowski's QLOG [Komorowski 1982] and the work of Kahn and Carisson [Kahn 1984].) We conjecture that this idea has not caught on in the Lisp community because of unification, the variable-matching process used in Prolog. Indeed one can easily design a language that has many of the features of Lisp but uses unification during procedure calls. The problem is that unification is sufficiently different in nature from lambda-binding that the resulting language doesn't really feel like Lisp any more. To the average Lisp programmer, it feels like an extension of Prolog but not an extension of Lisp; you just can't mess around that much with something as fundamental as procedure calls. On the other hand, one can leave Lisp procedure calls as they are and provide unification as a separate facility that can be explicitly invoked. But then it is just another Lisp library routine, and the result doesn't feel at all like Prolog. 6.4
LISP AS A LANGUAGE LABORATORY
An interesting aspect of the Lisp culture, in contrast to those surrounding most other programming languages, is that toy dialects are regarded with a fair amount of respect. Lisp has been used throughout its history as a language laboratory. It is trivial to add a few new functions to Lisp in such a way that they look like system-provided facilities. Given macros, CLISP, or the equivalent, it is pretty easy to add new control structures or other syntactic constructs. If that fails, it is the work of only half an hour to write, in Lisp, a complete interpreter for a new dialect. To see how amazing this is, imagine starting with a working C, FORTRAN, Pascal, PL/I, BASIC, or APL system--you can write and run any program in that language, but have no access to source code for the compiler or interpreter--and then tackling these exercises: 1. Add a new arithmetic operator to the language similar to the one for Pythagorean addition in Knuth's Metafont language [Knuth 1986]: a÷+b computes x / ~ - . The language is to be augmented in such a way that the new operator is syntactically similar to the language operators for addition and subtraction. (For C, you ma.~.,use ÷÷÷ or O rather than ÷÷; for APL, use one of the customary awful overstrikes such as W.) 2. Add a c a s e statement to the language. (If it already has a c a s e statement, then add a statement called s w i t c h that is just like the c a s e statement already in the language, except that when the selected branch has been executed, control falls through to succeeding branches; a special b r e a k statement, or dropping out of the last branch, must be used to terminate execution of the s w i t c h statement.) 3. Add full lexically scoped functional closures to the language. Without source code for the compiler or interpreter, all three projects require one practically to start over from scratch. That is part of our point. But even given source code for a FORTRAN compiler or APL interpreter, all three exercises are much more difficult than in Lisp. The Lisp answer to the first one is a one-liner (shown here in Common Lisp): (defun ++
(x y)
(sqrt
(+ (* x x)
(* y y))))
Lisp does not reserve special syntax (such as infix operators) for use by built-in operations, so user-defined functions look just like system-defined functions to the caller.
LISP SESSION
291
GUY L. STEELE JR. & RICHARD R GABRIEL
The second requires about a dozen lines of code (again, in Common Lisp, using backquote syntax as described in the discussion of macros): (defmacro
switch
(value &rest body)
(let* ( (:newbody (mapcar #' (l~mhda
(switcher
(clause) '(,(gensym) ,@(rest clause))) body) ) (mapcar #' (l~mhda (clause newclause) ' (, (first clause) (go , (first newclause)) )) body newbody) ) )
• (block switch (tagbody (case ,value ,@switcher) (break) ,@(apply #'nconc newbody) ) ) ) (defmacro break () ' (return-from switch) )
Here we use two macros, one for s w i t c h and one for b r e a k , which together cause the statement (switch n (0 (princ (1 (princ (2 (princ (3 (princ
"none") (break)) "one ")) "too ")) "many") ) )
(which always prints either many, t o o many,
one
too
m a n y , none,
or nothing) to expand into
(block switch (tagbody (case n (0 (go o 0 0 4 2 ) )
(1 (go G0043) (2 ( g o 0 0 0 4 4 ) ) (3 ( g o 0 0 0 4 5 ) ) ) 00042 00043 00044 G0045
(return-from switch) (princ "none" ) (return-from switch) (princ "one ") (princ "too ") (princ "many" ) ) )
which is not unlike the code that would be produced by a C compiler. For examples of interpreters that solve the third problem in about 100 lines of code, see Steele 1978c and 1978b. There is a rich tradition of experimenting with augmentations of Lisp, ranging from "let's add just one new feature" to inventing completely new languages using Lisp as an implementation language. This activity was carried on particularly intensively at MIT during the late 1960s and the 1970s and also at other institutions such as Stanford University, Carnegie-Mellon University, and Indiana University. At that time it was customary to make a set of ideas about programming style concrete by putting forth a new programming language as an exemplar. (This was true outside the Lisp community as well; witness the proliferation of ALGOL-like, and particularly Pascal-inspired, languages around the same time period. But Lisp made it convenient to try out little ideas with a small amount of overhead, as well as tackling grand revampings requiring many man-months of effort.) One of the earliest Lisp-based languages was METEOR [Bobrow 1964], a version of COMIT with Lisp syntax. COMIT [MIT RLE 1962a, 1962b; Yngve 1972] was a pattern-matching language that 292
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
repeatedly matched a set of rules against the contents of a flat, linear workspace of symbolic tokens; it was a precursor of SNOBOL and an ancestor of such rule-based languages as OPS5 [Forgy 1977]. METEOR was embedded within the MIT Lisp 1.5 system that ran on the IBM 7090. The Lisp code for METEOR is a little under 300 80-column cards (some with more whitespace than others). By contrast, the 7090 implementation of the COMIT interpreter occupied about 10,000 words or memory, according to Yngve; assuming this reflects about 10,000 lines of assembly language code, we can view this as an early example of the effectiveness of LISP as a high-level language for prototyping other languages. Another of the early pattern-matching languages built on Lisp was CONVERT [Guzman 1966]. Whereas METEOR was pretty much a straight implementation of COMIT represented as Lisp data structures, CONVERT merged the pattern-matching features of COMIT with the recursive data structures of Lisp, allowing the matching of recursively defined patterns to arbitrary Lisp data structures. Carl Hewitt designed an extremely ambitious Lisp-like language for theorem-proving called Planner [Hewitt 1969, 1972]. Its primary contributions consisted of advances in pattern-directed invocation and the use of automatic backtracking as an implementation mechanism for goal-directed search. It was never completely implemented as originally envisioned, but it spurred three other important developments in the history of Lisp: Micro-Planner, Muddle, and Conniver. Gerald Jay Sussman, Drew McDermott, and Eugene Charniak implemented a subset of Planner called Micro-Planner [Sussman 1971 ], which was embedded within the MIT PDP-6 Lisp system that eventually became MacLisp. The semantics of the language as implemented were not completely formalized. The implementation techniques were rather ad hoc and did not work correctly in certain complicated cases; the matcher was designed to match two patterns, each of which might contain variables, but did not use a complete unification algorithm. (Much later, Sussman, on learning about Prolog, remarked to Steele that Prolog appeared to be the first correct implementation of Micro-Planner.) A version of Planner was also implemented in POP-2 [Davies 1984]. The language Muddle (later MDL) was an extended version of Lisp and in some ways a competitor, designed and used by the Dynamic Modeling Group at MIT, which was separate from the MIT AI Laboratory but in the same building at 545 Technology Square. This effort was begun in late 1970 by Gerald Jay Sussman, Carl Hewitt, Chris Reeve, and David Cressey, later joined by Bruce Daniels, Greg Pfister, and Stu Galley. It was designed " . . . as a successor to Lisp, a candidate vehicle for the Dynamic Modeling System, and a possible base for implementation of Planner-70" [Galley 1975]. To some extent, the competition between Muddle and Lisp, and the fact that Sussman had a foot in each camp, resulted in cross-fertilization. The I/O, interrupt handling, and multiprogramming (that is, coroutining) facilities of Muddle were much more advanced than those of MacLisp at the time. Muddle had a more complex garbage collector than PDP-10 MacLisp ever had, as well as a larger library of application subroutines, especially for graphics. (Some Lisp partisans at the time would reply that Muddle was used entirely to code libraries of subroutines but no main programs! But in fact some substantial applications were coded in Muddle.) Muddle introduced the lambda-list syntax markers OPTIONAL, REST, and AUX that were later adopted by Conniver, Lisp-Machine Lisp, and Common Lisp. The language Conniver was designed by Drew McDermott and Gerald Jay Sussman in 1972 in reaction to perceived limitations of Micro-Planner and in particular of its control structure. In the classic paper Why Conniving Is Better Than Planning [Sussman 1972a, 1972b], they argued that
LISP SESSION
293
GUY L. STEELE JR. & RICHARD P. GABRIEL
automatic nested backtracking was merely an overly complicated way to express a set of F O R A L L loops used to perform exhaustive search: It is our contention that the backtrack control structure that is the backbone of Planner is more of a hindrance in the solution of problems than a help. In particular, automatic backtracking encourages inefficient algorithms, conceals what is happening from the user, and misleads him with primitives having powerful names whose power is only superficial. The design of Conniver put the flow of control very explicitly in the hands of the programmer. The model was an extreme generalization of coroutines; there was only one active locus of control, but arbitrarily many logical threads and primitives for explicitly transferring the active locus from one to another. This design was strongly influenced by the "spaghetti stack" model introduced by Daniel Bobrow and Ben Wegbreit [Bobrow 1973] and implemented in BBN-Lisp (later to be known as Interlisp). Like spaghetti stacks, Conniver provided separate notions of a data environment and a control environment and the possibility of creating closures over either. (Later work with the Scheme language brought out the point that data environments and control environments do not play symmetrical roles in the interpretation of Lisp-like languages [Steele 1977d].) Conniver differed from spaghetti stacks in ways stemming primarily from implementation considerations. The main point of Conniver was generality and ease of implementation; it was written in Lisp and represented control and data environments as Lisp list structures, allowing the Lisp garbage collector to handle reclamation of abandoned environments. The implementation of spaghetti stacks, on the other hand, involved structural changes to a Lisp system at the lowest level. It addressed efficiency issues by allowing stack-like allocation and deallocation behavior wherever possible. The policy was pay as you go but don't pay if you don't use it: programs that do not create closures should not pay for the overhead of heap management of control and data environments. At about this time Carl Hewitt and his students began to develop the actor model of computation, in which every computational entity, whether program or data, is an actor: an agent that can receive and react to messages. The under-the-table activity brought out by Conniver was made even more explicit in this model; everything was message-passing; everything ran on continuations. Hewitt and his student Brian Smith commented on the interaction of a number of research groups at the time [Smith 1975]: The early work on PLANNER was done at MIT and published in IJCAI-69 [Hewitt 1969]. In 1970 a group of interrested researchers (including Peter Deutsch, Richard Fikes, Carl Hewitt, Jeff Rulifson, Alan Kay, Jim Moore, Nils Nilsson, and Richard Waldinger) gathered at Pajaro Dunes to compare notes and concepts. . . . In November 1972, Alan Kay gave a seminar at MIT in which he emphasized the importance of using intentional definitions of data structures and of passing messages to them such as was done to a limited extent for the "procedural data structures" in the lambda calculus languages of Landin, Evans, and Reynolds and extensively in SIMULA-67. His argument was that only the data type itself really "knows" how to implement any given operation. We had previously given some attention to procedural data structures in our own research. . . . However, we were under the misconception that procedural data structures were too inefficient for practical use although they had certain advantages. Kay's lecture struck a responsive note... We immediately saw how to use his idea.., to extend the principle of procedural embedding of knowledge to data structures. In effect each type of data structure becomes a little plan of what to do for each kind of request that it receives . . . . Kay proposed a language called SMALLTALK with a token stream oriented interpreter to implement these ideas . . . .
294
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
[At that time,] Peter Bishop and Carl Hewitt were working to try to obtain a general solution to the control structure problems which had continued to plague PLANNER-like problem solving systems for some years. Sussman had proposed a solution oriented around "possibility lists" which we felt had very serious weaknesses . . . . Simply looking at their contents using t r y - n e x t can cause unfortunate global side-effects • . . [which] make Conniver programs hard to debug and understand. The token streams of Smalltalk have the same side-effect problem as the possibility lists of Conniver. After the lecture, Hewitt pointed out to Kay the control structure problems involved in his scheme for a token stream oriented interpreter. By December 1972, we succeeded in generalizing the message mechanism of Smalitalk and SIMULA-67; the port mechanism of Krutar, Balzer, and Mitchell; and the previous CALL statement of PLANNER-71 to a universal communication mechanism. Our generalization solved the control structure problems that Hewitt pointed out to Kay in the design of SMALLTALK. We developed the actor transmission communication primitive as part of a new language-independent, machine-independent, behavioral model of computation. The development of the actor model of computation and its ramifications is our principal original contribution to this area of research . . . . The following were the main influences on the development of the actor model of computation: •
The suggestion by [Alan] Kay that procedural embedding be extended to cover data structures in the context of our previous attempts to generalize the work by Church, Landin, Evans, and Reynolds on "functional data structures."
•
The context of our previous attempts to clean up and generalize the work on corouti ne control structures of Landin, Mitchell, Krutar, Balzer, Reynolds, Bobrow-Wegbreit, and Sussman.
•
The influence of Seymour Papert's "little man" metaphor for computation in LOGO.
•
The limitations and complexities of capability-based protection schemes. Every actor transmission is in effect an inter-domain call efficiently providing an intrinsic protection on actor machines.
•
The experience developing previous generations of PLANNER. Essentially the whole PLANNER-71 language (together with some extensions) was implemented by Julian Davies in POP-2 at the University of Edinburgh.
In terms of the actor model of computation, control structure is simply a pattern of passing messages . . . . Actor control structure has the following advantages over that of Conniver: •
A serious problem with the Conniver approach to control structure is that the programmer (whether human or machine) must think in terms of low level data structures such as activation records or possibility links. The actor approach allows the programmer to think in terms of the behavior of objects that naturally occur in the domain being programmed . . . .
•
Actor transmission is entirely free of side-effects . . . .
•
The control mechanisms of Conniver violate principles of modularity.... Dijkstra has remarked that the use of the g o t o is associated with badly structured programs. We concur in this judgement but feel that the reason is that the g o t o is not a sufficiently powerful primitive. The problem with the g o t o is that a message cannot be sent along with control to the target . . . .
•
Because of its primitive control structures, Conniver programs are difficult to write and debug . . . . Conniver programs are prone to going into infinite loops for no reason that is very apparent to the programmer.
Nevertheless Conniver represents a substantial advance over Micro-Planner in increasing the generality of goal-oriented computations that can be easily performed. However, this increase in generality comes at the price of lowering the level of the language of problem solving. It forces users to think in low level implementation terms such as "possibility lists" and "a-links." We propose a shift in the paradigm of problem solving to be one of a society of individuals communicating by passing messages.
LISP SESSION
295
GUY L. STEELE JR. & RICHARD R GABRIEL
We have quoted Smith and Hewitt at length for three reasons: because their comparative analysis is very explicit; because the passage illustrates the many connections among different ideas floating around in the AI, Lisp, and other programming language communities; and because this particular point in the evolution of ideas represented a distillation that soon fed back quickly and powerfully into the evolution of Lisp itself. (For a more recent perspective, see [Hewitt 1991 ].) Hewitt and his students (notably Russ Atkinson, Peter Bishop, Mike Freiling, Irene Greif, Roger Hale, Ken Kahn, Benjamin Kuipers, Todd Matson, Marilyn McLennan, Keith Nishihara, Howie Shrobe, Brian Smith, Richard Stieger, Kathy Van Sant, and Aki Yonizawa) developed and implemented in MacLisp a new language to make concrete the actor model of computation. This language was first called Planner-73 but the name was later changed to PLASMA (PLAnner-like System Modeled on Actors) [Hewitt 1975; Smith 1975]. Although the syntax of PLASMA was recognizably Lisp-like, it made use of several kinds of parentheses and brackets (as did Muddle) as well as many other special characters. It is reasonable to assume that Hewitt was tempted by the possibilities of the then newly available Knight keyboard and Xerox Graphics Printer (XGP) printer. (The keyboards, designed by Tom Knight of the MIT AI Lab, were the MIT equivalent of the extended-ASCII keyboards developed years earlier at the Stanford A! Laboratory. Like the Stanford keyboards, Knight keyboards had Control and Meta keys (which were soon pressed into service in the development of the command set for the EMACS text editor) and a set of graphics that included such exotic characters as ct, I~, and 5. The XGP, at 200 dots per inch, made possible the printing of such exotic characters.) The recursive factorial function looked like this in PLASMA: [factorial (cases (~> [0] 1) (~> [=n] (n * (factorial
(n-
i)))))]
Note the use of infix arithmetic operators. This was not merely clever syntax, but clever semantics; (n - 1 ) really meant that a message containing the subtraction operator and the number 1 was to be sent to the number/actor/object named by n. One may argue that Lisp development at MIT took two distinct paths during the 1970s. In the first path, MacLisp was the workhorse tool, coded in assembly language for maximum efficiency and compactness, serving the needs of the AI Laboratory and the MACSYMA group. The second path consisted of an extended dialogue/competition/argument between Hewitt (and his students) and Sussman (and his students), with both sides drawing in ideas from the rest of the world and spinning some off as well. This second path was characterized by a quest for "the right thing," where each new set of ideas was exemplified in the form of a new language, usually implemented on top of a Lisp-like language (MacLisp or Muddle) for the sake of rapid prototyping and experimentation. The next round in the Hewitt/Sussman dialogue was, of course, Scheme (as discussed in Section 6.2.8); in hindsight, we observe that this development seems to have ended the dialogue, perhaps because it brought the entire path of exploration full circle. Starting from Lisp, they sought to explicate issues of search, of control structures, of models of computation, and finally came back simply to good old Lisp, but with a difference: lexical scoping---closures, in short--were needed to make Lisp compatible with the lambda calculus, not merely in syntax but also in semantics, thereby connecting it firmly with various developments in mathematical logic and paving the way for the Lisp community to interact with developments in functional programming.
296
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
Hewitt had noted that the actor model could capture the salient aspects of the lambda calculus; Scheme demonstrated that the iambda calculus captured nearly all salient aspects (excepting only side effects and synchronization) of the actor model. Sussman and Steele began to look fairly intensely at the semantics of Lisp-like as well as actor-based languages in this new light. Scheme was so much simpler even than Lisp 1.5, once one accepted the overheads of maintaining lexical environments and closures, that one could write a complete interpreter for it in Lisp on a single sheet of paper (or in two 30-line screenfuls). This allowed for extremely rapid experimentation with language and implementation ideas; at one point Sussman and Steele were testing and measuring as many as ten new interpreters a week. Some of their results were summarized in The Art of the Interpreter [Steele 1978b]. A particular point of interest was the comparison of call-by-name and call-by-value parameters; in this they were influenced by work at Indiana University discussed in the paper CONS Should Not Evaluate Its Arguments [Friedman 1975]. Besides being itself susceptible to rapid mutation, Scheme has also served as an implementation base for rapid prototyping of yet other languages. One popular technique among theoreticians for formally describing the meaning of a language is to give a denotational semantics, which describes the meaning of each construct in terms of its parts and their relationships; iambda calculus is the glue of this notation. Although Scheme showed that a properly designed Lisp gave one all the flexibility (if not all the syntax) one needed in managing control structure and message-passing, it did not solve the other goal of the development of Lisp-based AI languages: the automatic management of goal-directed search or of theorem proving. After Scheme, a few new Lisp-based languages were developed in this direction by Sussman and his students, including constraint-based systems [Sussman 1975a; Stailman 1976; Steele 1979; de Kleer 1978b] and truth maintenance systems [de Kleer 1978a; McAIlester 1978] based on nonmonotonic logic. The technique of dependency-directed backtracking eliminated the "giant nest of FORALL loops" effect of chronological backtracking. Over time this line of research became more of a database design problem than a language design problem, and has not yet resulted in feedback to the mainstream evolution of Lisp. Development of languages for artificial intelligence applications continued at other sites, however, and Lisp has remained the vehicle of choice for implementing them. During the early 1980s C became the alternative of choice for a while, especially where efficiency was a major concern. Improvements in Lisp implementation techniques, particularly in compilation and garbage collection, have swung that particular pendulum back a bit. During the AI boom of the early 1980s, "expert systems" was the buzzword; this was usually understood to mean rule-based systems written in languages superficially not very different from METEOR or CONVERT. OPS5 was one of the better-known rule-based languages of this period; XCON (an expert system for configuring VAX installations, developed by Carnegie-Mellon University for Digital Equipment Corporation) was its premier application success story. OPS5 was first implemented in Lisp; later it was recoded for efficiency in BLISS [Wulf 1971] (a CMU-developed and DEC-supported systems implementation language at about the same semantic level as C). Another important category of AI languagess was frame-based; a good example was KRL (Knowledge Representation Language), which was implemented in Interlisp. Another line of experimentation in Lisp is in the area of parallelism. Although early developments included facilities for interrupt handling and multiprogramming, true multiprocessing evolved only with the availability of appropriate hardware facilities (in some cases built for the purpose). S-1 Lisp [Brooks 1982a] was designed to use the multiple processors of an S- 1 system, but (like so many other
LISP SESSION
297
GUY L. STEELE JR. & RICHARD P. GABRIEL
features of S-1 Lisp) that part never really worked. Some of the most important early "real" parallel Lisp implementations were Multilisp, Qlisp, and Butterfly PSL. Multilisp [Halstead 1984, 1985] was the work of Bert Halstead and his students at MIT. Based on Scheme, it relied primarily on the notion of a future, which is a sort of laundry ticket, a promise to deliver a value later once it has been computed. Multilisp also provided a p e a l i construct, essentially a function call that evaluates the arguments concurrently (and completely) before invoking the function. Thus p e a l 1 provides a certain structured discipline for the use of futures that is adequate for many purposes. Multilisp ran on the Concert multiprocessor, a collection of 32 Motorola 68000 processors. MultiScheme, a descendant of Multilisp, was later implemented for the BBN Butterfly [Miller 1987]. Butterfly PSL [Swanson 1988] was an implementation of Portable Standard Lisp [Griss 1982] on the BBN Butterfly. It also relied entirely on futures for the spawning of parallel processes. Qlisp [Gabriel 1984b; Goldman 1988] was developed by Richard Gabriel and John McCarthy at Stanford. It extended Common Lisp with a number of parallel control structures that parallel (pun intended) existing Common Lisp control constructs, notably q l e t , q l a m b d a , and c / c a t c h . The computational model involved a global queue of processes and a means of spawning processes and controlling their interaction and resource consumption. For example, q l a m b d a could produce three kinds of functions: normal ones, as produced by l a m b d a ; eager ones, which would spawn a separate process when created; and delayed ones, which would spawn a separate process when invoked. Qlisp was implemented on the Alliant FX8 and was the first compiled parallel Lisp implementation. Connection Machine Lisp [Steele 1986] was a dialect of Common Lisp extended with a new data structure, the xapping intended to support fine-grain data parallelism. A xapping was implementationally a strange hybrid of array, hash table, and association list; semantically it is a set of ordered index-value pairs. The primitives of the language are geared toward processing all the values of a xapping concurrently, matching up values from different xappings by their associated indices. The idea was that indices are labels for virtual processors. To recapitulate: Lisp is an excellent laboratory for language experimentation for two reasons. First, one can choose a very small subset, with only a dozen primitives or so, that is still recognizably a member of the class of Lisp-like languages. It is very easy to bootstrap such a small language, with variations of choice, on a new platform. If it looks promising, one can flesh out the long laundry list of amenities later. Second, it is particularly easy--the work of an hour or less--to bootstrap such a new dialect within an existing Lisp implementation. Even if the host implementation differs in fundamental ways from the new dialect, it can provide primitive operations such as arithmetic and I/O as well as being a programming language that is just plain convenient for writing language interpreters. If you can live with the generic, list-structure-oriented syntax, you can have a field day reprogramming the semantics. After you get that right there is time enough to re-engineer it and, if you must, slap a parser on the front.
6.5
WHY LISP IS DIVERSE
In this history of the evolution of Lisp, we have seen that Lisp seems to have a more elaborate and complex history than languages with wider usage. It would seem that almost every little research group has its own version of Lisp and there would appear to be as many Lisps as variations on language concepts. It is natural to ask what is so special or different about Lisp that explains it. There are six basic reasons: its theoretical foundations, its expressiveness, its malleability, its interactive and incremental nature, its operating system facilities, and the people who choose it.
298
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
Its theoretical foundations. Lisp was founded on the footing of recursive function theory and the theory of computability. The work on Scheme aligned it with Church's lambda calculus and denotational semantics. Its purest form is useful for mathematical reasoning and proof. Therefore, many theoretically minded researchers have adopted Lisp or Lisp-like languages in which to express their ideas and to do their work. We thus see many Lisp-oriented papers with new language constructs explained, existing constructs explained, properties of programs proved, and proof techniques explored. The upshot is that Lisp and Lisp-like languages are always in the forefront of basic language research. And it is common for more practically minded theoretical researchers to also implement their ideas in Lisp. Its expressiveness. Lisp has proved itself con::erned more with expressiveness than anything else. We can see this more obliquely by observing that only a person well-versed with how a particular Lisp is implemented can write efficient programs. Here is a perfectly nice piece of code: (defun make-matrlx (n m) (let ((matrix ())) (dotimes (i n matrix) (push (make-list m) matrix) ) ) ) (defun add-matrix (ml m2) (let ((11 (length ml)) (12 (length m2) ) ) (let ( (matrix (make-matrix 11 12) )) (dotimes (i 11 matrix) (dotimes (J 12) (setf (nth i (nth J matrix)) (÷ (nth i (nth J ml)) (nth i (nth j m2)))))))))
The expression to read and write a cell in a matrix looks perfectly harmless and fast as anything. But it is slow, because n t h takes time proportional to the value of its first argument, essentially CDaing down the list every time it is called. (An experienced Lisp coder would iterate over the cells of a list rather than over numeric indices, or would use arrays instead of lists.) Here expressiveness has gone awry. People tend to expect that operations in the language cost a small unit time, not something complicated to figure out. But this expectation is false for a sufficiently expressive language. When the primitives are at a sufficiently high level, there is enough wiggle room underneath to permit a choice of implementation strategies. Lisp implementors continue to explore that space of strategies. Precisely because Lisp is so expressive, it can be very hard to write fast programs (though it is easy to write pretty or clear ones). Its malleability. It is easy with Lisp to experiment with new language features, because it is possible to extend Lisp in such a way that the extensions are indistinguishable to users from the base language. Primarily this is accomplished through the use of macros, which have been part of Lisp since 1963 [Hart 1963]. Lisp macros, with their use of Lisp as a computation engine to compute expansions, have proved to be a more effective way to extend a language than the string-processing mechanisms of other languages. Such macro-based extensions are accepted within the Lisp community in a way that is not found in other language communities. Furthermore, more recent Lisp dialects have provided mechanisms to extend the type system. This enables people to experiment with new data types. Of course, other languages have had this mechanism, but in Lisp the data typing mechanism combines with the powerful macro facility and LISP SESSION
299
GUY L. STEELE JR. & RICHARD R GABRIEL
the functional nature of the language to allow entirely new computing paradigms to be built in Lisp. For example, we have seen data-driven paradigms [Sussman 1971], possible-worlds paradigms [McDermott 1974], and object-oriented paradigms [Moon 1986; Bobrow 1986] implemented in Lisp in such a way that the seams between Lisp and these new paradigms are essentially invisible. Its interactive and incremental nature. It is easy to explore the solutions to programming problems in Lisp, because it is easy to implement part of a solution, test it, modify it, change design, and debug the changes. There is no lengthy edit-compile-link cycle. Because of this, Lisp is useful for rapid prototyping and for constructing very large programs in the face of an incomplete--and possibly impossible to complete---plan of attack. Therefore, Lisp has often been used for exploring territory that is too imposing with other languages. This characteristic of Lisp makes it attractive to the adventuresome and pioneering. Its operating system facilities. Many Lisp implementations provide facilities reminiscent of operating systems: a command processor, an automatic storage management facility, file management, display (windows, graphics, mouse) facilities, multitasking, a compiler, an incremental (re)linker/loader, a symbolic debugger, performance monitoring, and sometimes multiprocessing. It is possible to do operating system research in Lisp and to provide a complete operating environment. Combined with its interactive and incremental nature, it is possible to write sophisticated text editors and to supplant the native operating system of the host computer. A Lisp system can provide an operating environment that provides strong portability across a wide variety of incompatible platforms. This makes Lisp an attractive vehicle for researchers and thereby further diversifies Lisp. Its people. Of course, languages do not diversify themselves; people diversify languages. The five preceding factors merely serve to attract people to Lisp and provide facilities for them to experiment with Lisp. If the people attracted to Lisp were not interested in exploring new language alternatives, then Lisp would not have been diversified, so there must be something about Lisp that attracts adventuresome people. Lisp is the language of artificial intelligence, among other things. And AI is a branch of computer science that is directed towards exploring the most difficult and exotic of all programming tasks: mimicking or understanding cognition and intelligence. (Recall that symbolic computation, now a field of its own, was at many institutions originally considered a branch of AI.) The people who are attracted to AI are generally creative and bold, and the language designers and implementors follow in this mold, often being AI researchers or former AI researchers themselves. Lisp provides its peculiar set of characteristics because those features--or ones like them--were required for the early advances of AI. Only when AI was the subject of commercial concerns did AI companies turn to languages other than Lisp. Another attraction is that Lisp is a language of experts, which for our purposes means that Lisp is not a language designed for inexpert programmers to code robust reliable software. Therefore, there is little compile-time type checking, there are few module systems, there is little safety or discipline built into the language. It is an "anarchic" language, whereas most other languages are "fascist" (as hackers would have it [Raymond 1991]). Here are how some others have put it: LISP is unusual, in the sense that it clearly deviates from every other type of programming language that has ever been developed. . . . The theoretical concepts and implications of LISP far transcend its practical usage. pJean E. Sammet [ 1969, p. 406]
300
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
This is one of the great advantage of Lisp-like languages: They have very few ways of forming compound expressions, and almost no syntactic structure . . . . After a short time we forget about syntactic details of the language (because there are none) and get on with the real issues. --Abelson and Sussman [1985, p. xvii] Syntactic sugar causes cancer of the semicolon. - - A l a n Perlis What I like about Lisp is that you can feel the bits between your toes. - - D r e w McDermott [ 1977] Lisp has such a simple syntax and semantics that parsing can be treated as an elementary task. Thus parsing technology plays almost no role in Lisp programs, and the construction of language processors is rarely an impediment to the rate of growth and change of large Lisp systems. - - A l a n Perlis (forward to Abelson [1985]) APL is like a beautiful diamond---flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud--it still looks like Lisp. --Joel Moses [1978?] Pascal is for building pyramids--imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms . . . . - - A l a n Pedis (forward to Abelson [1985]) Lisp is the medium of choice for people who enjoy free style and flexibility. --Gerald Jay Sussman (introduction to Friedman [1987], p. ix) Hey, Quux: Let's quit hacking this paper and hack Lisp instead! - - r p g (the final edit) [Gabriel 1992]
REFERENCES [Abeison, 1985] Abelson, Harold and Sussman, Gerald Jay, with Sussman, Julie. Structure and Interpretation of Computer Programs. Cambridge, MA: MIT Press, 1985. [Abrahams, 1966] Abrahams, Paul W., Barnett, Jeffrey A., Book, Erwin, Firth, Donna, Kemeny, Stanley L., Weissman, Clark, Hawkinson, Lowell, Levin, Michael I., and Saunders, Robert A. The LISP 2 programming language and system. In Proceedings ¢~fthe 1966AFIPS Fall Joint Computer Conference, voi. 29, San Francisco, CA, Nov. 1966, pp. 661--676. American Federation of Information Processing Societies. Washington, D. C.: Spartan Books, 1966. [ACM AIPL, 1977] Association for Computing Machinery. Proceedings of the Artificial Intelligence and Programming Languages Conference, Rochester, NY,Aug. 1977.ACM SIGPLAN Notices, 12:8, Aug. 1977.ACM SIGARTNewsletter, 64, Aug. 1977. [ACM LFE 1982] Association for Computing Machinery. Proceedings of the 1982 ACM Symposium on Lisp and Functional Programming, Pittsburgh, PA, Aug. 1982. [ACM LFI:~1984] Association for Computing Machinery. Proceedings of the 1984 ACM Symposium on Lisp and Functional Programming, Austin, Texas, Aug. 1984.
LISP SESSION
301
GUY L. STEELE JR. & RICHARD P. GABRIEL [ACM LFR 1986] Association for Computing Machinery. Proceedings of the 1986 ACM Conference on Lisp and Functional Programming, Cambridge, MA, Aug. 1986. [ACM LFP, 1988] Association for Computing Machinery. Proceedings of the 1988 ACM Conference on Lisp and Functional Programming, Snowbird, Utah, July 1988. [ACM OOPSLA, 1986] Association for Computing Machinery. Proceedings of the ACM Conference on Objected-Oriented Programming, Systems, Languages, and Applications ( OOPSLA '86), Portland, OR, Oct. ! 986. ACM SIGPLAN Notices, 21:11, Nov. 1986. [ACM PLDI, 1990] Association for Computing Machinery. Proceedings of the 1990 ACM SIGPLAN '90 Conference on Programming Language Design and Implementation, White Plains, NY, June 1990. A CM SIGPLAN Notices 25:6, June 1990. [ACM PSDE, 1984] Association for Computing Machinery. Proceedings of the ACM SIGSOFT/SIGPLAN Symposium on Practical Software Development Environments, Pittsburgh, PA, Apr. 1984. ACM SIGPLAN Notices, 19:5, May 1984; also ACM Software Engineering Notes, 9:3, May 1984. [Backus, 1978] Backus, John. Can programming be liberated from the yon Neumann style? A functional style and its algebra of programs. Communications of the ACM, 21:8, Aug. 1978, pp. 613-.-641, 1977 ACM Tudng Award Lecture. [Baker, 1978] Baker, Jr., Henry B. List processing in real time on a serial computer. Communications of the ACM, 21:4, Apr. 1978, pp. 280-294. [Bartley, 1986] Bartley, David H. and Jensen, John C. The implementation of PC Scheme. In [ACM LFP, 1986], pp. 86..-93. [Bawden, 1988] Bawden, Alan and Rees, Jonathan. Syntactic closures. In [ACM LFP, 1988], pp. 86-95. [Berkeley, 1964] Berkeley, Edmund C., and Bobrow, Daniel G., Eds. The Programming Language LISP: Its Operation and Applications. Information International, Inc., and Cambridge, MA: MIT Press, 1964. [Black, 1964] Black, Fischer. Styles of programming in LISP. In [Berkeley, 1964], pp. 96-107. [Bobrow, 1964] Bobrow, Daniel G. METEOR: A LISP interpreter for string transformations. In [Berkeley, 1964], pp. 161-190. [Bobrow, 1972] Bobrow, Robert J., Burton, Richard R., and Lewis, Daryle. 1972 Manual (An Extended Stanford LISP 1.6 System). Information and Computer Science Technical Report 21, University of California, Irvine, lrvine, CA, Oct. 1972. [Bobrow, 1973] Bobrow, Daniel G. and Wegbreit, Ben. A model and stack implementation of multiple environments. Communications of the ACM, 16:10, Oct. 1973, pp. 591-603. [Bobrow, 1986] Bobrow, Daniel G., Kahn, Kenneth, Kiczaies, Gregor, Masinter, Larry, Stefik, Mark, and Zdybel, Frank. CommonLoops: Merging Lisp and object-oriented programming. In [ACM OOPSLA, 1986], pp. 17-29. [Boehm, 1986] Boehm, Hans-L, Cartwright, Robert, Riggle, Mark, and O'Donnell, Michael J. Exact real arithmetic: A case study in higher order programming. In [ACM LFP, 1986], pp. 162-173. [Brooks, 1982a] Brooks, Rodney A., Gabriel, Richard P., and Steele, Jr., Guy L. S-1 Common Lisp implementation. In [ACM LFP, 1982], pp. 108-113. [Brooks, 1982b] Brooks, Rodney A., Gabriel, Richard P., and Steele, Guy L., Jr. An optimizing compiler for lexically scoped LISP. In Proceedings of the 1982 Symposium on Compiler Construction, Boston, June 1982, pp. 261-275. Association for Computing Machinery. ACM SIGPLAN Notices, 17:6, June 1982. [Brooks, 1984] Brooks, Rodney A. and Gabriel, Richard P. A critique of Common Lisp. In [ACM LFP, 1984], pp. 1-8. [Burke, 1983] Burke, G. S., Carrette, G. J., and Eliot, C. R. NIL Reference Manual. Report MIT/LCS/TR-311, MIT Laboratory for Computer Science, Cambridge, Massachusetts, 1983. [Burstall, 1971] Burstall, R. M., Collins, J. S., and Popplestone, R. J., Eds. Programming in POP-2. Edinburgh University Press, 1971. [Campbell, 1984] Campbell, J. A., Ed. Implementations ofProlog. Chicbester: Ellis Horwood Limited, 1984. Also published by John Wiley & Sons, New York. [Church, 1941] Church, Alonzo. The Calculi of Lambda Conversion. Annals of Mathematics Studies 6. Princeton, N J: Princeton University Press, 1941. Reprinted by Klans Reprint Corp., New York, 1965. [Clark, 1982] Clark, K. L. and Titrnlund, S.-A., Eds. Logic Programming. New York: Academic Press, 1982. [Clinger, 1984] Clinger, William. The Scheme 311 compiler: An exercise in denotational semantics. In [ACM LFP, 1984], pp. 356-364. [Clinger, 1985a] Clinger, William, Ed. The Revised Revised Report on Scheme; or, An Uncomnum Lisp. AI Memo 848, MIT Artificial Intelligence Laboratory, Cambridge, MA, Aug. 1985. [Clinger, 1985b] Clinger, William, Ed.. The Revised Revised Report on Scheme; or, An Uncommon Lisp. Computer Science Department Tech. Rep. 174, Indiana University, Bloomington, June 1985. [Clinger, 1988] Clinger, William D., Hartbeimer, Anne H., and Ost, Eric M. Implementation strategies for continuations. In [ACM LFR 1988], pp. 124-131. [Clinger, 1990] Clinger, William D. How to read floating point numbers accurately. In [ACM PLDi, 1990], pp. 92-101.
302
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP [Clinger, 1991] Clinger, William, and Rees, Jonathan. Macros that work. In Proceedings of the Eighteenth Annual ACM Symposium on Principles of Programming Languages, Orlando, Florida, January 1991, pp. 155-162. Association for Computing Machinery. [CLTLI, 1984] Comnum Lisp: The Language. By Guy L. Steele, Jr., Scott E. Fahlman, Richard P. Gabriel, David A. Moon, and Daniel L. Weinreb. Burlington, MA: Digital Press, 1984. [CLTL2, 1990] Common Lisp: The Language (Second Edition). By Guy L. Steele, Jr., Scott E. Fahlman, Richard P. Gabriel, David A. Moon, Daniel L. Weiareb, Daniel G. Bobrow, Linda G. DeMichiel, Sonya E. Keene, Gregor Kiczales, Crispin Perdue, Kent M. Pitman, Richard C. Waters, and Jon L White. Bedford, MA: Digital Press, 1990. [Cohen, 1981] Cohen, Jacques. Garbage collection of linked data structures. ACM Computing Surveys, 13:3, Sept. 1981, pp. 341-367. [Correll, 1979] Correll, Steven. S-1 uniprocessor architecture (SMA-4). In The S-I Project 1979 AnnuaI Report, Vol. I, Chap. 4. Lawrence Livermore Laboratory, Livermore, CA, 1979. [Davies, 1984] Davies, J. POPLER: Implementation ofa POP-2-based PLANNER. In [Campbell, 1984], pp. 28-.-49. [DEC, 1964] Digital Equipment Corporation, Maynard, MA. Programmed Data Processor-6 Handbook, 1964. [DEC, 1969] Digital Equipment Corporation, Maynard, MA. PDP-IO Reference Handbook, 1969. [DEC, 1981] Digital Equipment Corporation, Maynard, MA. VAXArchitecture Handbook, 1981. [de Kleer, 1978a] de Kleer, Johan, Doyle, .Ion, Rich, Charles, Steele, Guy L., Jr., and Sussman, Gerald Jay. AMORD: A Deductive Procedure System. A1 Memo 435, MIT Artificial Intelligence Laboratory, Cambridge, MA, Jan. 1978. [de Kieer, 1978b] de Kleer, Johan, and Sussman, Gerald Jay. Propagation of Constraints Applied to Circuit Synthesis. AI Memo 485, MIT Artificial Intelligence Laboratory, Cambridge, MA, September 1978. Also in Circuit Theory andApplications, 8, 1980, pp. 127-144. [Deutsch, 1964] Deutsch, L. Peter, and Berkeley, Edmund C. The LISP implementation for the PDP- 1 computer. In [Berkeley, 1964], pp. 326-375. [Deutsch, 1973] Deutsch, L. Peter. A LISP machine with very compact programs. In [IJCAI, 1973], pp. 697-703. [Deutsch, 1976] Deutsch, L. Peter, and Bobrow, Daniel G. An efficient, incremental, automatic garbage collector. Communications of the ACM, 19:9, Sept. 1976, pp. 522-526. [Drescher, 1987] Drescher, Gary. ObjectLISP User Manual. LMI (LISP Machine, Inc.), Cambridge, Massachusetts, 1987. [Dybvig, 1986] Dybvig, R, Kent, Friedman, Daniel P., and Haynes, Christopher T. Expansion-passing style: Beyond conventional macros. In [ACM LFP, 1986], pp. 143-.-150. [Eastlake, 1968] Eastlake, D., Greenblatt, R., Hoiloway, .1., Knight, T., and Nelson, S. ITS 1.5 Reference Manual. AI Memo 161, MIT Artificial Intelligence Laboratory, Cambridge, MA, June 1968. Revised as AI Memo 161 A, July 1969. [Eastlake, 1972] Eastlake, Donald E. ITS Status Report. AI Memo 238, MIT Artificial Intelligence Laboratory, Cambridge, MA, Apr. 1972. [Fateman, 1973] Fateman, Richard J. Reply to an editorial. ACM SIGSAM Bulletin, 25, March 1973, pp. 9-1 I. This reports the results of a test in which a compiled MacLisp floating-point program was faster than equivalent FORTRAN code. The numerical portion of the code was identical and MacLisp used a faster subroutine-call protocol. [Feldman, 1972] Feldman, J. A., Low, J. R., Swinehart, D. C., and Taylor, R. H. Recent developments in SAIL. In Proceedings of the 1972 AFIPS Fall Joint Computer Conference 41, Stanford, CA, Nov. 1972, pp. 1193-1202. American Federation of Information Processing Societies. [Fessenden, 1983] Fessenden, Carol, Clinger, William, Friedman, Daniel E, and Haynes, Christopher. Scheme 311 Version 4 Reference Manual. Tech. Rep. 137, Indiana University, Feb. 1983. [Foderaro, 1982] Foderaro, J. K., and SHower, K. L. The FRANZLisp Manual. University of California, Berkeley, CA, Apr. 1982. [Forgy, 1977] Forgy, C., and McDermott, J. OPS, a domain-independent production system language. In Proceedings of the Fifth International Joint Conference on Artificial Intelligence (IJCAI-77), Cambridge, MA, 1977, pp. 933-935. International Joint Council on Artificial Intelligence. [Friedman, 1975] Friedman, Daniel P., and Wise, David S. CONS Stu~uld Not Evaluate Its Arguments. Tech. Rep. 44, Indiana University, Nov. 1975. [Friedman, 1987] Friedman, Daniel P., and Felleisen, Matthias. The Little LISPer. Trade edition. Cambridge, MA: MIT Press, 1987. Also published by Science Research Associates, Chicago, 3rd ed., 1989. [Gabriel, 1982] Gabriel, Richard P. and M&sinter,Larry M. Performance of Lisp systems. In [ACM LFE 1982], pp. 123-142. [Gabriel, 1984a] Gabriel, Richard P. and Frost, Martin E. A programming environment for a timeshared system. In [ACM PSDE, 1984], pp. 185-192. [Gabriel, 1984b] Gabriel, Richard P. and McCarthy, John. Queuc-b&sed multiprocessing Lisp. In [ACM LFP, 1984], pp. 25-.-44. [Gabriel, 1985] Gabriel, Richard P. Performance and Evaluation of Lisp Systems. Cambridge, MA: MIT Press, 1985.
LISP SESSION
303
GUY L. STEELE JR. & RICHARD R GABRIEL [Gabriel, 1988] Gabriel, Richard P. and Pitman, Kent M. Technical issues of separation in function cells and value cells. Lisp and Symbolic Computation, I:1, June 1988, pp. 81-101. [Gabriel, 1992] Gabriel, Richard E Personal communication to Guy L. Steele, Jr., Nov. 30, 1992 (two hours before handing off this manuscript to Federal Express). [Galley, 1975] Galley, S.W. and Pfister, Greg. The MDL Language. Programming Technology Division Document SYS.1 ! .01, MIT Project MAC, Cambridge, MA, Nov. 1975. [Geschke, 1977] Geschke, Charles M., Morris, Jr., James H., and Satterthwaite, Edwin H. Early experience with Mesa. Communications of the ACM, 20:8, Aug. 1977, pp. 540-553. [Golden, 1970] Golden, Jeffrey P. A User's Guide to the A. L Group LISCOM Lisp Compiler: Interim Report. AI Memo 210, MIT Project MAC, Cambridge, MA, Dec. 1970. [Goldman, 1988] Goldman, Ron and Gabriel, Richard P. Preliminary results with the initial implementation of Qlisp. In [ACM LFP, 1988], pp. 143-152. [Greenblatt, 1974] Greenblatt, Richard. The LISP Machine. Working Paper 79, M1T Artificial Intelligence Laboratory, Cambridge, MA, Nov. 1974. [Greussay, 1977] Greussay, E Contribution d la ddfinition interprdtive et d l'impldmentation des lambda-lungages. Tt~se d'Etat, Universit6 de Paris VI, Nov. 1977. [Gries, 1977] Gries, David. An exercise in proving parallel programs correct. Communications of the ACM, 20:12, Dec. 1977, pp. 921-930. [Griss, 1981] Griss, Martin L. and Hearn, Anthony C. A portable LISP compiler. S(~ftwarePractice and Experience, 11, 1981, pp. 541-605. [Griss, 1982] Griss, Martin L., Benson, Eric, and Maguire, Gerald Q., Jr. PSL: A portable LISP system. In [ACM LFP, 1982], pp. 88-97. [Guzman, 1966] Guzman, Adolfo and Mclntosh, Harold V. CONVERT. AI Memo 99, MIT Project MAC, Cambridge, MA, June 1966. [Hailpem, 1979] Hailpem, Brent T. and Hitson, Bruce L. S-1 Architecture Manual. Tech. Rep. 161 (STAN-CS-79-715), Department of Electrical Engineering, Stanford University, Stanford, California, Jan. 1979. [Halstead, 1984] Halstead, Robert H., Jr., Implementation of Halstead, 1985: Lisp on a multiprocessor. In [ACM LFE 1984], pp. 9-17. [Halstead, 1985] Halstead, Robert H., Jr., Multilisp: A language for concurrent symbolic computation. ACM Transactions on Programming Languages and System,v, 7:4, Oct. 1985, pp. 501-538. [Harbison, 1991] Harbison, Samuel P. and Steele, Jr., Guy L. C: A Reference Manual. 3rd ed., Englewood Cliffs, NJ: Prentice-Hall, 1991. [Hart, 1963] Hart, Timothy E MACRO Definitionsfi)r LISP. AI Memo 57, MIT Artificial Intelligence Project--RLE and MIT Computation Center, Cambridge, MA, Oct. 1963. [Hart, 1964] Hart, Timothy P. and Evans, Thomas G. Notes on implementing LISP for the M-460 computer In [Berkeley, 1964], pp. 191-203. [Hearn, 1971] Heam, A. C. REDUCE 2: A system and language for algebraic manipulation. In Proceedings of the Second Symposium on Symbolic and AIgebraic Manipulation, Los Angeles, Mar. 1971, pp. 128-133. [Henneman, 1964] Henneman, William. An auxiliary language for more natural expression--The A-language. In [Berkeley, 1964], pp. 239-248. [Hewitt, 1969] Hewitt, Carl. PLANNER: A language for proving theorems in robots. In Proceedings of the [First] International Joint Conference on Artificial Intelligence (IJCAI), W&shiugton, DC, May 1969, pp. 295-301. International Joint Council on Artificial Intelligence. [Hewitt, 1972] Hewitt, Carl. Descriptitm and Theoretical Analysis (Using Schemata) of PLANNER: A Language fi~r Proving Theoren~v and Manipulating Models in a Robot. MIT, Cambridge, MA, Apr. 1972. MIT Artificial Intelligence Laboratory TR-258. Ph.D. thesis. [Hewitt, 1975] Hewitt, Carl. How to use what you know. In Proceedings of the l~)urth International Joint Conference on Artificial Intelligence, vol. I, pp. 189-198, Tbilisi, Georgia, USSR, Sept. 1975. International Joint Council on Artificial Intelligence. Originally circulated as Working Paper 93, MIT Artificial Intelligence Laboratory, Cambridge, MA, May 1975. [Hewitt, 1991] Hewitt, Carl and lnman, Jeff. DA1 betwixt and between: From "intelligent agents" to open systems science. IEEE Transactions on Systems, Man, and Cybernetics, 21:6, Nov./Dec. 1991, pp. 1409-1419. [Hieb, 1990] Hieb, Robert, R., Dybvig, Kent, and Bruggeman, Carl. Representing control in the presence of first-class continuations. In [ACM PLDI, 1990], pp. 66-77. [IEEE, 1985] IEEE, New York. IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE STD 754-1985, 1985. An American National Standard.
304
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
[IEEB, 1991] 1EEE Computer Society, New York. IEEE Standard for the Scheme Programming Language, IEEE STD 1178-1990, 1991. [IJCAI, 1973] International Joint Council on Artificial Intelligence. Proceedings of the Third International Joint Conference on Artificial Intelligence (IJCAi3), Stanford, CA, Aug. 1973. [Iverson, 1962] Iverson, Kenneth E. A Programming Language. New York: Wiley,1962. [Jensen, 1974] Jansen, Kathlnen, and Wirth, Niklaus. Pascal User Manual and Report. New York: Springer-Verlag, 1974. [Kahn, 1984] Kahn, K. M., and Carlsson, M. How to implement Proiog on a LISP machine. In [Campbell, 1984], pp. 117-134. [Kempf, 1987] Kempf, James, Harris, Warren, D'Souza, Roy, and Snyder, Alan. Experience with CommonLoops. In Proceedings of the ACM Conference on Objected-Oriented Programming Systems, Languages, and Applications (OOPSLA '87), Orlando, FL, Oct. 1987, pp. 214.-226. Association for Computing Machinery. ACM SIGPLAN Notices, 22:12, Dec. 1987. [Kernighan, 1978] Kernighnn, Brian W. and Ritchie, Dennis. The C Programming Language. Englewood Cliffs, N J: PrenticeHall, 1978. [Knuth, 1969] Knuth, Donald E. Seminumerical Algorithms, Vol. 2 of The Art of Computer Programming. Reading, MA: Addison-Wesley, 1969. [Knuth, 1974] Knuth, Donald E. Structured programming with GO TO statements. Computing Surveys, 6:4, Dec. 1974, pp. 261-301. [Knuth, 1981] Knuth, Donald E. Seminamerical Algorithms (Second ed.), Vol. 2 of The Art of Computer Programming. Reading, MA: Addison-Wesley, 1981. [Knuth, 1986] Knuth, Donald E. The METAFONT Book, volume C of Computers and Typesetting. Reading, MA: AddisonWesley, 1986. [Kohlbecker, 1986a] Kohlbecker, Eugene, Friedman, Daniel P., Felleisen, Matthias, and Duba, Bruce. Hygienic macro expansion. In [ACM LFP, 1986], pp. 151-161. [Kohlbecker, 1986b] Kohlbecker, Eugene E., Jr., Syntactic Extensions in the Programming Language Lisp. Tech. Rep. 109, Indiana University, Aug. 1986. Ph.D. thesis. [Komorowski, 1982] Komorowski, H. J. QLOG: The programming environment for PROLOG in LISP. In [Clark, 1982], pp. 315-322. [Kranz, 1986] Kranz, David, Richard Kelsey, Rees, Jonathan, Hudak, Paul, Philbin, James, and Adams, Norman. ORBIT: An optimizing compiler for Scheme. In Proceedings of the 1986A CM SIG PLAN '86 Symposium on Compiler Construction, Palo Alto, CA, June 1986. Association for Computing Machinery. ACM SIGPILAN Notices, 21:7, July 1986, pp. 219-233. [Landin, 1964] Landin, Peter J. The mechanical evaluation of expressions. Computer Journal, 6:4, 1964. [Landin, 1965] l..andin, Peter J. A correspondence between ALGOL 60 and Church's lambda-notation. Communications of the ACM, 8:2-3, Feb.-Mar. 1965. [Lisp Archive] LzSIP ARCHZV.On-line archive of MacLisp release notes, 1969-1981, with entries by Jon L White, Guy L. St¢¢1¢ Jr., Howard 1. Cannon, Richard P. Gabriel, Richard M. Stallman, Eric C. Rosen, Richard Greenblatt, and Robert W. Kerns. [Lisp Conference, 1980] Conference Record of the 1980 LISP Conference, Stanford, CA, Aug. 1980. Republished by Association for Computing Machinery. [Malachi, 1984] Malachi, Yonathan, Manna, Zohar, and Waldinger, Richard. TABLOG: The deductive-tableau programming language. In [ACM LFR 1984], pp. 323-330. [Marti, 1979] Marti, J., A. C. Hearn, Gfiss, M. L., and Gfiss, C. Standard Lisp report. ACM SIGPLANNotices, 14:10, Oct. 1979, pp. 48-68. [Mathlab Group, 1977] Mathiab Group, The. MACSYMA Reference Manual (Version Nine). MIT Laboratory for Computer Science, Cambridge, MA, 1977. [McAIlester, 1978] McAllester, David A. A Three Valued Truth Maintenance System. AI Memo 473, MIT Artificial Intelligence Laboratory, Cambridge, MA, May 1978. [McCarthy, 1962] McCarthy, John, Abrahams, Paul W., Edwards, Daniel J., Hart, Timothy P., and Levin, Michael I. LISP 1.5 Programmer's Manual. Cambridge, MA: MIT Press, 1962. [McCarthy, 1980] McCarthy, John. Lisp: Notes on its past and future. In [Lisp Conference, 1980], pp. v-viii. [McCarthy, 1981] McCarthy, John. History of LISR In Wexelblat, Richard L., Ed., History of Programming Languages, ACM Monograph Series, Chapter IV, pp. 173-197. New York: Academic Press, 1981. (Final published version of the Proceedings oftbe ACM SIGPLAN History of Programming Languages Conference, Los Angeles, CA, June 1978.) [McDermott, 1974] McDermott, Drew V., and Sussman, Gerald Jay. The CONNIVER Reference Manual. AI Memo 295a, MIT Artificial Intelligence Laboratory, Cambridge, MA, Jan. 1974.
LISP SESSION
305
GUY L. STEELE JR. & RICHARD R GABRIEL
[McDermott, 1977] McDermott, Drew V. Oral remark at the ACM Symposium on Artificial Intelligence and Programming Languages, Rochester, NY, Aug. 1977, as recollected by Guy L. Steele, Jr. [McDermott, 1980] McDermott, Drew. An efficient environment allocation scheme in an interpreter for a lexically-scoped USE In [Lisp Conference, 1980], pp. 154---162. [Mellish, 1984] Mellish, C. and Hardy, S. Integrating Prolog in the POPLOG environment. In [Campbell, 1984], pp. 147-162. [Miller, 1987] Miller, James SIocum. MultiScheme: A Parallel Processing System Mased on MIT Scheme. Ph.D. thesis, MIT, Cambridge, MA, Aug. 1987. [MIT RLE, 1962a] MIT Research Laboratory of Electronics. Cambridge, MA: MIT Press. COMIT Programmers Reference Manual, June 1962. [MIT RLE, 1962b] M1T Research Laboratory of Electronics. Cambridge, MA: MIT Press. An Introduction to COMIT Programming, June 1962. [Moon, 1974] Moon, David A. MacLISP Reference Manual. M1T Project MAC, Cambridge, MA, Apr. 1974. [Moon, 1984] Moon, David A. Garbage collection in a large Lisp system. In [ACM LFR 1984], pp. 235-246. [Moon, 1986] Moon, David A. Object-oriented programming with flavors. In [ACM OOPSLA, 1986], pp. 1-8. [Moore, 1976] Moore, J. Strother, 11. The lnterLISP Virtual Machine Specification. Tech. Rep. CSL 76-5, Xerox Palo Alto Research Center, Palo Alto, California, Sept. 1976. [Moses, 1970] Moses, Joel. The Function of FUNCTION in LISP. AI Memo 199, MIT Artificial Intelligence Laboratory, Cambridge, MA, June 1970. [Moses, 1978?] Moses, Joel, as recalled (and probably paraphrased) by Guy L. Steele, Jr. There has been a persistent confusion in the literature about this remark. Some have reported that Moses said it while on a panel at the ACM APL 79 Conference. Moses denies having ever made that particular remark, however, and indeed Steele has heard him deny it. Steele, however, is equally certain that Moses did make such a remark--not at the APL conference, but while standing in the doorway of Steele and White's office, MIT room number NE43-834, circa 1978. Jon L White [personal communication to Steele, November 30, 1992] independently recalls having heard Moses comparing APL to a diamond and Lisp to a ball of mud on at least three separate occasions in that office building, once in NE43-834. The confusion will undoubtedly persist. [Naur, 1963] Nanr, Peter, FEd.,et al. Revised report on the algorithmic language ALGOL 60. Communications of the ACM, 6:1, Jan. 1963, pp. 1-20. [Okuno, 1984] Okuno, Hiroshi G., Takeuchi, Ikoo, Osato, Nobuyasu, Hibino, Yasushi, and Watanabe, Kazufumi. TAO: A fast interpreter-centered Lisp system on Lisp machine ELIS. In [ACM LFP, 1984], pp. 140-149. [Organick, ! 972] Organick, Elliot I. The Multics System: An Examination of Its Structure. Cambridge, MA: MIT Press, 1972. [Padget, 1986] Padget, Julian, et al. Desiderata for the standardisation of Lisp. In [ACM LFP, 1986], pp. 54-66. [PDP-6 Lisp, 1967] PDP-6 LISP (LISP 1.6). A1 Memo 116, MIT Project MAC, Cambridge, MA, Jan. 1967. Revised as Memo 116A, April 1967. The report does not hear the author's name, but Jeffrey P. Golden [Golden, 1970] attributes it to Jon L White. [Pitman, 1980] Pitman, Kent M. Special forms in Lisp. In [Lisp Conference, 1980], pp. 179-187. [Pitman, 1983] Pitman, Kent M. The RevisedMacLISP Manual. MIT/LCS/TR 295, MIT Laboratory for Computer Science, Cambridge, MA, May 1983. [Pratt, 1973] Pratt, Vanghan R. Top down operator precedence. In Proceedings of the ACM Symposium on Principles of Programming Languages, Boston, Oct. 1973, pp, 41-51. Association for Computing Machinery. [Pratt, 1976] Pratt, Vanghan R. CGOL: An Alternative E.rternal Representation for LISP Users. AI Working Paper 121, MIT Artificial Intelligence Laboratory, Cambddgu, MA, Mar. 1976. [Quam, 1972] Quam, Lynn H., and Diffie, Whitfield. Stanford LISP 1.6Manual. SAIL Operating Note 28.6, Stanford Artificial Intelligence Laboratory, Stanford, CA, 1972. [Raymond, 1991] Raymond, Eric, FEd.The New Hacker's Dictionary. Cambridge, MA: MIT Press, 1991. [Rees, 1982] Rees, Jonathan A. and Adams, Norman I., IV, T: A dialect of Lisp; or, LAMBDA: The ultimate software tool. In [ACM LFE 1982], pp. 114-122. [Rees, 1986] Rees, Jonathan, Clinger, William, et al. The revised3 report on the algorithmic language Scheme. ACM SIGPILAN Notices, 21:12, Dec. 1986, pp. 37-79. [Reynolds, 1972] Reynolds, John C. Definitional interpreters for higher order programming languages. In Proceedings of the ACM National Conference, Boston, Aug. 1972, pp. 717-740. Association for Computing Machinery. [Robinson, 1982] Robinson, .I.A. and Sibert, E. E. LOGLISP: Motivation, design, and implementation. In [Clark, 1982], pp. 299-313. [Roylance, 1988] Roylance, Gerald. Expressing mathematical subroutines constructively. In [ACM LFP, 1988], pp. 8-13. [Rudloe, 1962] Rudlee, H. Tape Editor. Program Write-up BBN-101, Cambridge, MA: Bolt Beranek and Newman Inc., Jan. 1962.
306
CHAPTER Vl
PAPER: THE EVOLUTION OF LISP
[Sabot, 1988] Sabot, Gary W. The Paralation Model: Architecture-Independent Parallel Ptt~gramming. Cambridge, MA: MIT Press, 1988. [Sammet, 1969] Jean E. Sammet. Programming Languages: History and Fundamentals. Englewood Cliffs, NJ: Prentice-Hall, 1969. [Sannders, 1964a] Sannders, Robert A. The LISP listing for the Q-32 compiler, and some samples. In [Berkeley, 1964], pp. 290-317. [Sannders, 1964b] Saanders, Robert A. The LISP system for the Q-32 computer. In [Berkeley, 1964], pp. 220-238. [Shaw, 1981] Shaw, Mary, Wulf, William A., and London, Ralph L. Abstraction and verification in AIphard: Iteration and generators. In Mary Shaw, Ed., ALPHARD: Form and Content, Chapter 3, pp. 73-116. New York: Spfinger-Vedag, 1981. [Smith, 1970] Smith, David Canfield. MLISP. Technical Report AIM-135, Stanford Artificial Intelligence Project, Oct. ! 970. [Smith, 1973] Smith, David Canfield and Enea, Horace J. Backtracking in MLISP2: An efficient backtracking method for LISE In [IJCAI, 1973], pp. 677-..685. [Smith, 1975] Smith, Brian C. and Hewitt, Carl. A PLASMA Primer. Working Paper 92, MIT Artificial Intelligence Laboratory, Cambridge, MA, Oct. 1975. [Sobalvarro, 1988] Sobalvarro, Patrick G. A Lifetime-based Garbage Collector for LISP Systems on General-Purpose Computers. Bachelor's Thesis, MIT, Cambridge, MA, Sept. 1988. [Stallman, 1976] Stallman, Richard M. and Sussman, Gerald Jay. Forward Reasoning and Dependency-Directed Backtracking in a System for Computer-Aided Circuit Analysis. AI Memo 380, MIT Artificial Intelligence Laboratory, Cambridge, MA, Sept. 1976. Also in Artificial Intelligence, 9, 1977, pp. 135-196. [Steele, 1975] Steele, Guy Lewis, Jr. Multiprocessing compacfifying garbage collection. Communications of the ACM, 18:9, Sept. 1975, pp. 495-508. [Steele, 1976a] Steele, Guy Lewis, Jr., and Sussman, Gerald Jay. LAMBDA: The Ultimate Imperative. AI Memo 353, MIT Artificial Intelligence Laboratory, Cambndge, MA, Mar. 1976. [Steele, 1976b] Steele, Guy Lewis, Jr. LAMBDA: The Ultimate Declarative. AI Memo 379, MIT Artificial Intelligence Laboratory, Cambridge, MA, Nov. 1976. [Steele, 1977a] Steele, Guy Lewis, Jr. Compiler Optimization BcLeedon Viewing LAMBDA as Rename plus Goto. Master's thesis, MIT, May 1977. Published as [Steele, 1978a]. [Steele, 1977b] Steele, Guy Lewis, Jr. Data representations in PDP- 10 MacLISE In Proceedings of the 1977 MACSYMA Users" Conference, Washington, DC, July 1977, pp. 203-214. NASA Scientific and Technical Information Office. Also published as AI Memo 420, MIT Artificial Intelligence Laboratory, Cambndge, MA, Sept. 1977. [Steele, 1977c] Steele, Guy Lewis, Jr. Fast arithmetic in Maclisp. In Proceedings of the 1977MACSYMA Users' Conference, Washington, DC, July 1977, pp. 215-224. NASA Scientific and Technical Information Office. Also published as AI Memo 421, MIT Artificial Intelligence Laboratory, Cambridge, MA, Sept. 1977. [Steele, ! 977d] Steele, Guy L., Jr. Macaroni is better than spaghetti. In [ACM AIPL, 1977], pp. 60-66. [Steele, 1977e] Steele, Guy Lewis, Jr. Debunking the 'expensive procedure call' myth; or, Procedure call implementations considered harmful; or, LAMBDA: The ultimate GOTO. In Proceedings of the ACM National Conference, Seattle, Oct. i 977, pp. 153-162. Association for Computing Machinery. Revised version published as AI Memo 443, MIT Artificial Intelligence Laboratory, Cambridge, MA, Oct. 1977. [Steele, 1978a] Steele, Guy Lewis, Jr. A Compiler for SCHEME (A Study in Compiler Optimization). Tech. Rep. 474, MIT Artificial Intelligence Laboratory, May 1978. This is a revised version of the author's master's thesis [Steele, 1977a]. [Steele, 1978b] Steele, Guy Lewis, Jr., and Sussman, Gerald Jay. The Art offthe Interpreter; or, The Modularity Complex (Parts Zero, One, and Two). AI Memo 453, MIT Artificial Intelligence Laboratory, Cambridge, Massachusetts, May 1978. [Steele, 1978c] Steele, Guy Lewis, Jr. and Sussman, Gerald Jay. The Revised Report on SCHEME: A Dialect of LISP. AI Memo 452, MIT Artificial Intelligence Laboratory, Cambridge, MA, Jan. 1978. [Steele, 1979] Steele, Guy Lewis, Jr. and Sussman, Gerald Jay. Constraints. In Proceedings of the APL 79 Conference, Rochester, NY, June 1979, pp. 208-225. Association for Computing Machinery. APL Quote Qund, 9:4, June 1979. Also pubfished as AI Memo 502, MIT Artificial Intelligence Laboratory, Cambridge, MA, Nov. 1978. [Steele, 1980] Steele, Guy Lewis, Jr. and Sussman, Gerald Jay. The dream of a lifetime: A lazy variable extent mechanism. In [Lisp Conference, 1980], pp. 163-172. [Steele, 1982] Steele, Guy L., Jr. An overview of Common Lisp. In [ACM LFP, 1982], pp. 98-107. [Steele, 1986] Steele, Guy L., Jr. and Hillis, W. Daniel. Connection Machine Lisp: Fine-grained parallel symbolic processing. In [ACM LFR 1986], pp. 279-297. [Steele, 1990a] Steele, Guy L., Jr. Making &synchronous parallelism safe for the world. In Proceedings of the Seventeenth Annual ACM Symposium on Principles of Programming Languages, San Francisco, Jan. 1990, pp. 218-231. Association for Computing Machinery.
LISP SESSION
307
GUY L. STEELE JR. & RICHARD R GABRIEL
[Steele, 1990b] Steele, Guy L., Jr. and White, Jan L. How to print floating-point numbers accurately. In [ACM PLDI, 1990], pp. 112-126. [Sussman, 1971] Sussman, Gerald Jay, Winograd, Terry, and Chamiak, Eugene. Micro-PLANNER Reference Manual. AI Memo 203A, MIT Artificial Intelligence Laboratory, Cambridge, MA, Dec. 1971. [Sussman, 1972a] Sussman, Gerald Jay and McDermott, Drew Vincent. From PLANNER to McDermott, 1974--A genetic approach. In Proceedings of the 1972 Fall Joint Computer Conference, Montvale, NL Aug. 1972, pp. 1171-1179. AFIPS Press. This is the published version of ]Sussman, 1972b]. [Sussman, 1972b] Sussman, Gerald Jay and McDermott, Drew Vincent. Why Conniving is Better than Planning. AI Memo 255A, MIT Artificial Intelligence Laboratory, Cambridge, MA, April 1972. [Sussman, 1975a] Sussman, Gerald Jay and Stallman, Richard M. Heuristic Teclmiques in Computer-Aided Circuit Analysis. AI Memo 328, MIT Artificial Intelligence I..aboratory, Cambridge, MA, Mar. 1975. [Sussman, 1975b] Sussman, Gerald Jay and Steele, Guy Lewis, Jr., SCHEME: An lnterpreterforExtendedLambda Calculus. A1 Memo 349, M1T Artificial Intelligence Laboratory, Cambridge, MA, Dec. 1975. [Sussman, 1988] Sussman, Gerald Jay and Halfant, Matthew. Abstraction in numerical methods. In [ACM LFR 1988], pp. I-7. [Swanson, 1988] Swanson, Mark R., Kessler, Robert R., and Lindstrom, Gary. An implementation of Portable Standard Lisp on the BBN Butterfly. In [ACM LFR 1988], pp. 132-142. [Swinehart, 1972] Swinehart, D. C. and Sproull, R. E SAIL. SAIL Operating Note 57.2, Stanford Artificial Intelligence Laboratory, Stanford, CA, 1972. [Symbolics, 1985] Symbolics, Inc., Cambridge, MA. Reference Guide to Symbolics-Lisp, Mar. 1985. [Takeuchi, 1983] Takeuchi, lkuo, Okuno, Hitachi, and Ohsato, Nobuyasu. TAO: A harmonic mean of Lisp, Prolog, and Smalltalk. ACM SIGPILANNotices, 18:7, July 1983, pp. 6.5-74. [Teitelman, 1966] Teitelman, Warren. PIL~." A Step toward Man-Computer Symbiosis. Tech. Rep. MAC-TR-32, MIT Project MAC, Sept. 1966. Ph.D. thesis. [Teitelman, 1971] Teitelman, W., Bobrow, D. G., Hartley, A. K., and Murphy, D. L. BBN-LISP: TENEX Reference Manual. Cambridge, MA: Bolt Beranek and Newman Inc., 1971. [Teitelman, 1973] Teitelman, Warren. CLISP: Conversational LISP. In [IJCAI, 1973], pp. 686-690. [Teitelman, 1974] Teitelman, Warren, etal. InterLISP Reference Manual. Xerox Palo Alto Research Center, Palo Alto, CA, 1974. First revision. [Teltelman, 1978] Teitelman, Warren, etaL lnterLISP Reference Manual. Xerox Palo Alto Research Center, Palo Alto, CA, Oct. 1978. Third revision. [Tesler, 1973] Tesler, Lawrence G., Enea, Horace J., and Smith, David C. The LISPT0 pattern matching system. In [IJCAI, 1973], pp. 671-676. [Thacker, 1982] Thacker, C. P., McCreight, E. M., Lampson, B. W., Sproull, R. F., and Boggs, D. R. Alto: A personal computer. In Siewiorek, Daniel P., C. Gordon Bell, and Allen Newell, Eds., Computer Structures: Principles and Examples, Computer Science Series, Chap. 33, pp. 549-572. New York: McGraw-Hill, 1982. [Travis, 1977] Travis, Larry, Honda, Masabiro, LeBlanc, Richard, and Zeigler, Stephen. Design rationale for TELOS, a Jensen, 1974-based AI language. In [ACM AIPL, 1977], pp. 67-76. [Ungar, 1984] David Ungar. Generation scavenging: A non-disruptive high performance storage reclamation algorithm. In [ACM PSDE, 1984], pp. 157-167. [Utah, 1982] Utah Symbolic Computation Group. The Portable Standard LISP Users Manual. Tech. Rep. TR-10, Department of Computer Science, University of Utah, Salt Lake City, Jan. 1982. [Vuillemin, 1988] Vuillemin, Jean. Exact real computer arithmetic with continued fractions. In [ACM LFE 1988], pp. 14-27. [Wand, 1977] Wand, Mitchell and Friedman, Daniel P. Compiling Lambda Expressions Using Continuations and Factorization. Tech. Rep. 55, Indiana University, July 1977. [Waters, 1984] Waters, Richard C. Expressional loops, in Proceedings of the Eleventh Annual ACM Symposium on Principles of Programming Languages, Salt Lake City, Utah, Jan. 1984, pp. 1-10. Association for Computing Machinery. [Waters, 1989a] Waters, Richard C. Optimization of Series Expressions, Part 1: User's Manual for the Series Macro Package. Al Memo 1082, MIT Artificial Intelligence Laboratory, Cambridge, MA, Jan. 1989. [Waters, 1989b] Waters, Richard C. Optimization of Series Expressions, Part !i: Overview of the Theory and Implementation. Al Memo 1083, MIT Artificial Intelligence Laboratory, Cambridge, MA, Jan. 1989. [Wegbreit, 1970] Wegbreit, Ben. Studies in Extensible Programming Languages. Ph.D. thesis, Harvard University, Cambridge, MA, 1970. [Wegbreit, 1971] Wegbreit, Ben. The Wegbreit, 1974 programming system. In Proceedings t~'the 1971 Fall Joint Computer Conference, pp. 253-262, Montvale, NJ: AFIPS Press, Aug. 1971. [Wegbreit, 1972] Wegbreit, Ben, Brosgol, Ben, Holloway, Glenn, Prenner, Charles, and Spitzen, Jay. ECL Programmer's Manual. Tech. Rep. 21-72, Harvard University Center for Research in Computing Technology, Cambridge, MA, Sept. 1972. 31)8
CHAPTER Vl
TRANSCRIPT OF LISP PRESENTATION
[Wegbreit, 1974] Wegbreit, Ben, Holioway, Glenn, Spitzen, Jay, and Townley, Judy. ECL Programmer's Manual. Tech. Rep. 23-74, Harvard University Center for Research in Computing Technology, Cambridge, MA, Dec. 1974. [Weinreb, 1978] Weinreb, Daniel, and Moon, David. LISP Machine Manual, Preliminary Version. MIT Artificial Intelligence Laboratory, Cambridge, Ma.~achusetts, Nov. 1978. ]Weinreb, 1981] Weinreb, Daniel and Moon, David. LISP Machine Manual, Third ed. MIT Artificial Intelligence Laboratory, Cambridge, MA, Mar. 1981. [White, 1980] White, Jon L. Address/memory management for a gigantic LISP environment; or, GC considered harmful. In [Lisp Conference, 1980], pp. 119-127. [White, 1986] White, Jon L. Reconfigurable, retargetable bignums: A case study in efficient, portable Lisp system building. In [ACM LFP, 1986], pp. 174-191. [Wulf, 1971] Wulf, W.A., Russell, D.B., and Habermann, A.N. Bliss: A language for systems programming. Communications oftheACM, 14:12, Dec. 1971, pp. 780-790. [Wulf, 1975] Wulf, William, Johnsson, Richard K., Weinstock, Charles B., Hobbs, Steven O., and Geschke, Charles M. The Design of an Optimizing Compiler, Vol. 2 of Programming Language Series. New York: American Elsevier, 1975. [Yngve, 1972] Yngve, Victor H. Computer Programming with COMIT il. Cambridge, MA: MIT Press, 1972.
TRANSCRIPT OF PRESENTATION STEELE: We're very happy to be here this morning at the HOPL conference. We've worked very hard on this paper. We began work on it almost two years ago. So this has been a long time in the making and we're ready to do it this morning.
GABRIEL: Yes, and we have also worked very hard on the presentation for this conference today. We've been working on the presentation for almost two days now. [laughter] STEELE: This extreme range, a difference of orders of magnitude, is typical of various things that go on in the Lisp community. Let me give you a couple of examples. One is that there is an ANSI standard for the dialect of Lisp known as Scheme. It is a mere 50 pages long. It is a model of concision.
GABRIEL: The ANSI Common Lisp draft specification is at the opposite extreme, currently weighing in at 1,350 pages. STEELE: That is a difference of 27 to 1. Another example is that with merely a stone knife, a block of wood, and a working C compiler, you can put together a working Lisp interpreter in less than a day if you know what you are doing.
GABRIEL: And, if you want to put together a fairly decent, but not outstanding, Common Lisp system, you should plan on 20 to 30 man-years. [laughter] STEELE: We worked very hard putting this paper together. We polished it and polished it and got it as perfect as we could and there is no way we can present all of that material this morning in a space of 35 minutes. So we are not even going to try. GABRIEL: So what we are going to do instead is try to take different slices through this complicated and very difficult to understand history of Lisp, and try to show you some themes that we've discovered over the years. STEELE: We are assuming that you have read or probably will read the paper [in this book]. But that's not a prerequisite for what we're going to do this morning. Instead, we're going to show you a graphical presentation of the various Lisp projects and we're going to show you everything on this two-dimensional graphical plot [Figure 6. l ], in which the vertical axis is time, extending from a little before 1960 to about the present. On the horizontal axis we've put geography running East and West. There is no reason why this should have turned out to be a useful axis, but it did, coincidentally, and so we're going to lay things out that way. You will find over here on the left projects occurring in LISP SESSION
309
GUY L. STEELE JR. & RICHARD R GABRIEL
Jan
UT
California ..................... 1960
IL TX IN
PA
NY
Q
mE
P
O
•
•
Q
!
"°I o
II
1990
A
"M
W
1980
@
•
O O
1970
Massachusetts ............ Europe
NJ
B
:i
o
@
II FIGURE 6.1
Japan. There is a large cluster of stuff that happened
in California; a variety of things that happened between the coasts in the U.S. at various scattered locations that we will talk about later--they are labeled by state on this plot; a whole pile of stuffthat happened in Massachusetts, particularly centered around MIT where Lisp got started; and then there are a number of projects over in Europe. GABRIEL: As often happens, you can learn quite a bit by plotting the relationships among the various languages and dialects. So we did that with the Lisp family graph and we came up with this intuitive [laughter] look at the history of Lisp [Figure 6.2]. In this diagram the black arrows indicate a direct relationship, for example, either using the implementation to bootstrap a further one or to use part of the implementation later on. The magenta arrows [gray in this book], which took us three hours to draw in, represent an influence that is significant. Rather than show you all of this, we are going to show you different slices through this that illustrate some particular points. STEELE: It would be helpful ifI explained our color coding system. The red [lightest gray] rectangles represent specific Lisp implementation projects, and we have attempted to show the geographic location at which the implementation occurred, not necessarily the sites of their use. Where some of these bars are first wider, then narrow, we have intended the wide part to indicate roughly the time span of the heyday of those implementations, although use continued after their heyday for some time in some instances. The green [light gray] ovals indicate language specifications for languages that are not of the Lisp family but which we have included on the chart because they have an influence on the development of Lisp. The blue [darkest gray] ovals indicate language specifications within the Lisp family, but specifications as opposed to implementations. The cyan [dark gray] rectangles indicate official standards projects under ANSI or ISO.
310
CHAPTER Vl
TRANSCRIPT OF LISP PRESENTATION
LISP Family Graph
O
O-~c ...................... "7f
,
'-
i
L.....~
FIGURE 6.2 There's no way in the world that we could possibly make intelligible sense out of this network of boxes and arrows. We're going to show you different subsets of that. Let's begin by looking at the Lisp 1.5 family [Figure 6.3]. This all stems from the original idea, shown here as a blue oval, of Lisp 1.5 as reflected in the Lisp 1.5 Programmer's Manual and earlier documents. This spawned a number of implementations. Perhaps the most direct descendants are the Lisp 1.5 implementations on IBM machines on the 7090 and the 7094 at MIT. There are a number of implementations early on on other machines, notably several different PDP-1 implementations that happened in different geographic locations; implementations on the M-460 and the Q-32, which you can read about in references that are cited in our paper; and also, notably, an implementation on the PDP-6, which was arguably the first real hardware Lisp machine. It was the first architecture that included instructions specifically for the support of the Lisp language and this turned out to have a great influence on the rest of the development of Lisp, as we will see later. There is also a version of Lisp developed in Cambridge, in England, and Lisp 1.5, after about ten or fifteen years, resulted in implementations in Utah (Standard Lisp) and the Stanford Lisp 1.6 and UCI Lisp configuration. The most notable characteristic of this slide is that there is an important idea and suddenly there was a quick spawning of a bunch of implementations. Lisp was still a fairly small language, and at the time it was very easy for a project at another university or another company to say, "Hey, let's build us a Lisp, too." You could within a day, or a week, or a month, get some kind of Lisp working on whatever machine you had there locally. GABml~L: Now we are going to look at a later family, the MacLisp family [Figure 6.4]. This family was developed here at MIT. Again, as Guy pointed out, it started off with the PDP-6 Lisp, which soon turned into MacLisp. MacLisp ran primarily on the PDP-10, which was again sort of a Lisp machine. LISP SESSION
311
GUY L. STEELE JR. & RICHARD R GABRIEL
LISP 1.5 Family :......',,....._/
LISP 1.5 PDP-1 U S P
i
....
,'~-~ '
I~'~,~_
":~'~_~:/a7",~
:..
i
.......:)
i:
I
il/i UCI-USP
i
:
:
i
i'
i
:. :
'"--~ ~
•
i
i
~ .......
i
:
i
!
.
i
i ii
.
Fi
.
'
'....................................
.
',
.
i
ii
', .......
..........................................::::::: ....................V i
•
("-)
i
!
.........
~........
~ ..
FIGURE
i
i
~
;
.... -
L...!
i.....~0
6.3
MacLisp Family :"..,\ ......
/.-.,
....
i.....
'
---:
,/ '":'::::i'"
i.... f'',
i
PDP-6 USP 'J .... !
\..)
..... !, ....
ilL! ~-i
i ......... ~ ~i;ili
:....~
~tlip
MuRIcs MacLIsp
i)
..........CMU
M~U,~
iVUSP
iFranz USP
t
i___ ¸
NIL
,
i.
/
........ i z,t,,,p i .i i FIGURE
312
~".........
L.J
0
Eili
6.4
CHAPTER Vl
TRANSCRIPT OF LISP PRESENTATION
It had special instructions for doing CAR and CDR and good stack instructions for fast function call. This work was primarily done by a fellow named Jon L white, whom we see again and again in our story. He worked on this fairly continuously up until the beginning of the demise of MacLisp. As we can see by the direction of the arrows, MacLisp kind of spread; even though most people think of MacLisp as having remained at MIT, it moved across country, particularly when Scott Fahlman and Dave Touretzky moved from MIT to CMU. They, along with Guy Steele, did a port of it to the local system, where they did some extensions. I ' m not sure what sort of adaptations they did, but they did some adaptations so that it became one of the standard Lisps at CMU. Similarly, when I moved across country, MacLisp came with me and we did some significant adaptations to it on the West Coast. And, in particular, one thing you can see is that MacLisp was used for quite a long time at Stanford, way beyond where it was used at MIT. Other MacLisp-like dialects spawned off, for example, Lisp-Machine Lisp, which was kind of a response to the limited address space that the PDP- l 0 had. In fact, one of the significant events was running into the limit of basically a one-megabyte, one-MIPS machine. Keep in mind that people were trying to do AI research in this Lisp on this machine. There are several dialects of Lisp-Machine Lisp that we will see later. One of the points we want to make here is a little bit surprising. We didn't know it until we saw these graphs. One of the things that you can see is that MacLisp kind of spread throughout the country and it did it for a couple of reasons. For one, MIT is relatively unstable in the sense that, when you are there, your funding may end at any time, so you might have to leave. So the tendency is for people to leave the area and take what they know with them. The, a h . . . I forget what the second point was! STEELE: Instead of your second point, let me point out one block you missed: Richard Fateman left MIT when he went to Berkeley (as opposed to Stanford); the Franz Lisp effort got started, and this was another important offshoot of the MacLisp family. I'll make a contrast with Dick's first point by looking at the IBM Lisp family [Figure 6.5]. Here there is a fairly direct relationship of taking at least the ideas, if not some of the implementation code, from the 7090 Lisp. Notice that this is the 7090 Lisp and not the 7094 Lisp--the difference between those is that the 7090 Lisp was running under the IBM operating system; the 7094 Lisp was running under MIT's CTSS operating system. It became Lisp360, and once it got there at Yorktown, or somewhere in New York, there was a fairly direct implementation line. It stayed in one place because IBM, at least compared to MIT, is a relatively stable place. Once you are there, you are set; there is less of a need to publish outside. There are more controls, for good reason: you have a product you are selling, as opposed to just doing it as an academic exercise. There are reasons to maintain central control over an implementation. Notice this is not the locale of use; this is the locale of implementation. There were, of course, users wherever IBM computers were. There is one interesting connection here with Intedisp and with MacLisp, which is that there was a programming environment that--actually, Intedisp developed a great programming environment, and when Dick Gabriel happened to be at Illinois and he read about the Interlisp programming environment, he was greatly impressed and decided to bring a version of it up in MacLisp. He did that, and then when he went to Stanford, he carried that with him, brought it up there, and it became the programming environment of choice at Stanford, completely displacing the old Stanford Lisp 1.6. That programming environment then got ported back to the IBM environment and became the programming environment that was standard within VM Lisp. But except for that one strong outside influence, it was pretty much a self-contained series of projects there at IBM. GABRIEL: Another example of a stable situation is with Interlisp [Figure 6.6]. Interlisp actually had its roots a little bit higher up in this diagram with the Basic PDP-1 Lisp that Peter Deutsch wrote as
LISP SESSION
313
G U Y L. S T E E L E JR. & R I C H A R D R GABRIEL
IBM Lisp Family
~ii)~ .
7090 LISP 1 .S
i
u=~ C.
:iii•
;iSS
i ....... \.,"
C! ...........
f..\
ulpaTO
i ii i \..~ i,,,i
L .......CD
Illinois
i
.......
'~. . . . . . . . .
~,iiiiiiii
!
i•i'~ i' i
g|cUIp~
~"
......
~ii
f,...
, i..,, ~ L.....;
...... ;
i ~,
C..._,..J =
......
....
:,
F9
.........
L._L
........................................................ i..i.................
i
i
i;
ii
i
i
.......... ,"
,
: ..j
..... i L . J
FIGURE
6.5
Interlisp Family ./'"9 /
•" ' ~
......i
.
i:
.......
sos,,.. List
L...~
......,
CiSii'! ~S.i~
\,..:
~ ~...,
Interlisp 370
-N
.......i
IntediIp i r'"""~
•
......
iiiil/, ::::, . ~:i
CSD
LOOPS
i '
i ....... J
.................................
f
~...........)
,i
©
FIGURE
314
U
6.6
CHAPTER
Vl
TRANSCRIPT OF LISP PRESENTATION
a high school student in this area. This was later expanded into the SDS 940 Lisp, which was done, at least in part, by Danny Bobrow, who will, again, appear in many places in this story. The interesting developments, from our point of view, start with BBN-Lisp. Now BBN-Lisp, which later became Interlisp, is interesting because it developed a notion of a very elaborate, cushy, comfortable programming environment. So, in contrast to MacLisp, which was concerned with performance and small size (in order to write large programs in the small address space of the PDP- 10), Interlisp was more concerned about making the programming task easier, so there was a non-file-based structure editor, "Do What I Mean," Conversational Lisp type of programming environment. At some point, BBN passed over the responsibility of maintaining BBN-Lisp to Xerox, partly coinciding with the departure of the principals, for example, Danny Bobrow, to the West Coast. Interlisp has sort of a long history. As you can see, it doesn't exist in very many places except for this box you can't see, which is Interlisp 370, which was developed in Sweden, and I ' m not sure how widely it was used. But if you ignore that, we can see a similar situation to IBM where there is sort of a narrow but long use. Again, because of the stability of the place, people didn't tend to leave, they didn't need to publish outside, so the ideas didn't spread very much. There are a couple of interesting spawns here into LOOPS and CommonLoops, the Lisp Object-Oriented Programming System. We'll see that later when we talk about the object-oriented programming aspects of this. Danny Bobrow did quite a lot of work all over this map. One of the interesting things he did was a concept called spaghetti stocks, which were a kind of a coroutining facility, a way of saving state and going back and forth between different threads of control. STEELE: Its important to realize that the Interlisp implementation, like the MacLisp implementation, was trying to run on a machine that had one megabyte of address space and ran at 1 MIPS; and that there were necessarily some severe engineering tradeoffs to be made. It's not that the MacLisp group would not have liked to have had a good programming environment; it's not as if the Interlisp group would not have liked to focus on compiler development and so forth, and good numerical performance, as the MacLisp group did; it is just that, when you are running under those kind of machine constraints, you have to make some hard choices. There was a time, in 1974, when the two implementation groups got together, at what we sometimes called a MacLisp-Interlisp summit, where the implementors got together and tried to agree on a set of features that they could exchange in order to encourage portability between the two platforms, and ultimately we agreed only on a few trivial things. At the time, I remember thinking, "Boy, those people are really pigheaded--they won't take all our good ideas!" and I ' m sure they felt very much the same way about us. Looking back on it, I ' m inclined to the more generous interpretation that each of us, consciously or unconsciously thinking about our severe budgetary constraints of memory space and machine speed, simply felt that we couldn't afford anything that wasn't on our main program. But what broke this logjam was the development of the Lisp machines [Figure 6.7]. It became clear in the mid-70s that the PDP-10 wasn't going to cut it for too much longer, and that it seemed to be more cost-effective to build custom-designed Lisp hardware--this was a point where you could just begin to afford to design special-purpose personal workstations. I think the original inspiration for this was the Alto at Xerox, although it wasn't initially running Lisp. Then Tom Knight and Richard Greenblatt at MIT proposed to build these things called Lisp Machines, of which first a few dozen were built at MIT, and this then proceeded to spawn two companies, LMI and Symbolics, which then commercialized those. At the same time, Xerox produced a series of machines designed for both Lisp and Smalltalk, and some other languages, such as Mesa. So they had a series of personal workstations such as the Alto and the so called "D machines," the Dorado, the Dolphin, and the Dandelion, and Interlisp was brought up on all those machines. There was also a machine that was
LISP SESSION
315
G U Y L. S T E E L E JR. & R I C H A R D R G A B R I E L
Lisp MachineI ~,........ ,
"':.
L..2 /,.-. L..;
.... J :.......~
:
~
,/-\
...,
i.iiiiii: ' ~ p l c e
.......
•. I~wliop (Xerox
~ , ........ J
i Lisp !(PERQ)
tBBIM ~cho~
: ! i i(MITCONS) : "(MIT CADR)
::~ .!AltO Domd~
Dolphin
:" .......
Dandelion
i
i i
m"~:::: ...........
!i iLhlp
'
,
i .......
E
(LMI L a m b d a ) :...:~ ....
TAO (ELLS)
:_.__:
Lisp I~iichine U ~ p
....i
Machine~
:~.iLl
............i::::7 .......... ~i ..... _cs: .....
!
[.............
.......
c"'~
Zetillsp
i i
" !(3600)
i ......
L.....i................:......................................
CC) ! •.) L..JC) i :Ci
..............i
FIGURE 6.7 done at BBN, called the Jericho. The machine was geographically over here, but it used Interlisp, so I've notated it next to the box there for Interlisp. There was also some work done on Lisp machines inJapan, of which I think the most notable was the ELIS machine, which ran a dialect that was a combination of Lisp and Prolog, and this dialect was called Tao. The Lisp Machines lasted for quite a while and some of them are still in use today. There are Lisp Machines running over at Thinking Machines, doing diagnostic debugging of Connection Machines--that's just the software we happen to run on them right now. They are still considered workhorses in some places. On the other hand, by the mid-80s, it became clear that machines that were custom-built to run just one language weren't necessarily cost-effective anymore, because the general-purpose workstation market had exploded and you could just go to Sun, or HP, or whatever place you liked, and buy a stock workstation, put up an implementation of Lisp on it, and the overall combination would be just as effective as having a custom-built piece of hardware. GABRIEL: The next major development is Common Lisp [Figure 6.8]. Common Lisp is an interesting development in the sense that it is, I think, the first time that the Lisp community tried to work together. What happened was, basically, as you will recall from the MacLisp slide, all of the MacLisp people kind of split up, went to the four winds, and started working on their own various dialects of Lisp. Here are some of these dialects: NIL, ZetaLisp, Spice Lisp, S-1 Lisp are the primary ones. In April 1981, there was a DARPA meeting at SRI in California, sort of another Lisp summit meeting. The purpose of that meeting was for DARPA to find out whether it was going to be able to have a consolidated Lisp to use in its research. What happened at that meeting was that the Interlisp community, being sort of unified anyway, appeared very unified and the MacLisp community seemed kind of scatterbrained. So what we did was, we all got together and said, "Let's beat those guys." We got together and we started to define a description of a family of langages called Common Lisp. 316
CHAPTER
Vl
TRANSCRIPT
OF LISP PRESENTATION
Common Lisp Family APL
L..~......... ..;~:~:--.... ........
t ............ )
.....i i_i ! "[
k,..:
I"
"
..
o
FIGURE 6.8 Now Common Lisp has gone through a somewhat lengthy history. As mentioned, it takes quite a while to implement the Lisp. That's because it's a fairly large definition; a large, what most languages call library was included. This box here [points to (a) in Figure 6.8] represents the publication of CLTLlmCommon Lisp: The Language, first edition--which represented the work of two or three years of informal standardization, which happened over the network, primarily. It was one of the first designs that happened over the network, and in fact, the e-mail traffic has been studied by various sociologists to figure out what was going on with us. [laughter] Later on, an ANSI standards committee was formed, called X3J 13, to do a formal ANSI standardization of that. These boxes here represent the location of the chairman, Guy Steele, over here [points to (b)], and [puzz/ed] Guy Steele over there [points to (c)]. STEELE: [The diagram is] kinda crunched. GABRIEL: [to audience] Okay, so we switched chairmen. The other interesting thing, which is not noted on here, is the extreme reaction against Common Lisp; we'll come back to that later. [In fact,
they didn't. ] STEELE: Here is a picture of the Scheme extended family [Figure 6.9], and there are three points to be noted here. One is that this is a two-part story where Scheme represents a very sudden left-hand turn. Everything that happened before Scheme was a series of developments of a series of AI-ofiented languages, actually going all the way back to COMIT, which was a very early string processing, pattern matching language at MIT. One of the notable offshoots of COMIT is that it had an influence on SNOBOL, but SNOBOL then did not have a lot of direct influence on Lisp; but it's interesting to note it is a cousin of Scheme though a very distant connection. COMIT also spawned an implementation of COMIT in Lisp, which was called Meteor--there is an obvious pun there--that was done by Danny LISP SESSION
317
GUY L. STEELE JR. & RICHARD R GABRIEL
Scheme Extended Family COMIT I ...............
Algol 60
m!
SNOBOL
.:::
DAISY, Scheme 311, Scheme M
[:::::]
R*V~d2 Sche,rM
•
iil.......
i :
ii ..........i
ili~ i I
i
CLTL1 i ~i
....
i~-
.rr
1..-"
l l j l d l l i i i i,WWii
i'
]."
.
S c h Re ~ lmI Q dei i i ~ ~
f[
ii i i . i~ ;
/i
PC Scheme
te~
i',
!
~ ~....
r
:i:? i / ~ ) ; Revlsed 2 Scheme ....
l~heme
........
o
i
LJ
FIGURE 6.9 Bobrow also, actually--and then after that there was a version of a pattern matching language called Convert, done by Adoifo Guzman at MIT, which was a redesign as a Lisp-embedded pattern matching language; it was used for some AI applications. Convert then had an influence on Carl Hewitt's Planner, as described in his doctoral dissertation, and then Planner spawned a bunch of ideas, and what then began was what can be characterized as a debate, or an argument, between Carl Hewitt and Gerry Sussman and their respective students about how languages to support AI should be designed and how complicated control structure should be done. Sussman worked on the Muddle project, which was inspired by some of the ideas of Planner, and also on MicroPlanner and some others. Conniver was a response to Planner, suggesting that all the automated mechanisms of Planner that happened under the table to do coroutining and backtracking should be brought out and made explicit and put under the control of the programmer. And so Conniver was a coroutinist's dream. Scheme was originally called Schemer, and it was conceived of as another in the series of Planner and Conniver and so forth, and the name got truncated because file names on the PDP-10 were limited to six characters. [loud laughter and applause] And we decided that that was an okay name, too. Scheme was an attempt to implement some of the actors ideas that Carl Hewitt had put in his language PLASMA, which had a very complicated and elaborate syntax. We were trying to strip it down to its barest essentials. After we had implemented a version of Lisp, we decided to give it lexical scoping as in ALGOL---there's the A L G O L 60 influence--rather than the dynamic scoping that had been typical of Lisp 1.5, largely because Sussman had been studying A L G O L 60 and teaching it in a course and wanted to try that idea, too, and he thought it would work with actors. When we got the whole thing implemented, we discovered that the code for implementing lexical closures and the code for implementing actors were identical--and this was discovered empiric a l l y - a n d we said, "Oh, I see! Actors are just closures of lambda expressions." Well, there is a little
318
CHAPTER Vl
TRANSCRIPT OF LISP PRESENTATION
bit more to it than that, but suddenly we realized that Scheme was just a dialect of Lisp, rather than a complicated AI language. And at the point below that is the second part of the story, which is that Scheme, being a very small, simple version of Lisp, spawned a bunch of new dialects. There is a version at Yale called T, and there are a bunch of others that I haven't shown; there's work done at Indiana, by Dan Friedman and Dave Wise and their students, which was actually quite a hotbed of Scheme activity, and actually some Lisp activity even before Scheme got started--they influenced some of the early ideas of Scheme. And we see a pattern here, hanging below Scheme, that is very much like the pattern that appears below Lisp 1.5, which is that a small simple idea suddenly could be implemented by a bunch of people and they could start to play with it, and we saw a large spawning of a bunch of implementations, which then got together and began to try to do some standards efforts. These green ovals, which are not on the master slide, show a series of revised Scheme reports--which are informal standards--and the third revision spawned the effort to produce the IEEE Scheme standard. GABRIEL: The next thing we're going to see is the object-oriented influence, and this slide [Figure 6.10] is interesting for a couple of reasons. It's one of the few slides that show ideas and influence going one way and then the other, geographically. So, as we can see, one of the things that spawned all this off, of course, is the Simula 67 work, which influenced the Smalltalk work that we will hear about from Alan Kay later today. There is some question here about exactly how the Smalltalk work influenced the PLASMA and the Flavors work. The way that we interpreted it is that Smalltalk 71, as it's called, was the thing that influenced Carl Hewitt in a meeting that you can read about in our paper and in Alan's paper, where they got together and talked about the implementation of these sorts of languages. The later Smalltalk, which we call Smalltalk 72, had sort of a direct influence on Flavors;
Object-Oriented Influence
•
"""-"~/ /.,.,...,...
?--i : " i i
i
Simula 67
• ;
Smalltalk-71
i-
i :i ~
• ~CLU
•
/
./
r
...... ~F / ,7" r,.vorsi ObJectlil:t';;>'~" ~ N
Zi: e r a
LOOPS
....
;
/
'
i!,,'T
~......~.....~
/
:
;i ~
......
New Flavors
!:::::i
:::::::::::::::::::::::::::::::::::::: ........................ ¢1
CLOS ZZ
.....% ..................
FIGURE 6.10
LISP SESSION
319
GUY L. STEELE JR. & RICHARD R GABRIEL
several of the MIT folks had visited Xerox PARC, seen the idea, and said, "Yeah, we can do that a little bit better." Now, one of the things this made us think about is, a lot of the other slides that you've seen have shown ideas originating here [at MIT] and spreading out. And we think that it's not so much because there's so many great ideas that come from MIT; rather, that MIT is a little more parochial, a little more inbred, and doesn't pay attention as much as the rest of the world to what's going on, so ideas tend to move away from here because ideas don't move in so much. [laughter] Sort of an extreme way of putting it. [laughter] The other thing is, MI~---well, you don't get a high salary, so people leave, and so they take their ideas with them. This is a contrast here, where we see the ideas coming back over. Now, LOOPS, the Lisp Object-Oriented Programming System, is kind of an offshoot of Interlisp and is relatively Smalltalk-like. Commonl_,oops and CLOS [Gabriel consistently pronounced this "see-loss"], on the other hand, are very different. CommonLoops and CLOS attempt to merge the pseudo-functional programming style of Lisp with the object-oriented style, so that you have generic functions rather than message passing. In addition, from Flavors and New Flavors, CommonLoops and CLOS have multiple inheritance, also method combination, and a lot of other exotic object-oriented technology. CLOS itself was an activity of X3J 13, and I've listed a couple of other influences, namely Object Lisp and Common Objects. Object Lisp is probably a relatively direct decendent of actors--it's a delegation-based object-oriented system. And Common Objects, done by Alan Snyder, is sort of an encapsulation-heavy type of system. I have listed influences here, but they are negative influences. The CLOS group decided to explicitly ignore Object Lisp Common Objects. CLOS, as you can see, has influenced quite a lot of work, both here and in Europe. Dylan, ISLisp (which is the ISO standard Lisp), and EuLisp all use a variant of CLOS.
STEELE: Now I'd like to discuss the influence of the lambda calculus [Figure 6.11] on the development of Lisp. Those who have not studied Lisp very closely are aware that Lisp has lambda expressions, and that lambda calculus started that, and so forth. If you read McCarthy's paper in the first HOPL conference, he explains there that primarily what was borrowed from the lambda calculus was the lambda notation but not its precise semantics; rather, it was used in a slightly different way. Functions in Lisp 1.5 give dynamic scoping to their variables, rather than lexical scoping adhering to something like the ALGOL copy rule. So the notation came in there. A second influence sort of focuses down here on Scheme and also on Lisp370, where through a series of influences--includin~ ?eter Landin's work on SECD machines and on ISWlM, and Evans' work on PAL, and Reynolds' work (particularly the "Definitional Interpreters" paper at the ACM '72 conference, which was a very strong influence on Sussman and m e ) - - b y these various intermediaries, Scheme and Lisp370 were led to implement lexical scoping, thereby preserving substitutability of expressions in a way that Lisp 1.5 did not. The third influence of the lambda calculus is that, more recently, purely functional languages appeared, the so-called "functional languages," some of which are Lisp-like in syntax and some are not, but they are very clearly Lisp-like in spirit. I think the current culmination may be described as Haskeli, which is a project that was done at Yale and other places, and that was in turn influenced by implementations of ML and Hope, which were in turn influenced by Landin. The influence coming in from lambda calculus is normal order reduction, that is, guaranteeing that if there is a normal form result for your computation, the interpreter will find it; this is not guaranteed in the case of Scheme or Lisp 1.5.
320
CHAPTER Vl
TRANSCRIPT OF LISP PRESENTATION
Lambda Calculus Influence
Landln b(SECD,
~"
nswu~)
!
i
\..,;
i
........ = i i
D HOPE
i iii
Hukell
:
.........
i iO
i }
FIGURE 6.11 I guess the point to be made is that there is an interesting progression as Lisp moves onward, going back to its roots in lambda calculus, and discovering, in several cycles, there is more there in lambda calculus than we thought and the closer we get to lambda calculus, the better the language gets. GABRIEL: Moving from the sublime to the ridiculous, [laughter] the influence of FORTRAN [Figure 6.12] is relatively minor. This influence up here is merely that the first Lisp was the FORTRAN List Processing Language [FLPL], implemented in FORTRAN. The second influence is basically complex numbers. [For lack of time, Gabriel omitted mention of the influence of FORTRAN on FORMAT
in Lisp-Machine Lisp.]
[to Steele] I guess we've got four minutes. STEELE: [tO Gabriel] Right, okay. [to audience] I've been on a number of standards committees where people say, "Well, this is an issue that can be decided in the FORTRAN community, because only FORTRAN worries about, say, complex numbers." And I'd pop up and say, "Well, there's also Common Lisp." And [when they'd add] "Only FORTRAN has FORMAT," I'd say, "Well, there's also Common Lisp." Now we'd like to show you a series of peregrinations of some key individuals who were involved with Lisp projects. First we'd like to show you what happened with John McCarthy [Figure 6.13]. He worked at MIT for some time, and then in the mid-to-late-60s moved to Stanford. The important thing there is that he took PDP-I Lisp with him, and this is how Lisp got started on the West Coast. That was a key migration, even ifa short story. GABRIEL: The next guy is Danny Bobrow [Figure 6.14], who started here at MIT, worked on another PDP-I Lisp, worked on a PDP-6 Lisp, worked on BBN-Lisp, and moved to the West Coast, where he
LISP SESSION
321
GUY L. STEELE JR. & RICHARD R GABRIEL
FORTRANInfluence
FLPL
/ f...
• ..,.~
',,...,...... J
/ O
ii
! i .... .... !
i i'
\J
i --~
/"%
ii i
~.,J
C.~
.j ::~~~ ....... :_.iii.i•!s'li i
_..
i
[::]i
-•!i
........i
i
~.......i
FIGURE 6.12
John McCarthy
"4
CD
Ci~iiiD [
...........i::::::i................................CSD ,
i
0
FIGURE 6.13
322
C H A P T E R Vl
TRANSCRIPT OF LISP PRESENTATION
Danny Bobrow .........,'
f-.\
i
l ........
0 ~,..)
f
~
.
s
5
©
\...
i :i
' II
'!
f....-~
iiiiiiii! i-~i ~i
,!
i.............................
FIGURE
6.14
still is. This shows that he worked on UCI Lisp, spaghetti stacks, LOOPS, CommonLoops, and CLOS. He was involved in X3JI 3 and also worked on CLTL2. STEELE: There is another individual whose path parallels Danny Bobrow's to some extent, which is Warren Teitelman, who also went from MIT and worked on Interlisp at Xerox; those two were the very strong influence from MIT on the Interlisp effort. Here's the path of Dick Gabriel [Figure 6.15], who got started on MacLisp at MIT, moved to Illinois---4've already discussed the influence of his Illinois presence, eventually, on IBM Lisp therenand from Illinois he went to Stanford and has been on the West Coast ever since then, except for a diversion for one summer to CMU, where he and I worked together on S-I Lisp, which is shown here [in California] geographically, but actually, wherever we were, we were working on that. He was also involved in a large number of standards efforts, in Europe as well as in the U.S, GABRIEL: From the ridiculous to the sublime, Guy Steele. [laughter] Guy Steele [Figure 6.16] started here at MIT and then, through a series of trips out to the West Coast to work with me on S-I Lisp, sort of bounced back and forth, and eventually went back to CMU and worked on Common Lisp. He was involved in a lot of the standards activities, worked on NIL, worked on Scheme, did a lot of stuff--but you know that. STEEI~E: Here are the travels of David Moon [Figure 6.17], and while he's geographically been in Cambridge, he's moved from project to project and carried a bunch of ideas back and forth. He got started working on Multics MacLisp. He was supporting the Multics implementation at the same time that I was working on the PDP-10 implementation. Then he was one of the principal implementors of the software for the Lisp Machine, and then moved over to Symbolics, and then has recently gone to Apple, where he's been working on the Dylan project.
LISP SESSION
323
GUY L. STEELE JR. & RICHARD R GABRIEL
Richard Gabriel f.. ........
++~
t " " \ t +",~
~,..........J
++
,+.+.+ .......
E
0 /"~\
E
~++, .-
~J
i i
i i ~•+•~
i iy
+ :
! i
.! i
i........ ,
!j!
i!
i:::
i/
i••+•i
U
+o
\+.j
i-- I
:
,
i++ ,..j
/
eD :
I FIGURE
6.15
G u y Steele F,
,
,
•
....
O
:::
.......
..r"
~,iiiiiiiiiii~
....
i
/", •
iiii
......
,.+.\
..........
C
~
~
•
* (
• ...
+
,!
FIGURE
324
i
.............L ~............... ++:..............
6.16
CHAPTER VI
TRANSCRIPT
OF LISP PRESENTATION
Dave Moon ....... '"
i
~
i
f'
i,.,,..
.'~
i
i
ilTiill iiiiiii
J
~ ..............
:---,:
11:.....i ........... i
.......
!iiiiii) ~::::::~
/7
........
...... "~
;
® ,
i
....
~.,
, .......
, <arrival city>, <departure time>, <arrival time>, ) 346
CHAPTER VII
PAPER:THE BIRTH OF PROLOG
where time schedules are represented by pairs of integers under the format < h o u r s > : < m i n u t e s > . All flights are supposed to be completed in the same day. The following predicate will be called by the user to plan a route. P L A N ( < d e p a r t u r e city>, <arrival city>, < d e p a r t u r e time>, <arrival < d e p a r t u r e min t i m e > , < a r r i v a l max time>)
time>,
It enumerates (and outputs as results) all pairs of cities connected by a route that can be a direct flight or a sequence of flights. Except for circuits, the same city cannot be visited more than once. Parameters <departure min t i m e > and < a r r i v a l max t i m e > denote constraints given by the user about departure and arrival times. The first flight of the route should leave after < d e p a r t u r e min t i m e > and the last one should arrive before < a r r i v a l m a x time>. In order to calculate PLAN, several predicates are defined. The predicate: ROUTE (<departure city>, <arrival city>, < d e p a r t u r e time>, <arrival time>, , , < d e p a r t u r e mini time>,<arrival maxi time>)
is similar to the PLAN predicate, except for two additional parameters: the input parameter < v i s i t s > is given represents the list (Ok. C k - 1 . . . C 1. NI L) of already visited cities (in inverse order), the output parameter < p l a n > is the list (F1 . . . . F k . NIL) of calculated flight names. The predicates BEFORE ( < t l > , < t 2 > ) and ADDTIMES ( < t l > , < t 2 > , < t 3 > ) deal with arithmetic aspects of time schedules. The predicate WRITEPLAN writes the sequence of flight names. Finally, NOT() defines negation by failure, and E L E M E N T ( < e l e m e n t > , < e l e m e n t s ) succeeds if < e l e m e n t > is among the list < e l e m e n t s > . Here then is the complete program, including data and the saving and execution commands. * INFIXED O P E R A T O R S -AJOP( ".', i, "(XIX) IX') * USER PREDICATE
-AJOP(":',
2,
~(XfX) IX")
:
+PLAN(*DEPC, *ARRC, *DEPT, *ARRT, *DEPMINT, *ARRMAXT) -ROUTE(*DEPC, *ARRC, *DEPT, *ARRT, *PLAN, *DEPC.NIL,
*DEPMINT, *A R R M A X T ) )
-SORM( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -LIGNE -SORM( "FLYING ROUTE BETWEEN: ") -SORT (*DEPC) -SORM(" AND: ") -SORT (*ARRC) -LIGNE -SORM( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ) -LIGNE -SORM(" D E P A R T U R E TIME: ") -SORT(*DEPT) -LIGNE - S O R M ( ' A R R I V A L TIME: ") -SORT(*ARRT) -LIGNE -SORM(" FLIGHTS: ") -WRITEPLAN(*PLAN) -LIGNE -LIGNE. * PRIVATE PREDICATES
PROLOG SESSION
347
ALAIN COLMERAUER & PHILIPPE ROUSSEL .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
+ROUTE(*DEPC,
.
°
*ARRC,
*DEPT,
*ARRT,
*FLIGHTID.NIL,
-FLIGHT(*DEPC, *ARRC, *DEPT, *ARRT, *FLIGHTID) -BEFORE(*DEPMINT, *DEPT) -BEFORE(*ARRT, *ARRMAXT). +ROUTE(*DEPC,*ARRC, *DEPT,*ARRT, *FLIGHTID.*PLAN, -FLIGHT(*DEPC,
*INTC,
*DEPT,
*INTT,
*VISITS,
*DEPMINT, *ARRMAXT)R
*VISITS,*DEPMINT, *ARRMAXT)
*FLIGHTID)
-BEFORE(*DEPMINT, *DEPT) -ADDTIMES(*INTT, 00:15, *INTMINDEPT) -BEFORE(*INTMINDEPT, *ARRMAXT) -NOT( ELEMENT(*INTC, *VISITS) -ROUTE(*INTC,*ARR,*INTDEPT,*HARR, *PLAN,
*INTC.*VISITS, *INTMINDEPT, *ARRMAXT).
+BEFORE(*HI:*MI, *H2:*M2) -INF(Hi, H2). +BEFORE(*Hi:*Mi, *Hi:*M2) -INF(Mi, M2). +ADDTIMES(*Hi:*MI, *H2:*M2, *H3:*M3) -PLUS(*Mi, *M2, *M) -RESTE(*M, 60, *M3) -DIV(*M, 60,*H) -PLUS(*H, *HI, *HH) -PLUS(*HH,*H2,*H3). +WRITEPLAN( *X. NIL) -/ -SORT(*X). +WRITEPLAN(*X.*Y) -SORT(*X) -ECRIT(-) -WRITEPLAN(*Y). +ELEMENT(*X, *X.*Y). +ELEMENT(*X, *Y.*Z) -ELEMENT(*X, *Z). +NOT(*X) -*X -/ -FAIL. +NOT(*X). * LIST OF FLIGHTS .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
°
+FLIGHT(PARIS, LONDON, 06:50, 07:30, AF201). +FLIGHT(PARIS, LONDON, 07:35, 08:20, AF210). +FLIGHT(PARIS, LONDON, 09:10, 09:55, BA304). +FLIGHT(PARIS, LONDON, 11:40, 12:20, AF410). +FLIGHT(MARSEILLES PARIS, 06:15, 07:00, IT100). PARIS, 06:45, 07:30, IT110). +FLIGHT(MARSEILLES +FLIGHT(MARSEILLES PARIS, 08:10, 08:55, IT308). +FLIGHT(MARSEILLES PARIS, i0:00, 10:45, IT500). LONDON, 08:15, 09:45, BA560). +FLIGHT(MARSEILLES +FLIGHT(MARSEILLES LYON, 07:45, 08:15, IT115). +FLIGHT(LYON, LONDON, 08:30, 09:25, TAT263). * SAVING THE PROGRAM .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
°
-SAUVE! * QUERYING -PLAN(MARSEILLES,
348
LONDON,
*HD, *HA, 00:00,
09:30)!
CHAPTER VII
PAPER:THE BIRTHOFPROLOG This is the ouput of the program: .
.
.
.
.
.
.
.
.
FLYING .
.
.
.
.
.
.
.
.
.
.
.
.
.
ROUTE .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
BETWEEN: .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
MARSEILLES .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
AND: .
.
.
.
.
.
.
.
.
.
.
.
.
.
LONDON .
D E P A R T U R E TIME: 06:15 ARRIVAL TIME: 08:20 FLIGHTS: ITi00-AF210
FLYING .
.
.
.
.
.
.
.
ROUTE .
.
.
.
.
.
.
BETWEEN: .
.
.
.
.
.
.
.
.
.
MARSEILLES .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
AND: .
.
.
.
LONDON .
D E P A R T U R E TIME: 07:45 A R R I V A L TIME: 09:25 FLIGHTS: ITIi5-TAT263
7.5.4
Implementation of the Interpreter
'The resolution system, in which nondeterminism was managed by backtracking, was implemented using a very novel method for representing clauses, halfway between the technique based on structure sharing used by Robert Boyer and Jay Moore in their work on the proofs of programs [Boyer 1972; Moore 1974] and the backtracking technique used in the preliminary version of Prolog. Philippe came up with this solution during his stay in Edinburgh after many discussions with Robert Boyer. In this new approach, the clauses of a program were encoded in memory as a series of templates, which can be instantiated without copying, several times in the same deduction, by means of contexts containing the substitutions to be performed on the variables. 'This technique had many advantages compared to those normally used in automated theorem-proving: • in all known systems, unification was performed in times that were, at best, linear in relation to the size of the terms unified. In our system, most of the unifications could be performed in constant time, determined not by the size of the data, but by that of the templates brought into action by the clauses of the called program. As a result, the concatenation of two lists was performed in a linear time corresponding to the size of the first and not in quadratic time as in all other systems based on copying techniques; • in the same system, the memory space required for one step in a deduction is not a function of the data, but of the program clause used. Globally therefore, the concatenation of two lists used only a quantity of memory space proportional to the size of the first list; • the implementation of nondeterminism did not require a sophisticated garbage collector in the first approach but simply the use of several stacks synchronized on the backtracking, thus facilitating rapid management and yet remaining economical in the use of interpreter memory. Concerning the representation of the templates in memory, we decided to use prefix representation (the exact opposite of Polish notation). The system consisted of the actual interpreter (i.e., the inference machine equipped with a library of built-in predicates), a loader to read clauses in a restricted syntax, and a supervisor written in Prolog. Among other things, this supervisor contained a query evaluator, an analyzer accepting extended syntax, and the high level input-output predicates. Alain, who like all of us disliked FORTRAN, succeeded nonetheless in persuading the team to program the interpreter in this language. This basic choice was based primarily on the fact that
PROLOG SESSION
349
ALAIN COLMERAUER & PHILIPPE ROUSSEL
FORTRAN was widely distributed on all machines and that the machine we had access to at that time supported no other languages adapted to our task. We hoped in that way to have a portable system, a prediction that proved to be quite correct. Under Philippe's supervision, G&ard Battani [Battani 1973] and Henri Meloni developed the actual interpreter between June 1973 and October 1973 on a CII 10070 (variant of the SIGMA 7) while Rent Bazzoli, under Alain's direction, was given the task of writing the supervisor in the Prolog language itself. The program consisted of approximately 2000 instructions, of roughly the same size as the ALGOL-W program of the initial version. The machine had a batch operating system with no possibility of interaction via a terminal. Hence, data and programs were entered by means of punched cards. That these young researchers could develop as complex a system as this under such conditions and in such short time is especially remarkable in light of the fact that none of them had ever written a line of FORTRAN before in their lives. The interpreter was finally completed in December 1973 by GErard Battani and Henry Meloni after porting it onto the IBM 360-67 machine at Grenoble, thus providing somewhat more reasonable operating conditions. Philippe Roussel wrote the reference and user's manual for this new Prolog two years later [Roussel 1975]. 7.6
CONCLUSION
After all these vicissitudes and all the technical details, it might be interesting to take a step back and to place the birth of Prolog in a wider perspective. The article published by Alan Robinson in January 1965, "A machine-oriented logic based on the resolution principle," contained the seeds of the Prolog language. This article was the source of an important stream of works on automated theorem-proving and there is no question that Prolog is essentially a theorem prover "~ la Robinson." Our contribution was to transform that theorem prover into a programming language. To that end, we did not hesitate to introduce purely computational mechanisms and restrictions that were heresies for the existing theoretical model. These modifications, so often criticized, assured the viability, and thus the success, of Prolog. Robert Kowalski's contribution was to single out the concept of the "Horn clause," which legitimized our principal heresy: a strategy of linear demonstration with backtracking and with unifications only at the heads of clauses. Prolog is so simple that one has the sense that sooner or later someone had to discover it. Why did we discover it rather than anyone else? First of all, Alain had the right background for creating a programming language. He belonged to the first generation of Ph.D.s in computer science in France and his specialty was language theory. He had gained valuable experience in creating his first programming language, Q-systems, while on the staff of the machine translation project at the University of Montreal. Then, our meeting, Philippe's creativity, and the particular working conditions at Marseilles did the rest. We benefitted from freedom of action in a newly created scientific center and, having no outside pressures, we were able to devote ourselves fully to our project. Undoubtedly, this is why that period of our lives remains one of the happiest in our memories. We have had the pleasure of recalling it for this paper over fresh almonds accompanied by a dry martini. ACKNOWLEDGMENTS
We would like to thank all those who contributed to the English version of this paper: Andy Tom, Franz G0nther, Mike Mahoney, and Pamela Morton.
350
CHAPTER VII
PAPER: THE BIRTH OF PROLOG
BIBLIOGRAPHY [Battani, 1973] Battani, GErard and Henry Mcloni, interpr~teur du langage PROLOG, DEA report, Group¢ Intelligence Artificielie, Facult~ des Sciences de Luminy, Universit6 Aix-Marseilie II, France, i 973. [Battani, 1975] Battani, G6rard, Mise en oeuvre des contraintes phonologiques, syntuxiques et s~mantiques dans un systJme de comprEhe~tvion automatique de la parole, 3line cycle thesis, Groupe Intelligence Artificielie, Facult~ des Sciences de Luminy, Universit~ Aix-Marseille II, France, June 1975. [Bergman, 1973a] Bergman, Marc and Henry Kanoui, Application of mechanical theorem proving to symbolic calculus, Third International Colloquium on Advanced Computing Methods in Theoretical Physics, Marseilles, France, June 1973. [Bergman, 1973b] REsolution par la demonstration automatique de quelques probl~mes en integration symbolique sur calculateur, 3Sine cyie thesis, Groupe Intelligence Artificielle, Facult6 des Sciences de Luminy, Universit~ AixMarsoille II, France, Oct. 1973. [13¢rgman, 1975] Bergman, Marc and Henry Kanoui, SYCOPHANTE, syst~me de calculformel sur ordinateur, final report for a DRET contract (Direction des Recherches et Etudes Techniques), Groupe Intelligence Artificielle, Facult6 des Sciences de Luminy, Universit6 Aix-Marseille ll, France, 1975. [Boyer, 1972] Boyer, Roger S. and Jay S. Moore, The sharing of structure in theorem proving programs, Machine Intelligence 7, edited by B. Melzer and D. Michie, New York: Edinburgh University Press, 1972, pp. 101-116. [Chastellier, 1969] Chastellier (de), Guy and Alain Colmcraucr, W-Grammar. Proceedings of the A CM Congress, San Francisco, Aug., New York: ACM, 1969, pp. 511-518. [Chomsky, 1965] Chomsky, Noam, Aspects of the Theory ofSyntux, MIT Press, Cambridge, 1965. [Cohen, 1988] Cohen, Jacques, A view of the origins and development of Prolog, Commun. ACM31, 1, Jan. 1988, pp. 26-36. [Colmemuer, 1970a] Colmeraner, Alain, Total precedence relations, J. ACM IZ 1, Jan. 1970, pp. 14--30. [Colmerauer, 1970b] Colmorauer, Alain, Les syst~mes-q ou un formalisme pour analyser et synth~tiser des phrtL~es sur ordinateur, Internal publication 43, D6partement d'informatiqu¢ de 1'Universit~ de Montr6al, Sept. 1970. [Colmemuer, 1971] Colmeraner, Alain, Femand Didier, Robert Pasero, Philippe Roussel, Jean Trndel, R~pondre d, Internal publication, Groupo Intelligence Artificiellc, Facuh6 des Sciences de Laminy, Universit6 Aix-Marseille II, France, May 1971. This publication is a computer print-out with handwritten remarks. [Colmerauer, 1972] Colmerauer, Alain, Henry Kanoui, Robert Pascro and Philippe Roussel, Un syst~nw de communication en franfais, rapport pr~liminaire de fin de contrat IRIA, Groupe Intelligence Artificielle, Facult~ des Sciences de Luminy, Universit~ Aix-Marseilie II, France, Oct. 1972. [Colmeraner, 1975] Colmeraner, Alain, Les grammaires de metamorphose GIA, Internal publication, Groupe Intelligence Artificielie, Facult~ des Sciences de Luminy, Universit6 Aix-Marseille II, France, Nov. 1975. English version, Metamorphosis grammars, Natural Language Communication with Computers, Lectures Notes in Computer Science 63, edited by L. Bole, Berlin, Heidelberg, New York: Spnnger Verlag, 1978, pp. 133-189. [Darlington, 1969] Darlington, .I.L. Theorem-proving and information retrieval. Machine Intelligence 4, Edinburgh University Press, 1969, pp. 173-707. [Elcok, 1988] EIcok, E., W. Absys: the first logic programming language--A restrnspective and a commentary. The Journal of Logic Programming. [Floyd, 1963] Floyd, Robert W., Syntactic analysis and operator precedence. J.ACM I0, 1963, pp. 316-333. [Floyd, 1967] Floyd, Robert W., Nondeterministic algorithms. J. ACM 14, 4, Oct. 1967, pp. 636-644. [Green, 1969] Green, Cordell C., Application of theorem-proving to problem-solving, Proceedings of First International Joint Conference on Artificial Intelligence, W&~hingtonD.C., 1969, pp. 219-239. [Hewitt, 1969] Hewitt, Carl, PLANNER: A language for proving theorems in robots, Proceedings of First International Joint Conference on Artificial Intelligence, Washington D.C., 1969, pp. 295-301. [Jouhert, 1974] Jouhert, Michel, Un syst~me de resolution de probl~mes d tendance naturelle, 3~me cycle thesis, Groupe Intelligence Artificielie, Facult6 des Sciences de Luminy, Univcrsit6 Aix-Marseillc 11, France, Feb. 1974. [Kanoui, 1973] Kanoui, Henry, Application de la demonstration automatique aux manipulations alg~briques et fi l'int~gratlon formelle sur ordinateur, 3~rnecycle thesis, Groupe Intelligence Artificielle, Facult6 des Sciences de Luminy, Universit6 Aix-Marscilie II, France, Oct. 1973. [Kanoui, 1976] Kanoui, Henry, Some &~pectsof symbolic integration via predicate logic programming. ACM SIGSAM Bulletin, 1976. [Kowalski, 1971] Kowalski, Rohert A. and D. Knehner, Linear resolution with selection function, memo 78, University of Edinburgh, School of Artificial Intelligence, 1971. Also in Artificial Intelligence 2, 3, pp. 227-260. [Kowalski, 1973] Kowalski, Robert A., Predicate Logic as Programming Language, memo 70, University of Edimburgh, School of Artificial Intelligence, Nov. 1973. Also in Proceedings oflFIP 1974, Amsterdam: North Holland, Amsterdam, 1974, pp. 569-574.
PROLOG SESSION
351
ALAIN COLMERAUER [Kowalski, 1974] Kowalski, Robert A. and Maarten van Emden, The semantic" of predicate logic as programming language, memo 78, University of Edinburgh, School of Artificial Intelligence, 1974. Also in JACM 22, 1976, pp. 733-742. [Kowalski, 1988] Kowalski, Robert A., The early history of logic programming, CACM vol. 31, no. 1, 1988, pp 38--43. [Loveland, 1984] Loveland, D.W. Automated theorem proving: A quarter-century review. Am. Math. Soc. 29, 1984, pp. 1--42. [Luckam, 1971] Luckam, D. and N.J. Nilson, Extracting information from resolution proof trees, Artificial Intelligence 12, I, 1971, pp. 27-54. [Meloni, 1975] Meioni, Henry, Mise en oeuvre des contraintes phonologiques, syntaxiques et sdmantiques dans un ,~stdme de coraprdhension automatique de la parole, tl'~se de 3brae cycle, Groupe Intelligence Artificielle, Facult6 des Sciences de Luminy, Universit6 Aix-MarseiUe II, France, June 1975. [Moore, 1974] Moore, Jay, Computational logic" : Structure sharing and proof of program properties, part ! and H, memo 67, University of Edinburgh, School of Artificial Intelligence, 1974. [Pasero, 1973] Pasero, Robert, ReprEsentation du frantiais en logique du premier ordre en vue de dialoguer avec un ordinateur, t~se de 3~me cycle, Groupe Intelligence Artiflcielle, Facult6 des Sciences de Luminy, Universit6 Aix-Marseille 11, France, May 1973. [Pereira, 1980] Pereira, Fernando C. and David H.D. Warren, Definite clause grammars for language analysis, Artificial Intelligence. 13, 1980, pp. 231-278. [Robinson, 1965] Robinson, J.A., A machine-oriented logic based on the resoulution pnnciple, J. ACM 12, I, Jan. 1965, pp. 23---41. [Roussel, 1972] Roussel, Philippe, Ddfinition et traitement de l'dgaliM formelle en d~numstration automatique, th6se de 3i~me cycle, Groupe Intelligence Artificielle, Facult6 des Sciences de Luminy, Universit6 Aix-Marseille II, France, May 1972. [Roussel, 1975] Roussel, Philippe, Prolog, manuel de rEfErence et d'utilisation, Groupe Intelligence Artificielle, Facult6 des Sciences de Luminy, Universit~ Aix-Marseille 11, France, Sept. 1975. [Taum, 1971] TAUM 71, Annual report, Projet de Traduction Automatique de I'Universit6 de Montr6al, Jan. 1971. [Warren, 1974] Warren, David H. D.,Warplan, A System for Generating Plans, research report, University of Edimburgh, Department of Computational Logic, memo 76, June 1974. [Warren 1977] Warren, David H. D., Lnis M. Pereira and Fernando Pereira, Prolog the language and its implementation, Proceedings of the ACM, Symposium on Artificial Intelligence and Programming Languages, Rochester, N.Y., Aug. 1977. [Wijnganrden, 1968] van Wijngaarden, A., B. J. Mailloux, J. E. L. Peck, and G. H. A. Koster, Final Draft Report on the Algorithmic" Language Algol 68, Mathematish Centrum, Amsterdam, Dec. 1968.
TRANSCRIPT OF PRESENTATION ALAIN COLMERAUER: (SLIDE 1) I was supposed to give this talk with Philippe Roussel but he could not come. I won't speak so much about Prolog but about the circumstances which brought about the birth of the language. Unlike other programming languages, there was no institution which decided to create Prolog. Prolog was born in a spontaneous way, as a software tool for natural language processing. These are the succesive topics of my talk: (SLIDE 2) After my PhD in Grenoble, I went, as Assistant Professor, to the University of Montreal where I got involved in an automatic translation project. It was within the framework of this project that I developed a software tool, called "Q-systems", which in fact turned out to be a forerunner of Prolog. The letter "Q" stood for Quebec. At the end of the 70s, I went back to France where I got a position as Professor in Marseilles. There I met Philippe Roussel and we started to develop a natural language communication system involving logical inferences. After a first "primitive" system, we developed a more sophisticated one, which led us to design and implement a preliminary version of Prolog, which I will call, "Prolog 0." We then developed a full version of the language, which I will call "Prolog 1". This version had a wide distribution. After describing all this in detail, I will conclude by giving information about direct and indirect contributions of various people to the birth of Prolog.
352
CHAPTER VII
TRANSCRIPT OF PROLOG PRESENTATION
The Birth of Prolog
• 1970 Automanlic translation project • 1970 Q-systems, a forerunner
Alain Colmerauer and Philippe Roussel
• 1971 Primitive natural language communication system • 1972 Natural language communication system
University of Marseille
SLIDE
1
SLIDE
2
(SLIDES 3 and 4) First let us talk about the automatic translation project which was given the name TAUM, for "Traduction Automatique Universit6 de Montr6ar'. We were supposed to translate texts from English into French, and here is a typical example of a sentence to be translated. (SLIDES 5 and 6) Slide 5 shows the input and slide 6 shows the output. The input sentence was translated using Q-sytems rules which were essentially rewriting rules on sequences of complex symbols. (SLIDE 7) You would take the input sentence and cut it into pieces separated by plus signs. The " - 1 - " indicated the beginning of the sentence and " - 2 - " the end. Then you would apply rules on subsequences of elements. You would apply a first set of rules and then you would obtain this. (SLIDE 8) "The" has been transformed into a definite article, "expansion" is a noun and so on. This makes up the first step in morphology. Then you would add another phase and you would end up with just one complex symbol. (SLIDE 9) What results is, in fact, a tree, in which you would have all the information contained in the sentence. Then you would have another set of Q-system rules which would take the tree and cut it into little pieces of complex symbols. While cutting it into little pieces you would start to produce some French. (SLIDE 10) Then you would parse this output, obtain a French deep structure... (SLIDE 1 1 ) . . . and then you would produce a French sentence.
• 1972 Prolog 0
Automatic translation
• 1973 Prolog 1 • 1974-1975 Distnbution of Prolog • Contnbutions of people
SLIDE
PROLOG SESSION
3
project: TAUM Montreal, 1970
SLIDE
4 353
ALAIN COLMERAUER
THE
EXPANSION
GOVERNMENT CANADA
L'EXPANSION
OF
ACTIVITIES
AS
COUNTRIES
IN
MANY
IS
NOT
COMME
OTHER SOMETHING
-i-
THE
+
GOVERNMENT
+
IN
+
+
+ OTHER
IS
+ NOT +
.
+ OF
+
IN
+
+
SOMETHING
+
-2-
N'EST
CHOSE
-i-
SENTENCE(PH(GOV(T(PRS3
SCONJ(AS)
-2-
P(AS)
-3-
-3-
P(IN)
...
-i-
+ NE
+ NP(N(C
+
[(PH) +
*GPR +
] +
+
*(.)
+
] +
] +
^ + NO(l)
AB,*DV),/))
+
-2-
.
+
+
... / + +
SLIDE
-4-
8
[(GOV)
[(OPS)
PAS +
-2-
-3-
LOC,*LOC)),/,*AB,*PL)),/,*
9
...
SLIDE
THING)
SLIDE
6
+ N(EXPANSION +
-2-
+
-2-
NOUVEAU.
ANADA),/,*C,*PROP,*NT)
S),OPS(INV(NOT)),NP(N(SOME ..... ADJ(OTHER,/),/,
CANADA
PAS
DE
ART(DEF)
7
*H,*C,*GP,*PL,*LOC),/,*C,*
354
PAYS
,/,*AB,*DV)
+ COUNTRIES
SLIDE
-i-
AUTRES
AU
SLIDE
+ ACTIVITIES + AS
ACTIVITES
PLUSIEURS
$
EXPANSION
+ CANADA
MANY
NEW
DANS
QUELQUE
NEW.
SLIDE
DES
GOUVERNEMENTALES
IN
[(T)
[(INV) +
*PL
*AB
+
*
+
^
/
+
]
+
+
10
CHAPTER
VII
TRANSCRIPTOF PROLOG PRESENTATION
-i-
L
(NE, PAS)),SN(N(QUELQUE,CHO
S
ACTIVITES
SE),ADJ(GOUVERNEMENTAL,/).
NTALES
GP(P(DANS),SN(CONJ(COMME),
E
SN(N(CANADA)
RES
-I-
PH(GOV(T(*IPR),OPS(INV
..... )),/,/,*F
+
E
. -2-
SLIDE
+
+
' +
+
DANS +
PAS
,*AB,*PL,3)),/,/*F,*AB,*S,3 ,),/)
+
+
+
AU +
PAYS +
EXPANSION
+
DE
CANADA
+COMM
PLUSIEURS
+
+
EST
N
QUELQUE
NOUVEAU
11
+
GOUVERNEME
+
+
' +
+
CHOSE
AUT
+
+ D
. -2-
SLIDE
12
(SLIDE 12) This is just to give an idea of what we were doing. (SLIDE 13) I would like to say a few words about the Q-systems. Essentially a Q-system is a set of rewriting rules. (SLIDE 14) Here the third rule states that the subsequence X + C can be rewritten as the sequence C + X. When you apply the rewriting rules on an input sequence like A + A + B + B + C + C, you want to be very efficient and avoid a large search space. The way we did it, was to represent each symbol occurrence by an arrow labeled by that symbol and thus to represent the input sequence by a graph. Then the result of applying the different rewriting rules becomes the following graph. (SLIDE 15) This graph representation leads to an efficient bottom-up parser which keeps most common parts together. The important thing was that, within a rule, you were allowed to speak about complex symbols and complex symbols were just trees, like the ones we now have in Prolog. To denote complex symbols, that is, trees, we were using formulae, similar to Prolog terms, with the difference that there were three kinds of variables, each represented by a single letter followed by an asterisk. A variable with a letter from the beginning of the alphabet, like tA," was used to denote an unknown label of a node, a variable with a letter in the middle of the alphabet, like "I," was used to denote a whole unknown tree and a variable with a letter at the end of the alphabet, like "X" and "Y," was used to denote an unknown sequence of trees.
A + B + C - > S
Q-Systems
A
+
S
+
Montr6al, 1970
PROLOG SESSION
13
+
C
->
S
B + B - > B + X
A
SLIDE
X
X + C - > C + X
+
A
+
B
+
B
SLIDE
+
C
+
C
14
355
ALAIN COLMERAUER
C
D
X
P
+
Q(R,S,T)
P
+
A*(X*,I*,Y*)
R
A p
P
it
SLIDE
Im
15
P
+
P
I*
+
->
+ Q(S,T)
+
S +' Q ) R , T )
+
P
T
+
P
+ Q(R,S)
A*(X*,Y*)
P
D
SLIDE
16
(SLIDE 16) So, for example, if you apply the rule in the middle of this slide, to the sequence at the top of the slide you obtain the three different sequences at the bottom of the slide, according to the fact that the variable "I*" matches "R," "S," or "T." Here we have a nondeterministic unification, but it is not a true unification, it is more like a pattern matching because it just works in one direction. But, the status of the variables here was already the same as in Prolog. They were true unknowns. (SLIDE 17) The Q-systems were very efficient and they are still used in a program which every day translates Canadian weather reports from English to French. This slide shows an example of such a translation made in 1978. (SLIDE 18) During my stay at the University of Montr6al, I was surrounded by a large team of linguists and I had to spend a lot of energy to make the computer scientists work together with them. Also, I was working more on syntactical aspects of natural languages than on semantical aspects, and my knowledge of English was, and is still, too poor to work on English syntax. So I wanted to stop working on automatic translation and do research in the processing of information contained in French sentences. Just before I went to Marseilles I was introduced to the "Resolution Principle" paper by Alan Robinson about automatic theorem proving. I was very impressed and then saw the possibility of designing a system able to "understand" statements and questions written in French and able to do the right logical inferences for answering the questions. So, I arrived in Marseilles together with Jean Trudel, a Canadian doctoral student, in the winter of 1971. Both Jean and Philippe Roussel started to write different theorem provers ~t la Robinson. But, instead of proving mathematical theorems, Jean always tried to do inferences on little stories. (SLIDES 19 and 20) This is the kind of logical axiom he was writing for this purpose: reflexivity (axiom 1) and transitivity (axiom 2) of the subset relation as shown: if the sets "x" and "y" are in the relation "r", and if "x" prime is a subset of "x" and "y" prime is the subset of y then "x" prime and "y" prime are also in the relation "r" (axiom 4). For example, if the boys love the girls, then if you take a boy and a girl then that boy will love that girl. It's very naive but if you work on natural languages, you always have the problem of plural noun phrases which denote sets. Thus all your relations are on sets and you have to make a connection between sets, subsets, and your relations. We also had a lot of trouble with thesubset relation because the addition of a communitivity axiom was producing a lot of unnecessary inferences. So we only allowed communitivity in the case where we were sure that every subset was a singleton (axiom 3).
356
CHAPTER VII
TRANSCRIPT OF PROLOG PRESENTATION
TAUM METEO 1978 CLOUDY
WITH
A CHANCE
SHOWERS
TODAY
NUAGEUX
AVEC
D AVERSES
AND
OF
THURSDAY
Primitive natural language communication system Marseille, 1971
POSSIBILITE
AUJOURD
HUI
ET
JEUDI.
SLIDE
17
SLIDE
18
3
( Vx)[Subset(x,x)],
(Va)(1Vb)[Subset(The (a)], The (b)) Subset(The(b), The(a))],
2
4
(Vx)(Vy)(Vz)[Subset(x,2) A Subset(y,z) = Subset(x,z)],
(Vx)('V'y)(Vr) ~ ' ) (Vy') ['rrue(r,x,y) ^ Subset(.f,x) ^ Subset(y',7) ~ True(r,x',2')].
1
SLIDE
CATS TOM
KILL
19
MICE.
IS A C A T W H O
LIKE MICE JERRY
SLIDE
WHO
>
DOES
NOT
EAT CHEESE.
IS A M O U S E
WHO
EATS
TOM DOES WHO
>
TOM KILLS
WHO
> TOM. WHAT
DOES
TOM DO?
SLIDE 21
PROLOG SESSION
MICE.
IS A C A T ?
CHEESE.
WHAT
LIKE MICE
EAT CHEESE.
MAX
IS N O T A M O U S E .
NOT
20
DOES
JERRY
EAT?
SLIDE
22
> CHEESE.
357
ALAIN COLMERAUER
WHO
DOES
NOT
LIKE MICE
WHO
EAT CHEESE?
• 50 Q-systems rules to translate s e n t e n c e s into logical statements. • 4 added logical statements.
> TOM.
Q-systems rules to translate the deduced logical statements into sentences.
• 17
WHAT
DOES
TOM
EAT?
> WHAT
CATS
WHO
DO NOT
LIKE
MICE
WHO
EAT
CHEESE
EAT.
SLIDE
23
SLIDE
24
(SLIDES 21, 22, 23, and 24) By putting together the four axioms, a whole theorem prover, a little Q-system to parse sentences in French, another one to produce answers, we were able to have the conversation shown in the slides and in which sentences starting with a ">" prompt are answers generated by the computer. Our taste for embedded relative clauses must be noticed when, to the query "What does Tom eat?" the computer replies "What cats, who do not like mice who eat cheese, eat." (SLIDE 25) We thought maybe we could use the theorem prover not only for making inferences, but also for the parsing and for the synthesis of the sentences. I spent a long time solving this problem. (SLIDE 26) I think it was in the summer of 1971 that I found the trick for writing a context-free parser using logical statements. It is a trick that is now well known under the name "difference lists". If you consider the first context-free rule of slide 26, you would like to write roughly: if"x" is of type "B" and if "y" is of type "C", then "x" concatenated with "y" is of type A. You would then have to run a concatenation subprogram and the parser would be very inefficient. So you just write: if the list "x" minus "y" (that is, the list "x" from which you have suppressed the ending list "y") is of type B and if the list "y" minus "z" is of type "C" then the list "x" minus "z" is of type "A." After this discovery, I decided that from now on we should program everything by just writing logical statements and use a kind of theorem prover to execute our statements. So we wrote a special theorem prover that I have called Proiog 0 and we wrote the first Prolog program which was already large.
Natural language communication system
A~BC, A~a.
Marseille, 1972. (Vx)(Vy)(Vz)
A Prolog program of 610 clauses. SLIDE
358
25
[A(x,z) ~ B(x,y) ^ C(y,z)],
(Vx)[A(list(a,x),x)].
SLIDE
26 CHAPTER VII
TRANSCRIPT OF PROLOG PRESENTATION
•
164 clauses to encode pronouns, articles, and prepositions,
• 104 clauses for linking singular and
plural,
EVERY
EVERY
• 334 clauses for the parsing, • 162 clauses for the deductive and
PSYCHIATRIST
IS A
PERSON. PERSON
HE A N A L Y Z E S
IS SICK. *JACQUES
IS A P S Y C H I A T R I S T
IN * M A R S E I L L E .
answering part.
SLIDE
27
SLIDE
28
(SLIDE 27) This is the size of the different parts of the program: a dictionary of pronouns, articles and prepositions, a small morphology of French, a large parser of French sentences and finally a part for computing and generating answers. (SLIDES 28 and 29) These are the kinds of sentences you were able to give as input to the computer. In these sentences the computer knows only the words "every," "is," "a," "he," "in" (that is, prepositions, articles and pronouns) and recognizes the proper nouns "Jacques" and "Marseille" because of the asterisk in front of them. With this input, you asked the questions : "Is Jack a person?", "Where is Jack?" "Is Jack sick?" and then you got the answers. (SLIDE 30) This system was written using Prolog 0, the very first Prolog. (SLIDE 31 ) For the syntax of Prolog 0 programs, this gives an idea. I was using an asterisk in front of the variables (in the Q-systems I used to put an asterisk after the variables). The minus sign denotes negation, the plus sign is used otherwise and all the atomic formula are implictly connected by "or" connectors. At the bottom of the slide you can see the way you would write the same program now if you use the normalized Prolog which I hope will come out soon. There were some main differences between Prolog 0 and current versions of Prolog. There was not a simple cut operation but there were different double punctuation marks at the end of each clause to perform different types of search space reductions.
IS
*JACQUES
WHERE
IS
A PERSON?
*JACQUES?
IS J A C Q U E S
SICK?
> > >
KNOW.
Prolog 0 Marseille, 1972.
YES. IN
*MARSEILLE.
I DO N O T
SLIDE
PROLOG SESSION
29
SLIDE
30
359
ALAIN COLMERAUER
+APPEND(NIL,*Y,*Y). +APPEND(*A.*X,*Y,*A.*Z) -APPEND(*X,*Y,*Z). append([],Y,Y). append([AlX],Y,[AIZ] :append(X,Y,Z).
SLIDE
31
No cut operation but double punctuation marks at the end of the clause: .. .; ;. ;;
cuts after the clause head, cuts after the whole clause, gives only the first answer, do not cut.
SLIDE
32
(SLIDE 32) For example you would put a double dot if you wanted to perform a cut after the head of the clause. There were very few predefined predicates. (SLIDE 33) There was a"DIF" predicate to write nonequal constraints. You could write "X" is not equal to " Y ' and it would delay the test until "X" and " Y ' were enough known. So Prolog 0 already had features which we later put in Prolog II. There was a primitive called "BOUM" to split or create an identifier into, or from, a string of characters. And somebody wanted to have a strange thing which was to copy terms and rename the variables. We didn't like it but we were forced to add the "COPY' predicate. There was no explict input and output instructions. For the ouput, what you were supposed to do was to put a slash in some clauses and then all the literals after the slash would be delayed and accumulated. At the end the Prolog 0 interpreter would print the sequence of all these literals. What you would input, would in fact be a set of clauses and the output would be another set of clauses which would be entailed by the first set of clauses. This was Prolog 0. (SLIDE 34) Then we decided to make a full programming language which I have called Prolog 1. This language was very close to the actual Prolog programming language. (SLIDE 35) With Prolog 1, there was the introduction of a unique cut operation and no more not-equal constraints. There were all the classical built-in predicates like input, output, assert, retract. The names of the last two ones were "AJOUT' and "SUPPRIMER". There was a metacail: you could
Predefined predicates: • DIF for the # constraint of Philippe's dissertation, • B O U M to split or create an identifier, • C O P Y to copy a term.
SLIDE
360
33
Prolog 1 Marseille, 1973
SLIDE
34 CHAPTER VII
TRANSCRIPT OF PROLOG PRESENTATION
• Introduction of the unique cut operation. • Suppresion of # constraints. • Classical predefined predicates: input, output, assert, retract ... • Meta-call: use of a vadable instead of a literal.
"The present system is implemented partly in Fortran, partly in Prolog itself and, running on an IBM 360-67, achieves roughly 200 unifications per second." David Warren
SLIDE 35
SUDE
36
use a variable instead of a literal. This was because a large part of Prolog was written in Prolog itself and thus we needed some meta level. (SLIDE 36) We had a visit from David Warren. This was in January 1973. After his visit, David wrote the sentence shown, which among others gives the speed of our implementation. In fact, an early version of Prolog 1 was running on a Sigma 7. This computer was sold in France by BULL, but under a different name. (SLIDE 37) The fact that the interpreter was written in FORTRAN was very helpful in the distribution of the language. We had a lot of visitors who came and took a copy away with them. First what happened was that different people started using Prolog to do something other than natural language processing. (SLIDE 38) The first other application was a plan generation system made by David Warren who was visiting us. Then there were people like Marc Bergman and Henry Kanoui who started to write a symbolic computation system. Then Henri Meloni started to make a speech recognition system using Prolog. (SLIDE 39) At the same time people came and took Prolog away to Budapest, University of Warsaw, Toronto, University of Waterloo, University of Edinburgh, University of Montreal, and INRIA in Paris. I was later told that David Warren took a copy from Marseilles and brought it to Stanford. From there Koichi Furakawa took a copy to Tokyo. This story was related in an issue of The
Washington Post.
The distribution of Prolog 1974-1975
SLIDE
PROLOG SESSION
37
• Plan generation system • Symbolic Computation system • Speech recognition system
SLIDE
38
ALAIN COLMERAUER
• Budapest,
• • • • • •
University of Warsaw, Toronto, University of Waterloo, University of Edinburgh, University of Montrdal, IRIA, reseamh center in Pads.
SLIDE
39
People and papers who influenced the work on Prolog
SLIDE 40
(SLIDE 40) I wanted to talk about the people and papers who influenced the work around Prolog. First, it sounds strange but Noam Chomsky had a strong influence on my work. When I did my thesis, I worked on context-free grammars and parsing and I spent a long time on this subject. At that time, Noam Chomsky was like a god for me because he had introduced me to the context-free grammars in his paper mentioned at the top of this next slide. (SLIDE 41) Also, when I was in Montreal, I discussed with people who were working in linguistics and these people were very influenced by the second paper mentioned in the same slide. If you look at this second paper from the point of view of a computer scientist, you understand that you can do everything in a nice way if you just use trees and transform them. I think this is what we are all doing. We are doing this in Lisp; we are doing this in Prolog. Trees are really good data structures. (SLIDE 42) Another person who is not a linguist but a computer scientist and who had a strong influence was Robert Floyd. He visited me when I was still a student in Grenoble and I was very impressed by him. I did my thesis starting from the first paper mentioned in the slide. I knew about the work described in the second paper before it was published. So I understood the way to implement a nondeterministic language, how to do the back-tracking, how to save information in a stack, and so on, and how to do it in an efficient way. (SLIDE 43) Another person who influenced me was A. van Wijngaarden. I was influenced in two ways. First, as a student I participated in different meetings to design a new ALGOL 60. I was very
Noam Chomsky On certain formal properties of grammars, Information and Control,
Robert Floyd Syntactic analysis and operator precedence. J. ACM, 1963.
1959.
Aspects of the Theory of Syntax, MIT Press, 1965.
SLIDE
362
41
Nondeterministic algorithms. J. ACM, 1967.
SLIDE 42 CHAPTER VII
TRANSCRIPT OF PROLOG PRESENTATION
A. van Wijngaarden Final Draft Report on the Algorithmic Language Algol 68, Mathematisch Centrum, Amsterdam, 1968 (with B.J. Mailloux, J.E.L. Peck, and G.H.A. Koster).
SLIDE 43
Alan Robinson A machine-onented logic based on the resolution principle. J. ACM, 1965.
SLIDE 44
impressed to see that people, starting from nothing, were creating a whole language. It's hard to believe that you can just take a sheet of paper and design a new language which will be used by many people. Secondly, I was very strongly influenced by the W-grammars, which is my name for the formalism introduced by A. van Wijngaarden to describe ALGOL 68. And in fact, I wrote a complete parser for languages that are generated by W-grammars. I also wrote a complete generator and I used both for performing automatic translation before using the Q-systems. (SLIDE 44) Of course, I think that Prolog would not have been born without Alan Robinson. I did not get the paper mentioned in the slide directly. I was still at the University of Montreal, and a student came, Jean Trudel, and showed me the paper. I looked at it and I didn't understand anything. I was not trained in logic at all. Jean Trudel spent a lot of time working on the paper and explaining it to us. This was a very important paper. (SLIDE 45) There was another influence: Robert Kowalski. When we arrived in Marseilles, we were not trained in logic and we were looking at all the papers written on automatic theorem proving. But we didn't exactly have a feeling for why things were made in such a way. So we invited people who knew a lot about automatic theorem proving. Robert Kowalski came to visit us and of course something clicked. He talked about logic, we wanted to do inferences and he did not know a lot about computers. So we began a very close collaboration. He had a very nice prover which was essentially
Robert Kowalski Linear resolution with selection function, Artificial Intelligence, 1972, (with D. Kuehner).
SLIDE
PROLOG SESSION
45
People who contributed directly to the work around Prolog
SLIDE 46 363
JACQUES COHEN
• Richard Kittredge, University of Montr6al, • Jean Trudel, Hydro Qu6bec, Montr6al,
• G6rard Battani, • Henri Meloni, • Ren6 Bazzoli.
• Robert Pasero, University of Marseille.
SLIDE
47
SLIDE
48
a resolution prover and the first Prolog was somehow an imitation of his complete SL-resolution method mentioned in the slide. (SLIDE 46) These are people who were more directly involved with the implementation or discussion which were next door. (SLIDE 47) First, I learned a lot from Richard Kittredge at the University of MontrEal. He was a linguist who had received his Ph.D. from Zelleg Harris. I wanted to thank Jean Pierre Trudel because he was really the person who filled the gap between Robinson's paper and our own work. Robert Pasero is the person who was always involved on the natural language processing side of Prolog. (SLIDE 48) And there are three other people who really were the implementors of Prolog 1 which was written in FORTRAN: they are Gerard Battani, Henri Meloni, and Ren6 Bazzoli. The first Prolog interpreter was their first FORTRAN program! That is all I have to tell.
TRANSCRIPT OF DISCUSSANT'S REMARKS SESSION CHAIR RANDY HUDSON: Jacques Cohen is a Professor in the Michtom School of Computer Science at Brandeis University. He has two Doctorates, one from the University of Illinois, the other from the University of Grenoble, France. He has held visiting positions at MIT, Brown, and at the University of Marseilles where the Prolog language originated. From 1963 to 1967 he was a colleague of Alain Colmerauer as a Doctoral student at the University of Grenoble. At that time, they had similar interests in syntax-directed compilation and nondeterminism. Jacques interacted only informally with Alain in the 1970s. In 1980, he was invited by Alain, now the head of the Artificial Intelligence group at the University of Marseilles, to teach a yearly course on compilers. Since the early 1980s, Jacques has been an aficionado of Prolog and has written several papers on logic programming including one on its early history. Jacques' current research interests are in the areas of compiler development using logic programming, parallelism, and constraint languages. He is currently Editor in Chief of Communications of the ACM. Jacques is a member oftbe Program Committee of this conference. JACQUES COHEN: In the first HOPL Conference the discussant for the Lisp language was Paul Abrams who rightly pointed out that LISP was unusual in the sense that it had not been designed by a committee, but it was an invention or, if you want, a discovery of a single individual, John McCarthy. Abrams also mentioned that he knew only one other language with a similar origin. That was APL,
364
CHAPTER VII
TRANSCRIPT OF DISCUSSANT'S REMARKS
the brain child of Ken Iverson. One can state that Prolog also belongs to that category of languages. Prolog had a pnncipal inventor, Alain Colmerauer, who contributed to most of the ideas underlying that language. Robert Kowalski and Philippe Roussel also played key roles. The first one, as an expert of automatic theorem proving, the second one as a doctoral student of Alain's who implemented the first version of Prolog. Alain and Philippe admit in their paper that had Prolog not been discovered by them, it would have certainly appeared later under a form which would be recognizable as a variant of Prolog as it is known nowadays. I wish to emphasize that this in no way diminishes the amazing feat of having been the first to discover this beautiful language. Again, a parallel with Lisp is in order. Prolog, like Lisp, has a very simple syntax and embodies an elegant set of primitives and rules. In my view, both languages appear to be so simple and effective for expressing symbolic computation, that they would have come into existence sooner or later. In the 1960s I was a colleague of Alain as a doctoral student at the University of Grenoble. I remember that one of his first research projects was to write a syntax-directed error detector for COBOL programs. Alain avoided reading many technical papers because at the time he had some difficulties with English. I am sure that when he located a key paper he read it with great care. I believe that two papers from Robert Floyd had a considerable impact on Prolog. The first was on parsing and the second was on backtracking. Prolog rules can be viewed as grammar rules and parsing corresponds to the equivalent Prolog program. Furthermore, the subject of parsing is closely related to Alain's interest in natural language processing. It is relevant to point out that Alain became aware of Alan Robinson's seminal paper of resolution and unification five years after that paper had been published in the Journal of the Association for Computing Machinery. As happened in the case of the Floyd papers, Alain realized the importance of Robinson's work and that prompted him to contact experts in theorem proving like Robert Kowalski. In the conclusion of their paper, Colmerauer and Roussel state that their first Prolog interpreter was essentially a theorem prover ~ la Robinson. The great merit of the inventors is to transform a theorem prover into an interpreter for a novel programming language and that in itself represents a formidable task. To illustrate that transformation, let us consider the following experiment: Submit a set of current Prolog programs to Robinson's theorem prover. (A parenthetic remark is in order. That set of Prolog examples actually took several years to develop. It would not be available without the experience gained in programming in the new language.) Robinson's prover would perhaps provide the needed answers to the current Prolog programs. But, it would be excruciatingly slow or it would run out of memory, even using present-day workstations. The heart of Coimerauer's quest was how to make Robinson's prover work practically. Efficiency became of paramount importance and the Prolog designers were willing to use all sorts of compromises provided that they could solve the class of problems they had in mind. In Prolog's case the problem was natural language understanding using computers. The compromises that Alan Colmerauer was willing to make would stupefy even the most open-minded logician. First, they dropped completeness by performing only certain steps needed to prove a theorem. Therefore, they had no guarantee that if it was known that the theorem was provable, that the prover would inevitably find that proof. They also dropped an important test which is called "the occur-test," which insures that the unification works properly. In other words, they were willing to eliminate these costly tests even though certain programs would automatically result in an infinite loop. Finally, they introduced annotations (mainly to cut operations) that bypass certain computations in an effort to further increase the speed at the expense of missing certain solutions of a problem.
PROLOG SESSION
365
BIOGRAPHY OF ALAIN COLMERAUER
All this was done for the sake of increasing efficiency. But the gained efficiency was precisely what enabled Alain to experiment with the prover by concentrating on expressing problems in their embryonic language. That experience was crucial in making the transition from a theorem prover to an interpreter of a new programming language. The role of Robert Kowalski in cleaning up the rudimentary language that preceded Prolog is considerable. Kowalski's main contribution was the discovery that most of the sample problems that he and Alain were submitting to the general theorem prover were of a particular kind. They simply did not need all the power of the general prover. I have had the opportunity to discuss that discovery with Robert Kowalski. According to Robert, it was a moment in which the main faults in Alain's implementation actually became a superior advantage. It avoided the combinatorial explosion of Robinson's approach by restricting the form of the theorem submitted to the prover to the so-called Horn clauses. In so doing, we would then regain the formal advantages of dealing with logic. One can also state that the limitation of the occur-test and the introduction of cut were premonitions of the designers of the new language and the fertile new areas of research extending Prolog. In my view, the development of Prolog reflects Polya's advice for solving difficult problems. If you cannot solve a difficult problem, try to solve a particular version of it. In the case of Proiog, the particular version of the problem developed into a rich area of logic programming. Polya's approach seems to underline Prolog's historical development and it can be summarized by: first specialize then generalize. A discussion about the history of Prolog would be incomplete without a few remarks about implementation. I believe that the lack of a fast mainframe in Colmerauer's actually slowed down the development of Prolog. As I recall, even in 1980, Alain and his colleagues implemented one version of the first Prologs on an Apple II. It is known that Prolog interpreters have a voracious appetite for memory. The designers had to implement a virtual memory on the Apple II, using a floppy disk as slow memory. According to Alain and his colleagues the hardest part of this implementation was temporarily stopping a program using Control C and making sure that the information in memory was not destroyed. Fortunately, the visit to Marseilles of David H. Warren from Edinburgh enabled him to implement the first fairly efficient compiler for the PDP 10. It is fair to state that it was that compiler that contributed to a wider acceptence of Prolog. Finally, I would like to mention that in my view, the recent contributions that Alain has made in the area of constraint logic programming, equal or surpass his previous contributions as an inventor of Prolog. One can only hope that in HOPL III, he or one of his colleagues will present a paper on the evolution of Prolog into the new class of constraint logic programming languages.
TRANSCRIPT OF QUESTION AND ANSWER SESSION GUY STEELE from Thinking Machines: Q-systems seem reminiscent of the COMIT language. Was there any influence of one language on the other? COLMERAUER: I am not familiar with COMIT but I am familiar with SNOBOL. But in SNOBOL there is no parsing. Furthermore, in the Q-system the rules are not context free. They are general rules specifying the rewriting of trees. So, the answer is no.
BIOGRAPHY OF ALAIN COLMERAUER Alain Colmerauer was born in 1941 in Carcassonne, France. After receiving a graduate degree in computer science from the Institut Polytechnique de Grenoble, he received a doctorat from the
366
CHAPTER VII
BIOGRAPHYOF PHILIPPE ROUSSEL
University of Grenoble in 1967. The subject of his thesis was: precedences, syntactic analysis, and programming languages. His interest then turned from computer languages to natural languages. As an assistant professor at the University of MontrEal, he worked for three years on a project for automatic translation from English into French. Upon returning to France in 1970, he was appointed professor in computer science at the Faculty of Sciences of Luminy. There, together with Philippe Roussel, he designed the programming language Prolog which has become indispensable in the field of Artificial Intelligence. His work centers on natural language processing, logic programming, and constraint programming. A good introduction to his recent work is the article: An Introduction to Prolog III, in Communications oftheACM, July 1990. He has received these prizes and honors: • LaurEatde la Pomme d'Or du Logiciel franqais 1982, an award from Apple France shared with Henry Kanoui and Michel Van Caneghem. • LaurEatfor 1984 of the Conseil REgional, Provence Alpes et C6te d'Azur. • Prix Michel Monpetit 1985, awarded by the AcadEmie des Sciences. • Chevalier de la LEgion d'Honneur in 1986. • Fellow of the American Association for Artificial Intelligence in 1991. • Correspondant de l'AcadErnie des Sciences in mathematics. BIOGRAPHY OF PHILIPPE ROUSSEL
Philippe Roussel is presently Associate Professor at the University of Nice, Sophia Antipolis, and member of the I3S-CNRS Laboratory of the same university. He is the coauthor, with Alain Colmerauer, of the Prolog language. He implemented it for the first time in 1972, while he was a researcher at the University of Marseilles. He received his doctoral degree the same year, in the field of automatic theorem-proving. After spending six years in this university as an Assistant Professor in Computer Science, he joined the Simon Bolivar University in Caracas, Venezuela. He took charge of a cooperative program for developing a master's program in computer sciences, working on logic programming and deductive data bases. He returned to France in 1984, first as manager of the Artificial Intelligence Department of the BULL Company and later, as a scientific director of the Elsa Software Company. During this time, he conceived the LAP language, an object-oriented language based upon logic programming paradigms. His major research interest is knowledge representation languages for information system modeling.
PROLOG SESSION
367
VIII Discrete Event Simulation Languages Session
Chair:
Tim Bergin
A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES Richard E. Nance Director, Systems Research Center Professor of Computer Science Virginia Polytechnic Institute and State University Blacksburg, Virginia 24061-0251 ABSTRACT
The history of simulation programming languages is organized as a progression in periods of similar developments. The five periods, spanning 1955-1986, are labeled: The Period of Search (1955-1960); The Advent (1961 - 1965); The Formative Period (1966-1970); The Expansion Period (1971 - 1978); and The Period of Consolidation and Regeneration (1979-1986). The focus is on recognizing the people and places that have made important contributions in addition to the nature of the contribution. A balance between comprehensive and in-depth treatment has been reached by providing more detailed description of those languages that have or have had major use. Over 30 languages are mentioned, and numerous variations are described. A concluding summary notes the concepts and techniques either originating with simulation programming languages or given significant visibility by them. CONTENTS 8.1 Introduction 8.2 The Period of Search (1955-1960) 8.3 The Advent (I 961-1965) 8.4 The Formative Period (1966-1970) 8.5 The Expansion Period (1971-1978) 8.6 Consolidation and Regeneration (1979-1986) 8.7 Concluding Summary References
369
RICHARD E. NANCE
8.1
INTRODUCTION
This introductory section is intended to explain the different types of computer simulation and to identify the key issues in simulation programming languages (SPLs). The approach to this survey is the subject of a concluding subsection. 8.1.1
Computer Simulation
Analog (or analogue) simulation, that is, simulation on analog computers, is not addressed in this survey because no major "language" or language issues are associated with this early form. However, analog simulation was much in evidence during the 1950s and earlier. Digital simulation, that is, simulation on digital computers, is considered synonymous with "computer simulation" for this history of SPLs.
8.1.1.1
Taxonomy and Terminology
Computer simulation is an application domain of programming languages that permits further division into three partitions: 1. discrete event simulation, 2. continuous simulation, and 3. Monte Carlo simulation.
Discrete event simulation utilizes a mathematical/logical model of a physical system that portrays state changes at precise points in simulated time. Both the nature of the state change and the time at which the change occurs mandate precise description. Customers waiting for service, the management of parts inventories, or military combat are typical application domains for discrete event simulation. Continuous simulation uses equational models, often of physical systems, which do not portray precise time and state relationships that result in discontinuities. The objectives of studies using such models do not require the explicit representation of state and time relationships. Examples of such systems are found in ecological modeling, ballistic reentry, or large-scale economic modeling. Monte Carlo simulation, the name given by John yon Neumann and Stanislaw M. Ulam [Morgenthaler 1961, p. 368] to reflect its gambling similarity, utilizes models of uncertainty where representation of time is unnecessary. The term is originally attributed to "a situation in which a difficult nonprobablistic problem is solved through the invention of a stochastic process that satisfies the relations of the deterministic problem" [Morgenthaler 1961]. A more recent characterization is that Monte Carlo is "the method of repetitive trials" [Shreider 1966, p.1]. Typical of Monte Carlo simulation is the approximation of a definite integral by "circumscribing the region with a known geometric shape, then generating random points to estimate the area of the region through the proportion of points falling within the region boundaries. Simulation as a problem-solving technique precedes the appearance of digital computers by many years. However, the emergence of digital technology exerted an influence far more than adding the term "computer" as an adjectival descriptor of this method of problem solving. The oppressive manual computational burden was now off-loaded to a much faster, more tolerant processor--the digital computer. Three related forms of simulation are commonly noted in the literature. Combined simulation refers generally to a model that has both discrete event and continuous components (see [Law 1991, p. 112]). Typically, a discrete event submodel runs within an encapsulating continuous model. Hybrid simulation refers to the use of an analytical submodel within a discrete event model (see [Shantikumar 1983]). 370
CHAPTER VIII
PAPER:A HISTORYOF DISCRETE EVENTSIMULATIONPROGRAMMINGLANGUAGES
Finally, gaming or computer gaming can have discrete event, continuous, and/or Monte Carlo modeling components. 8.1.1.2
Language Requirements for Discrete Event Simulation
In her description of programming languages, Sammet [1969, p. 650] justifies the categorization of simulation languages as a specialization warranting limited description with the statement that, "their usage is unique and presently does not appear to represent or supply much carry-over into other fields." The impact of the object-oriented paradigm, and the subsequent clamor over object-oriented programming languages, first represented by SIMULA, would appear in hindsight to contradict this opinion, which accurately represented the attitude of the programming language research community at that time. A simulation language must provide a model representation that permits analysis of execution behavior. This provision entails six requirements: 1. generation of random numbers, so as to represent the uncertainty associated with an inherently stochastic model; 2. process transformers, to permit uniform random variates obtained through the generation of random numbers to to be transformed to a variety of statistical distributions; 3. list processing capability, so that objects can be created, deleted, and manipulated as sets or as members, added to and removed from sets; 4. statistical analysis routines, to provide the descriptive summary of model behavior so as to permit comparison with system behavior for validation purposes and the experimental analysis for both understanding and improving system operation; 5. report generation, to furnish an effective presentation of potentially large reams of data to assist in the decision making that initially stimulates the use of simulation; and 6. timing executive or a time flow mechanism, to provide an explicit representation of time. Every simulation programming language provides these components to some degree. Many simulation applications are undertaken in general purpose languages. Strongly influenced by this fact, simulation "languages" have taken three forms: package, preprocessor, and conventional programming language. A package is a set of routines in language X that can be called or invoked to meet the six requirements listed previously. The user (programmer) might develop additional routines in X to provide needed capabilities or a tailored treatment. Although such packages are not truly languages, some have had major influence, perhaps leading to descendants that take one of the other two forms, For example, the evolution of GASP, a package, produced SLAM, a preprocessor. All three "language" forms are included because examples of each have played significant roles in shaping the simulation scene.
8.1.1.3 Conceptual Frameworks for Discrete Event Modeling Very early, Lackner [1962, p. 3] noted the importance of a modeling perspective as a "WELTANSICHT' or world view that "must be implicitly established to permit the construction of a simulation language." In a subsequent work, he attempted to lay the groundwork for a theory of discrete event simulation and used the differing world views to categorize SPLs [Lackner 1964]. Lackner's categorization differentiates between event-oriented and activity-oriented SPLs. Kiviat [1967; 1969] expanded the categories to identify three world views: event-oriented, activity-oriented, and processoriented. DISCRETE EVENT SIMULATIONLANGUAGESESSION
371
RICHARD E. NANCE
Fishman [1973] helped to clarify the distinction among the categories, which he labeled "event scheduling," "activity scan," and "process interaction." These labels have become more or less the conventions in the literature. A recent thesis by Derrick [ 1988] expanded the three to 13, doing so in a manner that encompassed more than SPL discrimination. The differentiation among world views characterized by languages is captured best using the concept of locality [Overstreet 1986, p. 171]:
Event scheduling provides locality of time: each event routine in a model specification describes related actions that may all occur in a single instant.
Activity scanning provides locality of state: each activity routine in a model specification describes all actions that must occur due to the model assuming a particular state (that is, due to a particular condition becoming true).
Process interaction provides locality of object: each process routine m a model specification describes the entire action sequence of a particular model object. 8.1.2
Historical Approach
Although fundamental in distinguishing the modeling differences among SPLs, the world views do not suggest a basis for historical description for the following reasons: 1. the origins and initial development of the language(s) promoting a particular view took place concurrently without a clear progression of conceptual convergence, and 2. remarkably parallel development patterns are evident throughout the major SPLs, irrespective of world view ties. However, the extent and range of activity in SPLs mandates an organizational thesis, and a chronological presentation is used. A chronological depiction of SPL development could proceed in several ways. One could provide a vertical trace of developments within each SPL. The tack taken in this paper is more of a horizontal cut across periods of time, which are noted in the genealogical tree of SPLs, shown in Figure 8.1: 1955-1960: 1961-1965: 1966-1970: 1971-1978: 1979-1986:
The Period of Search The Advent The Formative Period The Expansion Period The Period of Consolidation and Regeneration
Each major language originating in a period is described in terms of its background and rationale for language content. Description of that language in subsequent time periods is limited to changes in that language, particularly those that mark the designated time period. Descriptions of GPSS and SIMULA are limited also; since both languages are treated extensively in the first conference devoted to programming language history (see [Wexelblatt 1981 ]). No attempt is made to describe language developments since 1986; sufficient time has yet to elapse to permit a historical perspective. Figure 8.1 is organized vertically to distinguish languages according to world view. This categorization cannot be precise, for the language developer in most instances was unaware of the distinguishing characteristic. Crookes [1982, p. 1] places the number of SPLs as 137, although giving
372
CHAPTER VIII
PAPER: A HISTORY FIGURE
OF DISCRETE
EVENT SIMULATION
PROGRAMMING
LANGUAGES
8.1
The Genealogical Tree for Simulation Programming Languages.
I~
.~
1'~ ...........................
• ~ o., o . . . . . . . . . . . . . .
_
." S
° •
A
--
__ 1 ~
•
;
o....o
,-~-J
o
A
, IlVkmtccodcl I SIMPAC, • " 0
•
........
,." ......
""
•
oo"
•
~
•
•
•
•
• •
/
o
~ •
~ •
~p
°'"
~
•
o"
0"
'o ~ ......................
,.F-~,
•
o" ~
•
D
, ~
•
•
". •
•
•
•
.
•
o
o
•
•
,o
.
, E
•
•
T
•
!
. . . . . . . . . . . . . . . . . . . . . . .
--o,.
T
I~
I
--~'
/
--
T
o
/
-
v.
/
,~..
•
I ......
0%
•
•
I ..................
° ""
"."
qr
--
° * ~ ...............................
"
•
~
-- C i~0
•
~
T ......
I . . . . . . . . . . . . . .
/
'
"
X
rI -
I
I'
I I I,~,,~..7 /I
'~1
I
r~l I
J,~,,
/
'
[
/
A L
/ l
~ - . . . . . . . . . . . . . . . . . I';J~um' .................
C
N
I
'~
I II II1-1 "
I
~
~1 I
I I
II I, I, Ii II ,i],, II
11 £ G £
e
....
,~,m, T
I /
~ .
cC%sIM I " I
/
~
/
/
~o ~ ~
~
/ / /
/
/
...... s ! ~ P " ! ! ~ ' .... ~H.¶/
GASPIV
~
_oo
...........
c~.
~
I~OO. /
/
S R
o
:
1'
...... I ..... / . . . . . . . . . . . . . . . . . . . . ~~,J;® /
.~.-~'~,~v I . "
O
*--~
17,c~ GI'S7'360
~.~ ~ w = r--r----'
E .............. / ............. /
' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I~'SSII L,NPII
II
sAI.rl • i
.
i-. . ~[~Z ...... ,. . ~l . i . ~ . ] .] . ' ' . H . . . .
'
GI~S/PC
,- '.°I --
A T
--
I 0
NI~l'Wq T
SII~FAC'IORYII-~
! 0 N
C ~ V ~ T H.5
N
DISCRETE
EVENT SIMULATION
LANGUAGE
SESSION
373
RICHARD E. NANCE
no source, and attributes this overpopulation to a lack of standardization in general purpose computer languages. More likely, the excess in SPLs can be attributed to a combination of root causes: 1. perceived differences among application domains, requiring language features not provided in extant SPLs; 2. lack of awareness of SPLs or the reliance on the general purpose language "crutch" leading to package development; 3. educational use of a well known language in which components are provided so that learning time is reduced and the cost of an additional translator is avoided; and 4. competition among language vendors to exploit particular features or selected application domains. The degree to which each of these causes has proved influential is quite dependent on time. The first and second tend to mark the early periods; the fourth, the later periods. One further point concerns the unfortunate but all too common instances of incomplete references, primarily missing dates. In the attempt to provide as much historical information as possible, dates are given if suggested by other sources, added notes (time stamps), or personal recollection. In those cases where the data is uncertain, a"Y' suffix is placed in the citation, for example, [Meyerhoff 1968?] indicates that the recollection of Paul Roth is that this undated manual was completed in 1968 [Roth 1992].
8.2 THE PERIOD OF SEARCH (195,5.-1960) The title of this subsection is derived from the efforts during this period to discover not only concepts of model representation but to facilitate the representational needs in simulation modeling. Simulation languages came into being with the recognition of the power of the technique in solving problems that proved intractable to closed-form mathematical solution. The most prominent examples of such problems are the early manufacturing simulations by a group at General Electric; Jackson, Nelson, and Rowe at UCLA; and Baker and Dzielinski cited in Conway [1967, p. 219]. K.D. Tocher is generally credited with the first simulator described in a 1960 publication jointly with D.G. Owen [Tocber 1960]. The simulator, later called GSP (General Simulation Program), introduced the three-phase method of timing control generally adopted by activity scan languages. Significantly, Tocher characterized his work as "searching for a simulation structure," rather than merely providing a"simulation language," [Tocher 1960, p.51 ]. Excerpts from the GSP example given in the appendix of the 1960 paper are shown in Figure 8.2. Although lacking the format regularity of assembly language programs, the syntactic structure of GSP seems to fall far short of the descriptor "automatic programming of simulations," [Tocher 1960, p.51]. However, this seemingly inflated claim was typically applied to languages other than basic machine coding, including assemblers (see [Rosen 1967] for examples). In the United States interest in simulation was emerging rapidly in the late 1950s; however, the recognition of concepts and the assistance of languages in dealing with them was less recognized. Gordon [1981] describes his own efforts prior to 1960 as the writing of simulation programs for message switching systems. The Sequence Diagram Simulator, described in a conference in 1960, indicates some appreciation of language support for the application task [Gordon 1981, p. 405]. The treatment given to computer simulation in the 1961 issue of Progress in Operations Research [Ackoff 1961 ] demonstrates the perceived importance of the technique. However, the issue of manual
374
CHAPTER VIII
....
~'~ ~ .
~'~
~
~
~.
•
o~
o
~®~
- ~
=
~ . ~
~
~°
~
,~
~
~
~
....
~
o
4 ~ .
~
~
~
++~
~ ~
•~
~
t
~ ~
~ ~
~
~
,
~o~
~ ~~
~ ~
~
~
o
~
o
~
~ o
~ ~ ....
~
+
~
~
~
+ .~
~
o ~
~ ~
~ ~
~ +
~
o
~
,~
~
7
~.~.~
. i,
~
II
~+~ 0
÷
!i
~
~.~
•
°
+
.
.
~
.
+
.
.
.
2
~
~
.
~
-
~
RICHARD E. NANCE
versus computer execution is still a matter of consideration [Morgenthaler 1961, pp. 406-407], and little consideration of language needs is indicated.
8.3 THE ADVENT (1961-1965) The periodof 1961-1965 marks the appearance of the forerunners of the major simulation programming languages currently in use. This claim is documented to some extent in the genealogical tree for SPLs (Figure 8.1). The historical development of GPSS and SIMULA are described in detail in Wexelblatt [1981]. Herein, each is described sufficiently to furnish a trace of the evolution of the language through the subsequent time periods. More detailed description is provided for other languages emerging during this period, although none can be described to the extent permitted in the first conference. 8.3.1
GPSS
Beginning with the Gordon simulator in 1960, the General Purpose System Simulator (GPSS) was developed on various IBM computers, for example, 700,709, and 7090, during 1960--1961. With the later name change to the General Purpose Simulation System, GPSS developments continued under the version labeled GPSS II, which transitioned from table-oriented to list processing techniques. The GPSS III version released in 1965 was made available primarily for the large IBM systems (7090/94 and 7040/44) [IBM 1965]. A major issue was the lack of compatibility between GPSS II and GPSS III. GPSS has the distinction of being the most popular SPL. Uses and users of the language outnumbered all others during the early years (prior to 1975). No doubt, this popularity was due in part to the position of IBM as the premier marketing force in the computing industry, and GPSS during this era of unbundled software was the discrete event SPL for IBM customers. That fact alone, however, does not explain the appeal of GPSS. The language readily gained proponents in the educational community because of the speed with which noncomputer-oriented students could construct a model of a queueing system and obtain numerical results. Originating in the problem domain of communication systems, the GPSS block semantics were ideally suited for queueing models (although logic switches might have puzzled many business students). The importance of graphical output for on-line validation was demonstrated in 1965 using an IBM 2250 interactive display terminal tied to a GPSS model [Reitman 1992]. Boeing (Huntsville) was the first to employ this device to enable the observation of model behavior and the interruption and restart during execution. 8.3.2
SIMULA I
The selection of GPSS and SIMULA by the program committee for the first conference on the History of Programming Languages (HOPL I) is notable in that the two represent opposite poles in several measurement scales that could be proposed for languages. Within the simulation community in the United States (US), GPSS was viewed as easy to learn, user friendly (with the symbolic interface), highly used, limited (in model size and complexity), inflexible (especially so prior to the introduction of the HELP block), and expensive to run (the interpretive implementation). On the contrary, SIMULA was considered difficult to learn (lack of ALGOL knowledge in the US), lacking in its human interface (with input/output being an implementation decision following ALGOL 60), little used (in the US), but conceptually innovative and broadly applicable. The discovery of SIMULA by the programming 376
CHAPTER Vlll
PAPER:A HISTORYOF DISCRETE EVENTSIMULATIONPROGRAMMINGLANGUAGES
language research community in the 1970s was probably the influencing factor in its selection for HOPL I rather than the regard held for the language by simulation practitioners (notwithstanding its excellent reputation among a small cadre of simulation researchers in the US and a larger group in Europe). Originating as an idea in the spring of 1961, SIMULA I represented the work primarily of Ole-Johan Dahl and Kristen Nygaard. The language was developed for the Univac 1107 as an extension of Univac's ALGOL 60 compiler. Nygaard and Dahl [1981 ] described the development of the language during this period as progressing through four main stages: (l) a discrete event network concept, (2) basing of the language on Algol 60, (3) modification and extensions of the Univac ALGOL 60 compiler, and the introduction of the "process concept," and (4) the implementation of the SIMULA I compiler. The technical contributions of SIMULA are impressive, almost awesome. Dahl and Nygaard, in their attempt to create a language where objects in the real world could be accurately and naturally described, introduced conceptual advances that would be heralded as a paradigmatic shift almost two decades later. Almost lost in the clamor over the implementation of abstract data types, the class concept, inheritance, the coroutine concept, and quasi-parallel execution were the solution of significant problems in the extension of ALGOL 60. The creation, deletion, and set manipulation operations on objects are but one example. A second is that the sharing of attribute values by interacting processes required a means for breaking down the scoping restrictions of ALGOL 60. During the luncheon with language presenters at HOPL I in 1978, Nygaard remarked that only those who had programmed simulations really understood the power of the language (see [Wexelblat 1981, p. 485]). 8.3.3
SIMSCRIPT
SIMSCRIPT, in its original form was an event scheduling SPL. Two ancestors contributing to SIMSCRIPT are identified in the Preface to Markowitz [1963]: GEMS (General Electric Manufactaring Simulator) developed by Markowitz at the General Electric Manufacturing Services and SPS-l developed at RAND. Morton Allen was identified as a major contributor to GEMS, and contributors to SPS-1 included Jack Little of RAND and Richard W. Conway of Cornel l University. 8.3.3.1
Background
The RAND Corporation developed SIMSCRIPT under the auspices of the U.S. Air Force. The IBM 709n090 computer was the target machine, and copies of S1MSCRIPT were distributed through SHARE (the IBM user's group). Harry Markowitz, whose broad contributions in several areas were to earn him a Nobel Prize, is generally attributed with the major design, and Bernard Hausner was the sole programmer, actually for both SPS- 1 and the SIMSCRIPT translators. Herbert Karr authored the SIMSCRIPT manual [Markowitz 1963, p. iii]. SIMSCRIPT was considered a general programming system that could treat nonsimulation problems, but the major purpose of the language was to reduce the model and program development times that were common in large efforts. Users were intended to be noncomputing experts, and the descriptive medium for model development was a set of forms: (1) a SIMSCRIPT definition form in which variables, sets, and functions are declared, (2) an initialization form to define the initial system state, and (3) a report generation layout, for prescribing the format and content of simulation output. Accompanying the forms in the model definition is a routine for each endogenous and exogenous event and for any other decisions that prescribe the model logic. The applications context was machine or job shop scheduling and the initial examples reflect this focus.
DISCRETE EVENT SIMULATIONLANGUAGESESSION
377
RICHARD E. NANCE 8.3.3.2
Rationalefor Language Content
Influencing Factors The first version of SIMSCRIPT provided a set of commands that included FORTRAN statements as a subset. The syntax of the language and program organization were influenced considerably by FORTRAN. Basically, the language was transformed by a preprocessor into FORTRAN before compilation into the executable object program version. Insertion of a SIMULATION or NON-SIMULATION card in the compile deck differentiated between the intended uses, permitting omission of the events list and timing routines for nonsimulation purposes. A control routine designated as MAIN replaced the timing routine. SIMSCRIPT 1.5, a version proprietary to CACI [Karr 1965], is described by Markowitz [1979, pp, 27-28] as a "slightly cleaner version of SIMSCRIPT I" that did not appear much different externally. However, the SIMSCRIPT 1.5 translator did not generate FORTRAN statements but produced assembly language. SIMSCRIPT 1.5 is also described as germinating many of the ideas that later appeared in SIMSCRIPT II. Language Design and Definition SIMSCRIPT I (and SIMSCRIPT 1.5) describe the world in terms of entities, attributes, and sets. Entities can be either permanent (available throughout the simulation duration) or temporary (created and destroyed during the simulation). Attributes define the properties of entities, and are distinguished by their values. Sets provide a convenience to the modeler for description of a class of entities (permanent entities), and set ownership and membership are defined relationships among entities. The model structure is described in terms of a listing of events to prescribe the dynamic relationships, coupled with the entity and attribute definitions that provide a static description. Figure 8.3 taken from Markowitz [1963, p. 21] shows the declaration of exogenous and endogenous events for a job shop model. Figure 8.4 shows one exogenous input-an event with the name ORDRIN, also taken from Markowitz [ 1963, p. 22]. The event declarations create event notices that enable the timing executive to manipulate the events list, advancing time to the next imminent event. System-defined variables and functions such as TIME, RANDM, and PAGE are accessible by the modeler. Nontechnical Influences Shortly after SIMSCRIPT I appeared, Karr left RAND to form Consolidated Analysis Centers, Incorporated (CACI). CACI was the major force behind SIMSCRIPT 1.5, and implementations were done by Claude M. Delfosse, Glen Johnson, and Henry Kleine (see the Preface to [CACi 1983]). Referring to the language requirements described in section 8.1, Figure 8.5 gives examples of each of the six language requirements. The terminology used in the middle column of Figure 8.5 follows that of the first version of SIMSCRIPT. Upper case in the examples shows the required syntax. 8.3.4
CSL
Control and Simulation Language (CSL) was a joint venture of Esso Petroleum Company, Ltd. and IBM United Kingdom, Ltd. The purpose of the language was to aid in the solution of complex logical and decision making problems in the control of industrial and commercial undertakings [Esso 1963].
8.3.4.1 Background [Buxton 1962] describes the simulation capabilities of CSL as based on the General Simulation
Program [Tocher 1960] and Montecode [Kelly 1962]. The language is described as experimental in
'378
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES FIGURE 8.3 Events List for Example--Job Shop Simulation in SIMSCRIPT. STATEMENT NUMBER 1
STATEMENT 5
2
6
7 EVENTS
72
3 EXOGENOUS ORDRIN (1) ANALYZ (2) ENDSIM (3) 1 ENDOGENOUS EPROC
END
FIGURE 8.4 Exogenous Event Routine Describing the Receipt of an Order. STATEMENT NUMBER 1
2
STATEMENT
5
6
10
7 EXOGENOUS EVENT ORDRIN SAVE EVENT CARD CREATE ORDER LET DATE(ORDER) = TIME READ N FORMAT (14) DO TO I0, FOR I = (l) (N) CREATE DESTN READ MGDST(DESTN), PTIME(DESTN ) FORMAT (14, H3.2) FILE DES'IN IN ROUT(ORDER) LOOP CALL ARRVL(ORDER) RETURN END
DISCRETE EVENT SIMULATION LANGUAGE SESSION
72
379
RICHARD E. NANCE FIGURE 8.5 The SIMSCRIPTCapabilitiesfor Meeting the Six Requirements.
LanguageRequirement
Basis for Provision
Examples
RandomNumberGeneration
RANDI(IJ)
List ProcessingCapability
Automaticallygeneratedfunctions IntegersuniformlydistributedfromI to J Restart randomnumberstream(oddinteger) Uniformvariatesfrom0.0 to 1.0 Automaticallygeneratedfunctions Tablelook-upwithstep functions(discrete) and linearinterpolation(continuous) EntityOperations
StatisticalAnalysis
ControlConstructs MiscellaneousCommands
ProcessTransformers
ReportGeneration TimingExecutive
Formproducedreportswith specificationof lines, textheadings,spacing,etc. Events SchedulingwithEventsList and EventNotices
RANDR(17319) RANDM
CREATEtemporaryentity DESTROYtemporaryentity FOR EACHOF set ACCUMULATE COMPUTE
EX06EVENTARRVL
nature with an intentional provision of redundancy. This experimental approach also influenced the design of the compiler, emphasizing modifiability over other factors such as reliability. Buxton and Laski [1962, p. 198] attribute contributions to CSL from Tocher and his colleagues at United Steel Companies, Ltd., D.E Hartley of Cambridge University, and I.J. Cromar of IBM, who had major responsibility in writing the compiler. They also acknowledge becoming aware of SIMSCRIPT only on the completion of the CSL definition. No estimates are given for the language design effort, but the compiler is estimated to have required about nine man-months. The object program produced is described as "fairly efficient," both in terms of storage and execution time [Buxton 1962, p. 198]. A second version of CSL, described by Buxton [1966] and labeled C.S.L. 2 by Clementson [I 966], attributed to P. Blunden, P. Grant, and G. Parncutt of IBM UK the major credit for the compiler design that resulted in the product described by [IBM UK 1965]. This version, developed for the IBM 7094, provided extensive dynamic checking to aid program verification and offered some capability for parameter redefinition without forcing recompilation [Buxton 1966, p. 140]. 8.3.4.2
Rationalefor Language Content
Influencing Factors
The following factors appear to have influenced CSL:
I. the intended use for decision making beyond simulation models prompted the adoption of a predicate calculus approach [Buxton 1962, p. 194], .
the reliability on FORTRAN for intermediate translation, and
3. the dependence on techniques advanced by Tocher in GSP promoting the focus on activity as the basic descriptive unit.
380
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
The terminology of CSL resembles that of SIMSCRIPT in that entities, attributes, and sets are primary static model descriptors. The T-cells of CSL provide the basis for dynamic description, that is, representation o f time associated with the initiation and completion o f activities. L a n g u a g e Design and Definition To the F O R T R A N arithmetic and matrix manipulation capability, the developers o f CSL added set manipulation operations, statistical utilities, and some logical operations to support the predicate calculus requirements intended for activity tests. The term ACTIVITIES both signals the use o f CSL for simulation purposes (adding o f timing requirements) as well as marking the beginning of activity description. With reference to the six language requirements for discrete event simulation, CSL provided all, but some in limited form as shown in Figure 8.6. The CSL manual contains no explicit identification o f the random number generation technique although a linear congruential method is implied by the requirement o f an odd integer initialization. Only the normal and negative exponential transformation techniques were supplied in addition to a user defined specification for table look-up. Class definition o f entities gave a major descriptive advantage over programming in the host language (FORTRAN II or FAP). The class definition example in Figure 8.6 shows a driver class with two attributes where entities belong to one o f two sets, either local or long distance (LD). The use of TIME prescribes a T-cell associated with each driver. Set manipulation is illustrated in the F I N D statement which shows that a customer entity has two attributes and the search is intended to find the first in the queue that FIGURE 8.6 The CSL Capabilities for Meeting the Six Requirements. Language Requirement Random Numher
Generator Process Transformers
List Processing Capability
Statistical
Report Generation Timing Executive
Basis for Provision AutomaticallyGenerated Function Rectangular: variable = RANDOM (stream,range) (Type of generator not specified) AutomaticallyGenerated Functions Normal: variable = DEVATE(stream,stddev,mean) Negative Exponential:variable = NEGEXP (stream,mean) User Defined: variable = SAMPLE (cell name, dist,name,stream) Class definition of objects having the same attributes that can be referenced as a set or sets with the use of TIME assigning a clock (T.cell)to each entity. Additions to (GAINS) and deletions from (LOSES) set, and searching based on FIRST,LAST, MAX (expression),MIN (expression),ANY Provides only a HIST statement for accumulatingdata during program execution.FORTRAN 11or FAP subroutines can be called FORTRAN iaput/outpat and formatting Conditions specified which are tested. Time cells provide the link between time and state. Based primarily on GSP [Tocher 1960]
DISCRETE EVENT SIMULATION LANGUAGE SESSION
Examples TM1=RANDOM(STREAMB,2)
SERV.T = DEVIATE(STRMC,3,30) X = NEGEXP(BASE,MEAN(2)) T.MACH.K = SAMPLE(l, POISSON, STRM) CLASS TIME DRIVER.10(2) SET LOCAL,LD FIND CUST QUEUE FIRST & 120
WAITCUST(1) GE 10 WAIT.CUST(2)GE 35
381
RICHARD E. NANCE FIGURE g.7 Problem Statement and Example of CSL Code [Buxton 1962, p. 199]. Initial statements in the program mad in a two-dimensional data array of mileages between all airports in a given part of the world, and establish three sets that hold subgroups of airports. The first of these, AIRPORTS, holds the names of those airports betw~n which possible transfer routings involving one change of aeroplane are required. The second set, TRANSFERPORTS, holds the names of the major airports where transfer facilities are possible. The third set, USED, is used during the program as a working-space set. A transfer muting is permissible provided that the total mileage flown does not exceed the direct mileage by more than 15%. The following program establishes valid transfer routings. The initial statements arc omitted and the output statements are stylized to avoid the introduction of detail which has not been fully described in the paper. The transfer airports for each airport pair are written out in the order of increasing total mileage.
1
2
FOR A AIRPORTS FOR B AIRPORTS ALTB& 2 W R I T E A, B ZERO USED FIND X TRANSFERPORTS MIN (MILEAGE (A, X ) + M I L E A G E & 2 XNEA XNEB i00" (MILEAGE(A, X ) + M I L E A G E LE 1 1 5 * M I L E A G E (A, B) AIRPORT.X NOTIN USED WRITE X AIRPORT. X HEAD USED GO T O 1 DUMMY EXIT
(X, B) )
(X, B))
has attribute 1 value greater than or equal to 10 and attribute 2 value greater than or equal to 35. Basically, conditions were tested to determine if an activity could initiate; the termination was usually prescribed through the assignment of T-cell value. The timing executive was very similar to that used by Tother in GSP [Buxton 1962, p. 197]. Activities had a test and an action section. The test could be prescribed in rather complex logical statements comprising a chain. An evaluation of the chain would lead to the proper actions within the activity specification. Translation was accomplished in four phases. An intermediate phase produced a FORTRAN II program as output on an IBM 1401 (serving as input tape creator for an IBM 7090). Despite the multiphase translation with repetitive passes, the authors felt the process to be efficient, easy to modify, and easy to extend [Buxton 1962, p. 198]. A ratio of CSL to FORTRAN statements is "of the order of one to five." The authors also claim that an equivalent CSL program can be written in approximately 20 percent of the time required for a FORTRAN program. The problem statement and example of CSL code shown in Figure 8.7 are taken from Buxton [1962, p. 199]. Nontechnical Influences CSL continued the GSP organization of a model through activities. It also continued the use of activity scan but provided a simpler two-phase as opposed to a three-phase 382
CHAPTER VIII
PAPER:A HISTORYOF DISCRETE EVENTSIMULATIONPROGRAMMINGLANGUAGES
executive, probably because the application domain stressed contingent (state conditioned) events more than determined (time dependent) events. Following both precedents kept CSL in the mainstream of British simulation efforts, and it soon became a favorite for program generation techniques based on the entity-cycle or activity cycle diagrams, the successors to the wheel charts. Examples of these early graphical modeling aids are shown in Figure 8.8. 8.3.5
GASP
GASP (General Activity Simulation Program) was developed by Philip J. Kiviat at the Applied Research Laboratory of the United States Steel Corporation. Kiviat came to U.S. Steel in June of 1961 and began work on the steel mill simulation project shortly thereafter [Kiviat 1991 a].
8.3.5.1 Background The initial draft of GASP and a large part of the coding occurred during 1961, originally in ALGOL. Early on (presumably in 1961) the decision was made to base the GASP simulator on FORTRAN II. By February 1962, the design of the language was completed sufficiently so that Kiviat received approval for a seminar presentation entitled, "A Simulation Approach to the Analysis of a Complex Large Scale Industrial System," in the Department of Industrial and Engineering Administration at Cornell University. The invitation was extended by Professors Richard W. Conway and William L. Maxwell, both significant contributors to simulation conceptual development. Developed for internal use within United States Steel, GASP was intended to run on several machines, for example, the IBM 1410, IBM 1620, Control Data 1604, and Bendix G-20. A preliminary version of the Programmer's Manual, dated January 16, 1963, also showed intended execution on the IBM 7070 and 7090 with erasures of pencil inclusions of the IBM 7074 and 7094. Editorial markings by Kiviat noted that an update of the target machines would be necessary at final typing [Kiviat 1963a]. A report during the same time period [Kiviat 1963c] clearly casts GASP as the key ingredient in a method for utilizing computer simulation in the analysis of steel industry operations. The intended report was to educate potential users as to the benefits derived from simulation studies and to serve as an introduction to the use of the technique with a GASP "simulation-programming system that greatly reduces the time required for problem analysis, computer programming, and computer use" [Kiviat 1963c, Abstract]. 8.3.5.2
Rationalefor Language Content
Exposed to the subject in his graduate study at Cornell, Kiviat was both knowledgeable in simulation techniques and aware of other language developments. The completed version of the report describing GASP [Kiviat 1963b] (a revision of the earlier titled "Programmers' Manual") contained references to SIMSCRIPT, Tocher's GSP, SIMPAC, and industrial dynamics [Forrester 1961]. An incomplete reference contains the name "Gordon, Geoffery [sic]," but nothing more.
Influencing Factors GASP was designed to "bridge the gap" between two groups: operating or engineering personnel, unfamiliar with computer programming, and computer programmers unknowledgeable of the application domain. Like GPSS, flow-chart symbols were intended to be used by the operational personnel in defining the system. The symbols followed the conventions for general purpose use. An example, taken from [Kiviat 1963a], is shown in Figure 8.9. The sketch of language capabilities, provided in Figure 8. I 0, is supplemented by the following explanation.
DISCRETE EVENT SIMULATIONLANGUAGESESSION
383
RICHARD E. NANCE FIGIJRE 8.8 Wheel Chart and Activity Cycle Diagrams.
N
N ~ ~ NNN~
• f ~C4[ ~ ~ _ ~
y three [ n ~ ' ~ s (C2, C3, C4), each [ requiting it to unload parts. [ A state of C4 can also cause [ a state to occur for C2. [
(a) The Wheel Chart Example (from [Tocher 1966, p. 129])
P '
A machine requires a setup operator to prepare it for production (Running). A 3minute setup time is followeedby an idle period for the operator until the next setup. The machine runs for 10 minutes and stops to await setup for the next run.
(b) The Activity Cycle Example (from [ECSL-CAPS Reference Manual 1978, p. 9])
384
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
FIGURE 8.9 The How-ChartRepresentationof an Event(F.JOBIN)in GASP.
No
Yes
put the machine
in the busy state
SChedule the'~N~ achine to finish
essing this
~/
Random sample from Normal dist.
indicate that a job has been lost
put this job in queue behind machine. record time and number in queue
Collect output information
A GASP model was made up of elements--people, machines, orders--with elements described in terms of attributes. A list of attributes describing an element corresponded to the later concept of a record. Changes in the value of attributes occur through activities, which could either be instantaneous or require a time duration. Event routines were described by the user or the operating personnel, through flow charts subsequently translated into executable representations by programmers. Subroutines written in FORTRAN II provided the list processing capabilities (queue insertion, item removal, etc.) relying on the array data structure completely. Reporting was centralized in a single subroutine (OUTPUT) to which transfers were made, depending on the data being collected. The FORTRAN II resident library provided the random number generator, and GASP utilized transformations for the generation of variates following the uniform, Poisson, normal, and Erlang distributions. In addition, sampling could produce a value from an empirical distribution (based on sample data). A rather unique feature of GASP was the provision of a regression equation from which sampling could be used primarily to produce input values. The number of arguments for the regression equation was limited to 10 or less, and the error term was expected to follow a normal distribution. Timing was the responsibility of the GASP EXECUTIVE, which utilized the data supplied by the modeler's use of scheduling (SCHED) calls to sequence events properly. Debugging was also a major
DISCRETE EVENT SIMULATION LANGUAGE SESSION
385
RICHARD E. NANCE
concern, and features were provided in a special subroutine (MONITR) that assisted in this effort. A routine for error determination reported 13 types of errors. Nontechnical Influences A revision to GASP, labeled GASP II, was underway in early 1963. No doubt, further developments were hindered by the departure of Kiviat who took a position at the RAND Corporation. A later version of the GASP User's Manual, which is believed to be in the 1965 time frame, was authored by Jack Belkin and M.R. Rao [Belkin 1965?]. 8.3.60PS-3
OPS-3 is classed as a major SPL, not because of conceptual influences but because it was an innovative and technical effort considerably ahead of its time. Growing out of classroom instruction at MIT during the spring, 1964, OPS-3 was a prototyping effort building on two earlier versions, each the result of classroom experiments. The MIT time sharing system, CTSS, stimulated the experiments in interactive model building and simulation programming. 8.3.6.1
Background
The major contributors to OPS-3 were Martin Greenberger, Malcolm M. Jones, James H. Morris, Jr., and David N. Ness. However, a number of others are cited in the preface of Greenberger [ 1965]: M. Wantman, G.A. Gorry, S. Whitelaw, and J. Miller. The implication is that all in this second group were students in the Alfred P. Sloan School of Management. The OPS-3 system was intended to be a multi-purpose, open-ended, modular, compatible support for creative researchers. The users were not intended to be computing experts, but persons involved in problem solving and research that necessitated model building. Additions to OPS-3 could be from a variety of programming languages or represent a synthesis of subprograms without modification [Greenberger 1965, pp. 1-2]. 8.3.6.2
Rationalefor Language Content
OPS-3 was intended to be a general programming tool with extended capabilities for handling modeling and simulation to support research users. As pointed out before, OPS-3 was viewed as a system and not simply a language.
Influencing Factors The major influence on OPS-3 was the interactive; time-sharing environment provided by CTSS. For the first time simulation modeling was to be done in a quasi-real-time mode, but not necessarily with interactive assistance beyond that provided by CTSS. The AGENDA, provided as a compound operation (KOP), enabled the scheduling, cancellation, and rescheduling activities following the "spirit of simulation languages such as SOL and SIMSCRIPT," [Greenberger 1965, p. 7]. The power of interactive model execution was recognized as something totally new. Language Design and Definition OPS-3 is structured in a hierarchical fashion with a basic calculation capability furnishing the lowest level of support. The system provides five modes or user states: Execute, Store, Store and Execute, Run, and Guide. Simple operators such as PRINT are available in execute mode. Cascading a series of operations into a program is enabled with store mode. If single operators are to execute within a program then store and execute mode was used. Run mode enabled execution of compound operations (KOPs) without interruption. The assistance or help was accessible in guide mode. In the terminology typical of the time, OPS-3 would be categorized as emphasizing CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
FIGURE 8.10 The GASP Capabilities for Meeting the Six Requirements. Language Requirement
Basis for Provision
Examples
FORTRAN II resident library,NRANDM(d) with d = 1,2, 3, or4 gives an integer [1,10 d]
JDGT = NRANDM(I)- i
Number
Generation Process Transformers
Uniform, Poisson, Normal, and Erlang distributions. An empirical distributionalso could be defined.
NUM = NPOISN (3) (where 3 specifics the " row of the input parameter list which contains the actual parameter value) CALL FILEM (TMDUE,JDDLR, KMATL,QUEUE,1) CALL FETCHM (FLOATF(JDOLR), XINTF(TMDUE),KMATL,QUEUE,1) (Note: first argument is the basis for insertion and removal)
Random
List Processing Capability
Subroutines provided the capability for filing (FILEM) and retrieving (FETCHM)elements using FIFO or LIFO disciplines in a FORTRANarray.
Statistical
Subroutines COLECT: the sum, sum of squares, extreme values, and sample size for up to 20 designated variables HISTOG: formsa histogram for each up to 20 designated variables The OUTPUT subroutinemust he written by the user but the statistical subroutines above and PRINTQ provide the functionality.
Report Generation Timing Executive
Event scheduling with a schedulingsubroutineand using an associated list organizationdevelopedby Kiviat [1962a, 1962b]
CALL SCHDL(ARVTM,JARVL,KCUST)
operators rather than data structures. An operator took the form o f a closed subroutine written in M A D (Michigan Algorithmic Decoder), FORTRAN, FAP (an assembler), or any other source language available under CTSS. Over 90 operators were provided in the language, and 75 subroutines were provided in the library. In terms o f the six language requirements for simulation, Figure 8.11 shows the capabilities provided by OPS-3. Especially impressive were the statistical capabilities for input data modeling and output analysis through an operator set that provided linear least-squares fit, intercorrelation and partial correlation, tests of homogeneity, contingency table analysis, and others. A guided form o f each test ushered the novice user through the requirements for performing the test. A short form was available for the experienced user. The determination of the next activity is based on a three-phase method resembling that used in Tocher's GSP [Tocher 1960]. The contingent event is placed on the A G E N D A in an order dictated by TIME, the system clock, in the sequence o f conditional events. Parameters can be passed with the SCHED operator, and the A G E N D A can be accessed by the user as a debugging aid.
Nontechnical Influences This period in M I T computing was certainly one of the most exciting. Time sharing and interactive computation were in their infancies. Innovative thinkers such as J.C.R. Licklider, John McCarthy, and R.M. Fano were pushing the boundaries of computing technology to
DISCRETE EVENT SIMULATION LANGUAGE SESSION
387
RICHARD E. NANCE
FIGURE 8.11 The OPS-3 Capabilities for Meeting the Six Requirements. Language Requirement
Basis for Provision
Examples
Random Number Generation
Defined function, presumably a linear congruenfial method. DRAW arguments: returned val, distribution, parml, parm2 Initialization possible with SEED odd integer
DRAW PRIORITY RANDOM 1 7
Process Transformers
The second argument of DRAW specified the distribution: exponential, normal, or modeler specified. Default parameters of 0 (mean) and 1 (std. dev.) for normal.
DRAW SERVTM EXPONE THETA DRAW MEMRY DEMAND CLASS
List Processing Capability
Major control through user-accessible symbol table. Major data structure is array but with more flexible manipulation than with FORTRAN. Stack operators permit entry, removal, and examination of values.
RESETQ WLINE Empties the queue WLINE GETOLD REDYQ PROCQ Places oldest item in REDYQ into PROCQ
Statistical
Extensive statistical operators with capability for input data modeling and output analysis
CNTING X 2-way contingency table with X a floating-point matrix.
SEED 6193
TTESTS X NI N2 A t-test between two samples of size N1 and N2 with the values in the matrix X Report Generation
Nothing beyond the usual interactive input and output
Timing Executive
A three-phase method built around the KOP AGENDA. SCHED activity option basis CANCEL option activity variable
SCHED SRVCE AT 100 SCHED ENDSV NOW CANCEL FIRST ARRVL AT1ME
the utmost. Consider the insightful perspective of Licklider concerning the future role of languages for dynamic interactive modeling [Licklider 1967, p. 288-289]. In their static form, computer-program models are documents. They preserve and carry information just as documents printed in natural language do, and they can be read and understood by recipients who know the modeling language. In their dynamic form, however, computer-program models appeal to the recipient's understanding directly through his perception of dynamic behavior. That model of appeal is beyond the reach of ordinary documents. When we have learned how to take good advantage of it, it may--indeed, I believe it will--be the greatest boon to scientific and technical communication, and to the teaching and learning of science and technology, since the invention of writing on a fiat surface.
Within less than two years of publication, the DEC PDP-10 would supply even more advanced facilities than afforded to the developers of OPS-3. The efforts of Greenberger, Jones, and others with OPS-3 deserve recognition for the perceptions and demonstration of technology potential rather than the effect on SPL developments.
388
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES 8.3.7
DYNAMO
The DYNAMO (DYNAmic MOdels) language served as the executable representation for the industrial dynamics systems models developed by Jay Wright Forrester and others at MIT during the late 1950s and into the 1960s and beyond. DYNAMO is the lone nondiscrete event simulation language included in this history. Justification for this departure is that concept, techniques, and approaches utilized by the MIT group had a significant impact on those working in the development of discrete event SPLs [Kiviat 1991 b].
8.3.7.1 Background The predecessor of DYNAMO, a program called SIMPLE (Simulation of Industrial Management Problems with Lots of Equations), was developed by Richard K. Bennett for the IBM 704 computer in the spring of 1958. (Note that this is a contemporary of GSP in the discrete-event SPL domain.) SIMPLE possessed most of the basic features of DYNAMO, but the model specifications from which the program was derived were considered to be rather primitive [Pugh 1963, p.2]. DYNAMO is attributed to Dr. Phyllis Fox and Alexander L. Pugh, III with assistance from Grace Duren and David J. Howard. Modifications and improvement of the original SIMPLE graphical plots was provided by Edward B. Roberts [Forrester 1961, p.369]. Originally written for an IBM 704 computer, the DYNAMO compiler, consisting of about 10,000 instructions, was converted to an IBM 709 and then an IBM 7090 by Pugh. The DYNAMO compiler as described in the User's Manual represented about six staff-years of effort (including that required to develop SIMPLE), and the maximum model size was about 1500 equations. A FORTRAN simulator (FORDYN), intended for users who did not have access to the large IBM 7090 or 7094, was developed by Robert W. Llewellyn of North Carolina State University in 1965 [Llewellyn 1965]. (Note that neither DYNAMO nor FORDYN are included in Figure 8.1.) 8.3.7.2
Rationalefor Language Content
Although applicable to the modeling of any information feedback system, DYNAMO was developed as the means of implementing industrial dynamics models, which addressed the application of simulation to large scale economic and social systems. The level of modeling granularity does not address the individual items or events typically associated with the job shop models of that time. A thorough understanding of the basis for systems dynamics modeling, the term later employed, is beyond the scope of this paper (see [Forrester 1961]).
Influencing Factors The design of DYNAMO was strongly influenced by the following desirable properties [Pugh 1963, p.2]: 1. The language should be easily understood and easy to learn by the user group, who in general might not be professional programmers. Flexibility would be sacrificed for both ease of use and correctness. 2. A very efficient (at the time) compilation phase, with no object language production, eliminated the usual practice at the time of saving object text. 3. Output in the form of graphical plots was recognized as more useful than extensive numerical results; however, both were provided to the user.
DISCRETE EVENT SIMULATION LANGUAGE SESSION
389
RICHARD E. NANCE
. Error detection and error correction were considered a primary responsibility. Both initial conditions and the order of computation were subject to detection and correction. The claim was that DYNAMO checked for almost every logical inconsistency, and provided comments on errors that were easily understood. Language Design and Definition DYNAMO is described as a language expressing zero- and first-order difference equations. A system is described in terms of flows and accumulations. Flows in orders, material, personnel, money, capital equipment, and most importantly information, affect the decision making that leads to changes in the rate of flow occurring in subsequent time periods. Over time the changes in flow contribute to the redefinition of levels (of money, materials, information) that have subsequent influence on future rates of flow. Each model must begin with an initial state definition, and the constant increment of time (DT) is selected to be sufficiently small to avoid inherent instability. Figure 8.12 portrays the timing sequence for each set of DYNAMO computations. The present time (K), has values determined based on levels of accumulation at J modified by rates of flow over the JK interval. Levels at present time (K) then contribute to the definition of rates over the interval KL, where L = K + DT. Figure 8.13 is an example taken from [Pugh 1963, p.17] showing the model of a retail store that illustrates the DYNAMO representation. The equational representation in Figure 8.13 is understood by noting that the number of each equation is suffixed by the type of equation: L for level; A for auxiliary; R for rate; N for initial value. NOTE is a comment statement, and special statements such as PRINT, PLOT, and SPEC provide instructions on the execution process. The subscripting enables not only a determination of direct statement formulation, but also of statement ordering and typing. Although discontinuities were permitted in systems dynamics, and could be represented in DYNAMO, they were discouraged unless absolutely necessary as a modeling technique. The graphical output produced on a lineprinter consisted of letters showing the relative values for designated variables. The use of plotters with smoothed curvilinear, coded representations is provided in the book by Forrester, but was not available with the early version of DYNAMO. The fixed format field definition required by the translator was to be replaced in later versions. FIGURE 8.12 Time Notation(from[Pugh 1963,p.4].
JK interval
rl ~
I
KL interval
-~
TIME K (Present TIME)
390
L
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES FIGURE
8.13
Listing of model.
RUN NOTE NOTE iL IL 20A 20A 54R 40R 12A 3L 39R NOTE NOTE NOTE 12N 6N 6N NOTE NOTE NOTE 7R 45A NOTE NOTE NOTE C C C C C C C NOTE PRINT PLOT S PEC
M478-248,DYN,TEST,i,i,0,0 2698JP M O D E L OF RETAIL STORE IAR.K=IAR.J+(DT) (SRR.JK-SSR.JK) UOR.K=UOR.J+(DT) (RRR.JK-SSR.JK) NIR.K=IAR.K/DT STR.K=UOR.K/DFR SSR.KL=MIN(STR.K,NIR.K) PSR.KL=RRR.JK+(i/DIR) (IDR.K-IAR.K) IDR.K=(AIR) (RSR.K) RSR.K=RSR.J+(DT) (i/DRR) (RRR.JK-RSR.J) SSR.KL=DELAY3(PSR.JK,DTR)
INVENTORY ACTUAL UNFILLED ORDERS NEGATIVE INVENTORY SHIPMENTS TRIED S H I P M E N T S SENT P U R C H A S E O R D E R S SENT INVENTORY DESIRED REQUISITIONS SMOOTHED SHIPMENTS RECEIVED
INITIAL C O N D I T I O N S UOR=(DFR) RSR=RRR IAR=IDR
(RRR)
INPUT RRR.KL=RRI+RCR.K RCR.K=STEP(STH, 5)
REQUISITIONS RECEIVED REQUISITION CHANGE
CONSTANTS AIR=8 WKS DFR=i W K DIR=4 WKS DRR=8 WKS DTR=2 WKS RRI=i000 ITEMS/WK STH=i00 I T E M S / W K
C O N S T A N T FOR I N V E N T O R Y DELAY IN F I L L I N G O R D E R S DLY R E F I L L I N G I N V E N T O R Y REQUISITION SMTHNG T C D E L A Y IN T R A N S I T REQ. R E C E I V E D I N I T I A L L Y STEP H E I G H T
i)IAR, I D R / 2 ) U O R / 3 ) R R R , S S R / 4 ) P S R , S R R IAR=I,UOR=U/RRR=R, S S R = S , P S R = P , S R R = Q DT=0.1/LENGTH=i0/PRTPER=5/PLTPER=0
Nontechnical Influences Systems dynamics and DYNAMO, although developed totally at MIT, attracted considerable nationwide interest. Financial support from the Ford Foundation and the SIoan Research Fund are acknowledged in the Preface of Forrester [ 1961 ]. Additional support from a number of sources is identified there also. Since DYNAMO was not a discrete event SPL, and because its influence was limited to the developmental period, successive versions of the language are not described. However, the language continued, both in refined versions [Pugh 1973] and extensions [Pugh 1976]. DISCRETE EVENT SIMULATION LANGUAGE SESSION
391
RICHARDE. NANCE 8.3.8 Other Languages Numerous SPLs emerged during this advent period. Most, experienced some use and disappeared. A few had distinctive characteristics that deserve some note in a paper of this type. MILITRAN was produced by the Systems Research Group for the Office of Naval Research [Systems Research Group, Inc. 1964]. Krasnow [1967, p. 87] states that little concession to military subject matter was given in MILITRAN. Event scheduling was the world view promoted, and a distinction between permanent (synchronous) and contingent events was made. The Cornell List Processor (CLP) was a list processing language used extensively for simulation instruction. The developers had the goal of producing a list processing language that required no more than a "FORTRAN level" knowledge of programming [Conway 1965]. CLP relying on CORC, a general algebraic language used at Cornell also for instructional purposes, enabled students to define entities, and use them in set manipulation (INSERT, REMOVE) without the major effort of learning a language such as SIMSCRIPT [Conway 1965, p. 216]. The student still had to write his or her own timing, statistical analysis, and report generation routines. QUIKSCRIPT was a SIMSCRIPT derivative simulator, a set of subroutines, based on the 20-GATE algebraic language used at Carnegie Institute of Technology [Tonge 1965]. The GATE subroutines did not provide all the facilities of SIMSCRIPT (e.g., no report generation), and the definitional forms of the latter were omitted. SIMPAC, produced at the System Development Corporation, was distinguished by its fixed-timeincrement timing routine. This would appear to make it the only US language to adhere completely to the activity scan world view [Bennett 1962]. (OPS-4 departed from OPS-3 by accommodating all three world views.) SOL (Simulation Oriented Language) was developed by Knuth and McNeley as an extension to ALGOL. The language is structured much like GPSS, even using terms such as SEIZE, RELEASE, and ENTER. Sets are represented as subscripted variables. In contrast with SIMULA, SOL focused on the dynamic interaction of temporary objects, again much like GPSS [Knuth 1964a, 1964b]. Of note in SOL was the explicit use of a wait on state condition that was not present in GPSS or in SIMULA, because the prevailing view was that such an indeterminate expression could lead to gross inefficiencies (see [Nygaard 1981, p. 452] for a discussion specific to SIMULA and [Nance 1981] for a more general discussion). A second, more anecdotal, item related to SOL was the response of Knuth when asked at the IFIP Conference what were the plans for SOL; he replied that there were no plans for he found SIMULA to have all the capabilities of SOL (except for the wait on state condition) and more [Knuth 1992].
8.3.9 Language Comparisons The end of the advent period marked the beginning of a period of intense interest in simulation programming language comparison and evaluation. Such interest was manifested in the publication of a number of papers during the 1964-1967 timeframe that reviewed and compared existing languages with respect to many criteria [Young 1963; Krasnow 1964; Tocher 1965; Kiviat 1966; Teichrow 1966; Krasnow 1967; Reitman 1967]. These sources also refer to lesser known languages that are not mentioned here. Interest in comparison and evaluation was likely stimulated by the perceived cost associated with usir~ "another language." The cost of acquiring the translator was minor; the cost of training people, maintaining the language, and supporting its migration to subsequent hardware systems could be very high. For that reason, packages in a general purpose language had considerable appeal.
392
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
This sharp interest in language comparisons is also marked by the number of workshops, symposia, and conferences addressing SPL issues. Daniel Teichrow and John F. Lubin are cited by Philip Kiviat as the"honest brokers" in that they had no commitment to a particular language but were instrumental in developing forums for the exchange of concepts, ideas, and plans. A workshop organized by them and held at the University of Pennsylvania on March 17-18, 1966 refers to an earlier one at Stanford in 1964 [Chrisman 1966]. Session chairs at the 1966 workshop included Kiviat, R. L. Sisson (University of Pennsylvania), Julian Reitman (United Aircraft), and J.E Lubin. Comparison papers were presented by Harold G. Hixson (Air Force Logistics Command), Bernard Backhart (General Services Administration), and George Heidorn (Yale University). Among the 108 attendees were several who were involved in SPL development: W.L. Maxwell of Cornell (CLP), Malcolm M. Jones of MIT (OPS), Howard S. Krasnow and Robert J. Parente of IBM, and Julian Reitman of Norden (GPSS/Norden). In between the two workshops described was the IBM Scientific Computing Symposium on Simulation Models and Gaming held at the T.J. Watson Research Center in Yorktown Heights, New York on December 7-9, ! 964. A session entitled, "Simulation Techniques" included a paper by Geoffrey Gordon that compares GPSS and SIMSCRIPT [Gordon 1966] and a paper by Tocher that presents the wheel chart as a conceptual aid to modeling [Tocher 1966]. In another session, the Programming by Questionnaire (PBQ) technique for model specification is described [Geisler 1966]. (More about PBQ is to follow.) The Symposium took a broad applications view of simulation, and among the 175 attendees at this conference were Jay W. Forrester (MIT), who described the principles of industrial dynamics, Richard M. Cyert (CIT), Herbert A. Simon (CIT), Philip Morse (MIT), J.C.R. Licklider (MIT), Harold Guetzkow (Northwestern), Richard W. Conway and William L. Maxwell (Cornell), Oscar Morgenstern (Princeton), and Guy H. Orcutt (Wisconsin). The most notable technical conference on simulation languages was the IFIP Working Conference on Simulation Programming Languages, chaired by Ole-Johan Dahl and held in Oslo, 22-26 May 1967. The Proceedingswere edited by John N. Buxton and appeared the following year. The list of presenters and attendees reads like a "Who's Who," not only in computer simulation but also in computer science. The "by invitation only" participants, with their role or presentation subject in parentheses, included Martin Greenberger and Malcolm M. Jones (OPS-4), Michael R. Lackner (graphic forms for conversational modeling), Howard S. Krasnow (process view), Donald E. Knuth (Session Chair), Jan V. Garwick (Do we need all these languages?), R.D. Parslow (AS: an Algol language), Ole-Johan Dahl and Kfisten Nygaard (class and subclass declaration), L. Patrone (SPL: a simulation language based on PL/I), John G. Laski (interactive process description and modeling languages), G.K. Hutchison (multiprocessor system modeling), Robert J. Parente (simulation-oriented memory allocation), G. Molner (self-optimizing simulation), G.P. Blunden (implicit interaction), John L. McNeley (compound declarations), C.A.R. Hoare (Session Chair), A.L. Pugh III (DYNAMO II), T.B. Steel, Jr. (standardization), and Evzen Kindler (COSMO). The highly interactive group of participants included: Richard W. Conway, Douglas T. Ross, Christopher Strachey, Robin Hills, and John N. Buxton. Issues and problems surfacing in this symposium on occasion resurface, for example, in the annual Winter Simulation Conferences. In November 1967, Harold Hixson, Arnold Ockene, and Julian Reitman collaborated to produce the Conference on Applications of Simulation Using GPSS held in New York. Hixson, representing SHARE (the IBM User Group), served as General Chair, Ockene of IBM served as Publicity Chair, and Reitman of Norden Systems was the Program Chair. In the following years this conference expanded its programming language scope (beyond GPSS) and became known as the Winter Simulation Conference (WSC), which celebrated its twenty-fifth anniversary in December 1992, in Washington. The three individuals named above, together with other pioneers in the early years of the DISCRETE EVENT SIMULATION LANGUAGE SESSION
393
RICHARD E. NANCE
WSC, were brought together in a panel session entitled "Perspectives of the Founding Fathers" [Wilson 1992].
8.4 THE FORMATIVE PERIOD (1966-1970) Following the bustle of activity surrounding the emergence of new SPLs, the period from 1966-1970 marked a consolidation in conceptual clarification. The concepts, possibly subjugated earlier in the necessities of implementation, were reviewed and refined to promote more consistent representation of a world view and improve clarity in its presentation to users. Nevertheless, rapid hardware advancements and vendor marketing activities forced some languages, notably GPSS, to undergo major revisions.
8.4.1
GPSS
GPSS II and III are included in the advent period as is the ZIP/ZAP compiled version of the language translator. With the introduction of SYSTEM/360 in the 1960s, GPSS/360 represented an improved and extended version of GPSS III that appeared in two versions (see [Schriber 1974, p. 496]). An RCA version of the language, called Flow Simulator, represents a combined version of the two [Greenberg 1972, p. 8]. Flow Simulator appeared in 1967 [Flow Simulator, RCA 1967] [Flow Simulator Information Manual, RCA 1967]. A Honeywell version, GPS K appeared in 1969 [GPS K 1969]. Two versions of a User's Manual for GPSS V appeared in 1970-1971 [GPSS V 1970, 1971]. GPSS/UCC, corresponding closely to GPSS/360, was developed by the University Computing Corporation in the late 1960s. GPSS/360 extended the prior version (GPSS III) by increasing the number of block types from 36 to 44. Set operations were expanded by the introduction of groups. Extensions to the GENERATE block improved storage use. A HELP block permitting access to routines in other languages was provided. Comparisons of the language versions for GPS K, Flow Simulator, and GPSS III with GPSS/360 can be found in the Appendices of Greenberg [1972]. GPSS V provided more convenience features but made no major changes in the language. A run timer could be set by the modeler, extensions were made to the HELP block, and free format coding (removal of statement component restrictions to particular fields) was permitted. A detailed comparison of differences in GPSS/360 and GPSS V is provided in Appendix A of Schriber [1974].
8.4.2
SIMULA 67
The realization of shortcomings in SIMULA I and the influences of language and translator developments during the mid-1960s led to an extensive revision of the language. This revision, described in detail in Nygaard [ 1981 ], is not repeated here. Needless to say, the class concept was a major innovative contribution. Clearly, SIMULA 67 served to crystallize the process concept, the coroutine and quasi-parallel processing capabilities and demonstrate the implementation of abstract data types. The result was a language well beyond the power of most of its contemporaries.
8.4.3
SIMSCRIPT II
SIMSCRIPT II, although dependent on SIMSCRIPT 1.5 for its basic concepts of entity, attribute, and set, was clearly a major advancement over the earlier version. SIMSCRIPT II is intended to be a
394
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
general purpose language whereas SIMSCRIPT 1.5 was intended to be a simulation programming language. SIMSCRIPT II in appearance looks much different from SIMSCRIPT I [Markowitz 1979, p. 28]. An expressed goal of SIMSCRIPT II was to be a self-documenting language. SIMSCRIPT II was written in SIMSCRIPT II, just as its predecessor was written, for the most part, in SIMSCRIPT 1.5. 8.4.3.1
Background
The RAND Corporation provided the organizational support and financial underpinnings for SIMSCRIPT II. Philip J. Kiviat, having come from the United States Steel Company, took over the leading role in the design and development of the language from Harry Markowitz, who had started the project. Markowitz, whose ideas had formed the basis for SIMSCRIPT I and SIMSCRIPT 1.5, was in the process of leaving RAND dunng the major part of the language project. Bernard Hausner, the principal programmer on SIMSCRIPT 1.5, had departed, and Richard Viilanueva assumed this role. Although the claim was made that SIMSCRIPT II was a general purpose language, RAND's principal interest in developing SIMSCRIPT II was to enhance its capability within discrete event simulation and to offer greater appeal to its clients [Kiviat 1968, p. vi]. Many of RAND's models were military and political applications, necessitating extremely large complex descriptions. The intent was to create a language that, through its free-form and natural language appearance, would encourage more interaction with application users. Contributions to the language are acknowledged in the preface to the aforementioned book. George Benedict and Bernard Hausner were recognized as contributing much of the basic compiler design and programming. Joel Urman of IBM influenced the language design as well as programmed much of the I/O and operating system interface routines. Suggestions and criticisms were attributed to a number of persons, including Bob Balzer, John Buxton, John Laski, Howard Krasnow, John McNeley, Kristen Nyggard, and Paula OIdfather [Kiviat 1968, p. vii]. In addition to a free-form, English-like mode of communication, the language designers desired a compiler to be"forgiving," and to correct a large percentage of user syntax errors. Furthermore, forced execution of a program was felt to reduce the number of runs to achieve a correct model implementation. Debugging statements and program control features were central to the translator. 8.4.3.2
Rationalefor Language Content
Influencing Factors
Certainly, SIMSCRIPT 1.5 and the entity, attribute, and set concepts had the major influence on the language design. Nevertheless, the intent to involve application users and to provide a language working within SYSTEM/360 and OS/360, both still somewhat in development, had some impact. At one point, the language designers considered writing SIMSCRIPT II in NPL (the New Programming Language), subsequently PL/I, but the idea was rejected because of the instability ofNPL [Kiviat 1992]. Kiviat [1991b] acknowledges that ideas and information came from interaction with other language developers and designers. The Working Conference on Simulation and Programming Languages, cited above, was a primary source of such ideas [Buxton 1968].
Language Design and Definition
The design of SIMSCRIPT II can be represented by the reverse analogy of"peeling the onion." The language designers refer to "levels of the language," and use that effectively in describing the rather large language represented by SIMSCRIPT II.
DISCRETE EVENT SIMULATION LANGUAGE SESSION
395
RICHARD E. NANCE
Level 1 is a very simple programming language for doing numerical operations. It contains only unsubscfipted variables and the simplest of control structures with only rudimentary input (READ) and output (PRINT) statements. Level 2 adds subscripted variables, subroutines, and extended control structures to offer a language with roughly the capability of FORTRAN 66 but lacking the FORTRAN rigidities. Level 3 adds more general logical expressions with extended control structures, and provides the capability for storage management, function computations, and statistical operations. Level 4 introduces the entity, attribute, set concepts needed for list processing. The pointer structures, implied subscripting, and text handling go well beyond the capabilities of SIMSCRIPT 1.5. Level 5 contains the dynamic capabilities necessary for simulation: time advance, event processing, generation of statistical variates, and output analysis. Nontechnical Influences Markowitz [ 1979] attributes the lack of interest by RAND in developing SIMSCRIPT II as more than a simulation language to dictating the limitation of five levels in the implementation. He identifies Level 6 as that which dealt with database entities, and Level 7 as a language writing "language," used in the implementation of SIMSCRIPT II so that a user could define the syntax of statements and the execution of more complex commands [Markowitz 1979, p. 29]. Kiviat recalls discussion of the extension but that no concrete proposal was ever made [Kiviat 1992]. 8.4.3.3
Variants
SIMSCRIPT 1.5 was developed as a commercial product by Consolidated Analysis Centers, Incorporated (CACI). SIMSCRIPT II became a commercial product in SIMSCRIPT II Plus through Simulation Associates, Incorporated, cofounded by P.J. Kiviat and Arnold Ockene, formerly IBM GPSS Administrator. CACI purchased the rights to SIMSCRIPT II Plus and marketed it as SIMSCRIPT I1.5. Markowitz [1979, p. 29] also describes a SHARE version of the translator. 8.4.4
ECSL
ECSL, or E.C.S.L. as Clementson [1966] preferred, was developed for Courtaulds Ltd. by the originators of CSL [Buxton 1964]. The extensions that distinguish ECSL from its predecessor are likened to those of CSL2 developed by IBM United Kingdom, but the provision of the features took forms quite different on the Honeywell 400 and 200 series machines. A single man-year of effort was required for each of the Honeywell versions (400 and 200) [Clementson 1966, p. 215]. The most striking difference in CSL and ECSL is the departure from FORTRAN taken with the latter. This decision was based on the desire to facilitate use of ECSL by those having no knowledge of any other programming language [Clementson 1966, p. 215]. The approach taken was to adopt a columnar field formatting akin to that used in GPSS. Abandonment of FORTRAN also led to a richer I/O capability. The FORTRAN I/O was felt to be "the major shortcoming of C.S.L., as originally conceived," [Clementson 1966, p. 218]. ECSL became the target language for the Computer Aided Programming System (CAPS), the first interactive program generator, developed by Clementson in 1973 [Mathewson 1975].
396
C H A P T E R VIII
PAPER: A HISTORYOF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
A contrary argument to the separation from FORTRAN was raised almost a decade later in the simulation package EDSIM, which claimed both to emulate ECSL and to be event based [Parkin 1978]. In actuality, EDSIM closely followed the ECSL design as an activity scan language. 8.4.5
GASP II
GASP II appears twice in the genealogical tree in Figure 8.1. A preliminary description of the revised version appears in manual form available from Pritsker at Arizona State University [Pritsker 1967]. Although the published description appears in the book by Pritsker and Kiviat [1969], a listing of FORTRAN subprograms designated as a GASP II compilation on the IBM 7090 is dated "3/13/63." This early revision, the work of Kiviat alone, predates his departure from U.S. Steel by only a few months. An examination of the 1963 and 1967 versions of GASP II reveals both the addition and elimination of routines. The most prominent addition is the routine SET. The use of NSET as the primary data structure improved the organization of the package. A basic and extended version of GASP II are described [Pritsker 1967, pp. 22-23]. A version of GASP II, written in the JOSS interactive language, called JASP was developed by Pritsker during the summer of 1969 at RAND. Pritsker notes that memory limitations of 2000 words forced data packing and overlay techniques developed by Lou Miller of RAND. JASP is the only example of a time-sharing simulation language developed outside of MIT prior to 1970. 8.4.60PS-4
Defined in the Ph.D. thesis of Malcolm M. Jones [1967], the description of OPS-4 is taken here primarily from [Greenberger 1968]. Based on PL/I, OPS-4 encouraged the incremental construction and test of model components. All three world views (event scheduling, activity scan, and process interaction) were supported in the language. Additional routines for the generation of random variates were provided, and the numerous statistical routines of OPS-3 were continued. Extensive debugging and tracing capabilities were available along with immediate on-line diagnostic explanations for error detection. Model execution could be interrupted for examination and redefinition of values. OPS-4 was described as a project in the planning stage. Intended for operation under the MULTICS operating system, OPS-4 raised the issue of the degree to which an SPL might use underlying operating systems support for simultaneous execution and asychronous processing [Greenberger 1968, p. 22, 24]. Ambitious in scope, OPS-4 did not become a commercial language, and little is known about its eventual use. 8.4.7
Other Languages
BOSS (Burroughs Operational Systems Simulator) was initiated in 1967 as the generalization of a gun placement simulator developed by the Defense, Space, and Special Systems Group of the Burroughs Corporation. Principals in the development of BOSS were Albert J. Meyerhoff, the informal group leader, Paul E Roth, the conceptual designer, and Philip E. Sharer, the programmer. Supported at a high level by independent research and development funds, BOSS was viewed as a potential competitor with GPSS. The first prototypes for external use were completed in early 1969. Roth [1992] acknowledges experience with GPSS II as contributing to his design of BOSS, and the
DISCRETE EVENT SIMULATION LANGUAGE SESSION
397
RICHARDE. NANCE FIGURE 8.14 The GERTFamilyTree(from[Pritsker1990,p. 243]).
I GANTT charts, PERT, CPM l
I
I Generalized activity networks ]
Signal flow graphs
I
I G'SP'' I
I
I
GERT
l GERTS
I GERT'''z II I ~F
II
I GR,SP
H
SMOOTH
GERT IIIQ
GERTE
I
I I GERT IIIQR
P-GERT
I
I
I
I I
GRASP IV
I
I
I
R-GERT
Q-GERT I
II QP-GERT I
I I
SAINT
]
I
Q-GERT Analysis Program I
transaction flow and diagrammatic specification of GPSS are evident in the language description [Meyerhoff 1968?]. An extensive set of symbols enabled a wide variety of graphical structures to be represented, and the subsequent diagram was transformed into an executable ALGOL program. Roth [ 1992] attributes an internal competition with SIMULA as the reason that BOSS was never converted into a marketable product, which was the motivation of the developing group. A very interesting application of BOSS during the 1970s was to message/communication processing by CPUs in a network model developed by Scotland Yard. Roth [1992] believes the language continued in use until approximately 1982.
398
CHAPTER VIII
PAPER:A HISTORYOF DISCRETEEVENTSIMULATION PROGRAMMINGLANGUAGES
Q-GERT, appearing in the early 1970s, is described by Pritsker as the first network-oriented simulation language [Pritsker 1990, p. 246]. It is based on the GERT network analysis technique developed by Pritsker, and is first reported in Pritsker and Burgess [1970]. The intent with Q-GERT was to provide a user friendly modeling interface with a limited number of node types that could be combined through edge definition to describe routing conditions. Obviously, Pritsker's experience with GASP II had an influence, and the GERT family tree shown in Figure 8.14 shows the mutual influence between GERT and GASP. Buxton [ 1968] contains descriptions of several languages offered in concept or perhaps developed to some extent during this period. Presentations at the 1967 IFIP workshop included: SPL (Petrone), AS (Parslow), SLANG (Kalinichenko).
8.5 THE EXPANSION PERIOD (1971-1978) The title for this period in SPL development emanates from the major expansions and extensions to GPSS, SIMSCRIPT 11.5, and GASP. The program generator concept, initiated in the U.S., took hold in the U.K. and became a major model development aid. 8.5.1
GPSS
The major advances in GPSS came from outside IBM as the success of the language caused others to extend either its capabilities or the host machine environment. 8.5.1.1
GPSS/NORDEN and NGPSS
Advances in GPSS were underway by the Norden Division of United Aircraft Corporation in the late
1960s. Labeled GPSS/NORDEN, this version of the language is an interactive, visual, on-line environment for executing GPSS models. Programmed in COBOL (the language known best by the programming team) [Reitman 1977?], GPSS/NORDEN permitted the user to interact through a CRT terminal, examining the behavior of the model (queues forming at facilities, storages filling and emptying, etc.) during execution. The user could interrupt model execution and redefine certain standard numerical attributes and then resume execution. The NORDEN report generator was described as a radically new free format English-like compiler that provides an ideal method for intermixing data, text, and titles [GPSS/NORDEN 1971, pp. 1-3]. GPSS/NORDEN in effect was a redesign around the matrix organization of GPSS. Model redefinition was accomplished through manipulation of matrices, and interactive statistical display and manipulation routines enabled both the inspection and alteration of matrix data, supported by the VP/CSS time sharing system. A film showing the use of this version of the language was distributed by the United Aircraft Corporation during the 1970s. A version of the language entitled NGPSS (Norden GPSS) is described in a report dated 15 December 197 I. Characterized as a superset of GPSS/360 and GPSS V for both batch and interactive versions, the User's Guide attributes the translator with the capability of handling very large databases, utilizing swapping capability to IBM 2311 or 2314 disk drives. A limited database capability is provided through the GPSS language to permit a modeler's access to matrix savevalues so that model components can be created and stored in a library [NGPSS 1971 ]. The User's Guide is replete with CRT displays of program block structures, data input, and model execution. A light pen is illustrated as used with the display [NGPSS 1971, p. 71].
DISCRETE EVENTSIMULATION LANGUAGESESSION
399
RICHARD E. NANCE 8.5.1.2
GPSS V/6000
A version of GPSS V was developed by Northwestern University for Control Data Corporation in a project completed in 1975. Program copyright is shown in [GPSS V/6000 1975]. GPSS V/6000 was intended to be fully compatible with the IBM product bearing the name GPSS V. In some cases perceived restrictions imposed in the IBM version were removed in order to allow compatibility with an earlier version GPSS 1II/6000 [GPSS V/6000 1975, p. v- 1]. The translator resided under the SCOPE 3.3 operating system (or later versions) and was a one-pass assembler in contrast to the two-pass IBM version. Differences between the two versions are described in detail in Appendix B of [GPSS V/6000 1975]. 8.5.1.3
GPDS and GPSS 1100
A version of GPSS, based apparently on GPSS/360, called the General Purpose Discrete Simulator, was a program product of Xerox Data Systems for the Sigma Computer line. Little is known about it beyond the identification in [Reifer 1973]. Similarly, a UNIVAC product labeled GPSS 1100 is referenced with a 1971 date [UNIVAC 1971a, 1971b]. Little else is known about this version, particularly, if it was related in any way to GPSS/UCC, which was also implemented on a UNIVAC 1108. 8.5.1.4
GPSS/H
In 1975, James O. Henriksen published a description of a compiler for GPSS that produced a 3:1 performance enhancement [Henriksen 1976]. With the announcement of the termination of support for GPSS V by IBM in the mid-1970s, Henriksen was poised to market his version of the language which was already gaining proponents. In 1977 GPSS/H was released by Wolverine Software Corporation, which have supported the language with extensive enhancements since that time [Schriber 1991, p. 17]. Other versions of the language have been developed, both on PCs and mainframes, but GPSS/H (the "H" for Henriksen) remains to date the most popular version. 8.5.2
SIMULA 67
The historical description in [Wexelblatt 1981 ] describes the period of expansion for SIMULA as the development of a pure system description language called DELTA [Holbaek-Hanssen 1977]. Beginning from the SIMULA platform, the DELTA Project sought to implement system specification for simulation execution through a series of transformations from the high-level user perspective, represented in the DELTA specification language, through an intermediate language called BETA, culminating with an executable language called GAMMA. Probably due to lack of funding, the project is not viewed as having been successful. Beyond the recognition of the lack of success of the DELTA project, little can be said conceptually about SIMULA during this period. However, the originating organization (Norwegian Computing Center) issued publications that noted comparisons of the language with other SPLs and sought to promote the language in this way [Virjo 1972; RCgeberg 1973]. Houle and Franta [1975, pp. 39-45] published an article showing that the structural concepts of SIMULA encompassed those of other languages, notably GPSS and SIMSCRIPT, and included a comparison with the language ASPOL [MacDougall 1973]. They specifically claim that GPSS and SIMSCRIPT concepts are a subset of the structural capabilities of SIMULA.
400
CHAPTER VIII
PAPER: A HISTORYOF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES 8.5.3
SIMSCRIPT
As the decade of the seventies opened, simulation languages provided contrasting positions in the representation of world views identified by Kiviat in the classic RAND report [ 1969]: event scheduling--SIMSCRIPT II, GASP II, activity scan--ECSL, and process interaction--GPSS V, SIMULA 67. However, those studying model and language representation concepts readily recognized a major distinction between GPSS and SIMULA in the representation of the process interaction world view, that is, GPSS lacked the flexibility of SIMULA in portraying interactions among permanent entities, which made the former cumbersome for problems where such relationships must be represented. The expansion period marked the beginnings of the breakdown in conceptual distinctions among languages. Nowhere was this more apparent than with SIMSCRIPT II. Supported by the U.S. Department of Agriculture, Agricultural Research Service, CACI completed the extension of SIMSCRIPT II.5 to include continuous simulation components in 1976. This effort is documented with a report authored by Claude M. Delfosse [ 1976] describing C-SIMSCRIPT. This report describes the definitions and program structure for continuous simulation and integration control variables within SIMSCRIPT I1.5. Examples of both continuous and combined models are given. Almost concurrently, the process view with focus on temporary entities was added to the language. Using the distinction of processes to describe the typical GPSS transaction and resources to represent facilities and storages, the modeling approach enabled a definition of resources as passive (permanent) entities and temporary entities represented as processes. Process instances are created similar to the creation and scheduling of events. An ACTIVE or CREATE statement is used. Within the process a WORK or WAIT statement provides for time passage, the latter with a process in a passive, the former an active, state. Processes may SUSPEND, INTERRUPT, or RESUME other processes. A second form of expansion took place in the form of computer system modeling languages based on SIMSCRIPT. Two such vehicles were ECSS [Kosy 1975] and CSP II [Iwata 1975]. Developed at the RAND Corporation, ECSS became a favored language for computer system performance evaluation studies. 8.5.4
GASP
During this period GASP was the subject of notable changes and considerable experimentation by Pritsker and his graduate students at Purdue. These activities are described extensively in Pritsker []9901. 8.5.4.1
GASP IV
GASP IV became available on a published basis with a book in 1974 [Pritsker 1974]. The contributions of Nicholas R. Hurst and C. Elliott Sigal are noted in the preface to the book. GASP IV proceeded philosophically in the differentiation between state and time as modeling characterizations. State events and time events became means of describing the event scheduling concept of an event and the activity scan concept of a condition. However, the concept of state variables was used to extend the discrete event capability to a continuous representation.
DISCRETE EVENT SIMULATIONLANGUAGE SESSION
401
RICHARD E. NANCE Mirroring the SIMSCRIPT II strategy, GASP augmented the transaction flow world view in the 1975-1976 time period [Washam 1976a, 1976b]. In [Pritsker 1990, p. 252] GASP is described as an on-going language development that is intended to produce subsequent versions at least up to GASP VI. The increased capability and flexibility of treating both continuous and discrete models within the same language provided a claimed advantage for GASP over its contemporaries. This advantage was short-lived because SIMSCRIPT followed with the capability in 1976 [Delfosse 1976]. 8.5.4.2
GASP_PL/I
In the early 1970s, several efforts were made to map a simulation language onto PL/I. Some of these are noted in the final section describing this period. GASP_PL/I, developed by Pritsker and Young [Pritsker 1975] produced a version of GASE A doctoral student examining the coded subroutines commented at the time that it appeared as if a FORTRAN programmer had done a statement by statement syntactic translation of FORTRAN into PL/I, and none of the PL/I features were utilized. Kiviat notes that preoccupation with a PL/I implementation was rather widespread at this time [Kiviat 1992]. 8.5.5
Program Generators
Simulation program generators were intended to accept a model definition in a noncxecutable form and produce an executable program or one that would admit execution after slight modification. In a sense the early definitional forms of SIMSCRIPT suggested such an approach, replacing the 80-column card specification with custom forms for entity definition and report generator layout. The first program generator was Programming By Questionnaire (PBQ), developed at the RAND Corporation [Ginsberg 1965; Oidfatber, 1966]. With PBQ model definition was accomplished through a user's completion of a questionnaire. The questionnaire, with the user's responses, forms a specification that produces a SIMSGRIPT program. While PBQ was under development at RAND, K.D. Tocher was showing the utility of "wheel charts" for model description in GSP [Tocber 1966]. The "wheel chart," based on the UK "machine based" (permanent entity) approach, pictured the cyclic activity of machines going from idle to busy as they interacted with material requiring the machine resource. In this same paper Tocher comments on the potential for real-time simulation for process control. Interactive program generators, those permitting an interactive dialogue between modeler and program generator, appeared in the early 1970s in the UK. CAPS-EGSL (Computer Aided Programming System/Extended Control and Simulation Language), developed by Alan T. Ciementson at the University of Birmingham, is generally considered the first [Matbewson 1975]. DRAFT, developed by Stephen Mathewson at Imperial College, appeared in several versions in which the activity cycle diagrams (also known as entity cycle diagrams), successors to the "wheel charts," are translated into DRAFT/FORTRAN, DRAFT/GASP, DRAFT/SIIVlON, or DRAFT/SIMULA programs [Mathewson 1977]. Two efforts, not specifically program generators but related to them, deserve mention in this section. The first is HOCUS, a very simple representational form for simulation model specification, first suggested by Hills and Poole in 1969 but subsequently marketed both in the U.S. and the U.K. in the early to mid- 1970s [Hills 1969]. The second is the natural language interface to GPSS, a project of George E. Heidorn at the Naval Postgraduate School in the early 1970s. Heidorn's work actually began at Yale University in 1967 as a doctoral dissertation [Heidorn 1976]. The project had as its eventual goal to enable an analyst working at a terminal to carry on a two-way dialogue with the 402
CHAPTER VIII
PAPER:A HISTORYOF DISCRETE EVENT SIMULATIONPROGRAMMINGLANGUAGES
computer about his simulation problem in English. The computer would then develop the model, execute the simulation, and report the results, all in an English dialect [Heidorn 1972, p.1]. 8.5.6
Other Languages
8.5.6.1
The PL/I Branch
The cessation of support for GPSS V coincided with a decision by IBM to create the language SIMPL/L a PLh preprocessor [S[MPL/[ 1972]. S]MPL/I has the distinct flavor of GPSS in its provision of the list processing, random number generation, and statistical routines, to assist in the modeling and simulation studies. Eater, SIMPL/I and GPSS V commands were made interchangeable, with the translation of both into PL/L Such a package, described as SIMPL/[ X or PL/[ GPSS, provided even greater flexibility to the modeler [Metz 1981]. Only a few IBM 360•370 Assembly Language routines augmented the PL/I implementation. SIMPL is a descendent of OPS-4, created by Malcolm W. Jones and Richard C. Thurber [Jones 1971a, 1971b]. Implemented on the MULTICS time sharing system, SIMPL was envisioned as a simulation system consisting of both a programming language and a run-time support system, quite similar to its ancestors. Again, PL/I provided the underlying translation capability with SIMPL source code being compiled into PL/I. Use of SIMULATE (model name) set up the special environment for simulation and initiated the model. Like OPS-4, the interactive time sharing environment, now provided by MULTICS, served as the major vehicle. A third member of the PL/I family, SIML/I, actually appeared in 1979 [MacDougall 1979]. Intended for computer system modeling, as was one of its predecessors ASPOL [MacDougall 1973], SIML/I provided representational capability "which extends into the gap between system-level and register-transfer-level simulation languages," [MacDougall 1979, p. 39]. The process interaction world view is apparent, perhaps influenced more by SOL than SIMULA. Process communication occurs via signals that can be simple or synthesized into more complex expressions. The influence of the application domain is readily apparent in the representation of signals. 8.5.6.2
The Pritsker Family
A. Alan B. Pritsker and Pritsker and Associates, Incorporated have contributed significantly to the development of simulation languages. In addition to GASP 1! and subsequent versions, GERTS (GERT Simulation program) provided a network modeling capability for simulation solutions to activity network models and queueing network formulations based on GERT, created earlier by Pritsker. Extensions to the network modeling capability resulted in a family of programs generally identifiable as one form of GERT or another. The GERT family tree is shown in Figure 8.14 which also shows the relationship to GASP [Pritsker 1990, pp. 242-243]. SAINT (Systems Analysis for Integrated Networks of Tasks) was developed by Pritsker and Associates under an Air Force contract that sought a modeling capability that enabled the assessment of contributions of system components especially human operators to overall performance [Wortman 1977a]. SAINT utilized a graphical approach to modeling, similar to Q-GERT, and depended on an underlying network representation. The continuous component was similar to the provided in GASP IV [Wortman 1977a, p.532]. Like GASP IV, SAINT is actually a simulator consisting of callable FORTRAN sub-routines and requiring approximately 55,000 decimal words of internal storage [Wortman 1977b, 1977c]. The contributions of numerous students and employeesarc generously described in Pritsker [1990].
DISCRETE EVENT SIMULATIONLANGUAGESESSION
403
RICHARD E. NANCE 8.5.6.3
Interactive Simulation Languages
The rapid acceptance and increased availability of time-sharing operating systems led to the emergence of interactive modeling systems based on user dialogue or conversational style. Two such languages during this period are CML (Conversational Modeling Language) developed by Ronald E. Mills and Robert B. Fetter of Yale University [undated]. CML was intended for language creation as well as a language for simulation purposes. The reference describes the use of CML for creation of a simulation language used to study hospital resource utilization. The power of CML was found in its ability to provide deferred run-time definition of model parameters and its ability for model modification and redefinition. The creators describe CML as equally useful as a simulation language, a general purpose programming tool, a specialized "package" for certain tasks, and an environment for systems programming. CONSIM was developed as a doctoral dissertation by Sailie Sheppard Nelson at the University of Pittsburgh. Considered a prototype conversational language, CONSIM is patterned after SIMULA 67 because of the recognized advanced capabilities of the language [Sheppard Nelson 1977, p. 16]. Coroutine sequencing, process description, and dynamic interaction in the CONSIM interpreter follow the design found in SIMULA 67. 8.6
C O N S O L I D A T I O N A N D R E G E N E R A T I O N (1979-.-1986)
The period from 1979 to 1986 might be characterized as one in which predominant simulation languages extended their implementation to many computers and microprocessors while keeping the basic language capabilities relatively static. On the other hand, two major descendants of GASP (in a sense) appeared to play major roles: SLAM II and SIMAN. 8.6.1
Consolidation
Versions of GPSS on personal computers included GPSS/PC developed by Springer Cox and marketed by MINUTEMAN Software [Cox 1984] and a Motorola 68000 chip version of GPSS/H [Schriber 1984, p. 14]. Joining the mapping of GPSS to PL/I are a FORTRAN version [Schmidt 1980] and an APL version [IBM 1977]. CACI extended SIMSCRIPT 11.5 even further by providing application dependent interfaces: NETWORK 11.5 for distributed computing in September 1985 and SIMFACTORY 11.5 for the modeling of manufacturing problems in October 1986 [Annino 1992]. An added interface in November 1987, COMNET I1.5, addressed the modeling of wide and local area communications networks. An extension of SIMULA, to capture an explicit transaction world view, called DEMOS, was introduced by Birtwistle [1979]. DEMOS was intended to provide modeling conveniences (built in resource types, tracing, report generation capability) that were lacking in SIMULA [Birtwistle 1981, p. 567]. 8.6.2
SLAM AND SLAM II
The Simulation Language for Alternative Modeling (SLAM), a GASP descendent in the Pritsker and Associates, Inc. software line, sought to provide multiple modeling perspectives: process, event, or state variables, each of which could be utilized exclusively or joined in a combined model [Pritsker 1979]. SLAM appeared in 1979; SLAM II, in 1983 [O'Reilly 1983]. (Note that the acronym SLAM
404
CHAPTER VIII
PAPER: A HISTORYOF DISCRETE EVENT SIMULATIONPROGRAMMING LANGUAGES
is also used for a continuous simulation language developed in the mid-1970s [Wallington 1976]. The two are not related.) 8.6.2.1
Background
The background for SLAM introduction included the coding of processes as an addition to GASP IV in a version called GASPPI. This work was done as a master's thesis by Ware Washam [Washam 1976a]. Jerry Sabuda in a master's thesis at Purdue did the early animation work for Q-GERT networks that led to its incorporation eventually in the SLAM II PC animation program and SLAMSYSTEM ® [Pritsker 1990, p. 292]. Pritsker [1990, p.290-293] describes the long, evolutionary process in developing highly usable simulation languages. The intended purpose of SLAM was to join diverse modeling perspectives in a single language that would permit a large degree of flexibility as well as strong capability to deal with complex systems. Modeling "power" was considered the primary support capability influencing the design of the language and the later evolution of SLAMSYSTEM® [pritsker 1991 ]. 8.6.2.2
Rationale for Language Content
Clearly, GASP, Q-GERT, SAINT, and several variations of each contributed to the creation of SLAM. In fact, many of the identical subroutine and function names in GASP IV are repeated in SLAM. 8.6.2.3
Language Design and Definition
Unlike its predecessors which were simulators, SLAM is a FORTRAN preprocessor, with the preprocessing requirements limited to the network modeling perspective. The simulator aspect is preserved in the representation of continuous and discrete event models. Improvements were made to the functions and subroutines making up the discrete event and continuous components, but the major structure of the SLAM design followed that of GASP. 8.6.2.4
Nontechnical Influences
After the completion and delivery of SLAM as a product, differences occurred between Pfitsker and Pegden over the rights to the language and a court case ensued. Settlement of the case dictated neither party should say more about the relationship of SLAM to SIMAN, a language developed in 1980o1983 by Pegden. The statements below are taken from Prefaces to the most current sources for each language. C. Dennis Pegden led in the development of the original version of SLAM and did the initial conception, design, and implementation. Portions of SLAM were based on Pritsker and Associates' proprietary software called GASP and Q-GERT. Since its original implementation, SLAM has been continually refined and enhanced by Pntsker and Associates [Pritsker 1986, p. viii]. Many of the concepts included in SIMAN are based on the previous work of other simulation language developers. Many of the basic ideas in the process-orientation of SIMAN can be traced back to the early work of Geoffrey Gordon at IBM who developed the original version of GPSS. Many of the basic ideas in the discrete-event portion of SIMAN can be traced back to the early work by Philip Kiviat at U.S. Steel who developed the original version of GASP. SIMAN also contains features which Pegden originally developed for SLAM. Some of the algorithms in SIMAN are based on work done by Pdtsker and Associates. The combined discrete-continuous features of S1MAN are in part based on SLAM [Pegden 1990, p. xi].
DISCRETE EVENT SIMULATIONLANGUAGE SESSION
405
RICHARD E. NANCE
8.6.3 SIMAN The name SIMAN derives from SIMulation ANalysis for modeling combined discrete event and continuous systems. Originally couched in a manufacturing systems application domain, SIMAN possesses the general modeling capability for simulation found in languages such as GASP IV and SLAM II.
8.6.3.1 Background Developed by C. Dennis Pegden, while a faculty member at Pennsylvania State University, S1MAN was essentially a one-person project. A Tektronix was used as the test bed for the language, which originated as an idea in 1979 and moved rapidly through initial specifications in 1980, to final specification and a prototype in 198 I. A full version of the language was completed in 1982, and the release date was in 1983. 8.6.3.2
Rationale for Language Content
SIMAN incorporates multiple world views within a single language: 1. a process orientation utilizing a block diagram similar to that of GPSS, 2. an event orientation represented by a set of FORTRAN subroutines defining instantaneous state transitions, and 3. a continuous orientation, utilizing dependent variables representing changes in state over time (state variables). Thus, SIMAN is either a FORTRAN preprocessor or a FORTRAN package depending on the selected world view. The use of FORTRAN as the base for SIMAN was justified by the wide availability of the latter language on mainframes and minicomputers. Pegden [ 1991] acknowledges that in today's technical market place it would be much easier if written in C or C++.
Influencing Factors SIMAN draws concepts from GPSS, SIMSCRIPT, SLAM, GASP, and QGERT [Pegden 1991]. The primary contributions are the combined process, next event, and continuous orientation from SLAM and the block diagram and process interaction concepts from GPSS. New concepts introduced in SIMAN include general purpose features embedded in specialized manufacturing terminology, for example, stations, conveyors, transporters. SIMAN has claimed to be the first major simulation language executable on the IBM PC and designed to run under MS-DOS constraints [Pegden 1991]. Macro submodels provide convenient repetition of a set of objects without replication of entire data structures. Nontechnical Influences Systems Modeling Corporation in marketing SIMAN recognized the major advantage of output animation and created a "companion" product called CINEMA. 8.6.4
The PASCAL Packages
The emergence of yet another popular general purpose language--Pascal--stimulated a repetition of history in the subsequent appearance of simulation packages based on the language. Bryant [1980; 1981 ] developed SIMPAS as an event scheduling language through extensions of Pascal that met the six requirements for simulation (described in section 8.1.1.2). Implemented as a preprocessor,
406
CHAPTER VIII
PAPER: A HISTORYOF DISCRETE EVENT SIMULATIONPROGRAMMING LANGUAGES
SIMPAS was designed to be highly portable yet complete in its provision of services. In contrast, PASSIM [Uyeno 1980] provided less services, requiring more knowledge of Pascal by the modeler. INTERACTIVE, described as a network simulation language, used graphical symbols in a four-stage model development process that supported interactive model construction and execution [Lakshmanan 1983]. The implementation on microcomputers, coupled with the ability of Pascal to support needed simulation capabilities, motivated the development of the package [Mourant 1983, p. 481]. 8.6.5
O t h e r Languages
INSIGHT (INS) was developed by Stephen D. Roberts to model health care problems and as a general simulation modeling language [Roberts 1983a]. Utilizing the world view of a network of processes, INSIGHT adopts the transaction flow characterization of object interaction with passive resources. Described as a simulation modeling language rather than a programming language or parameterized model [Roberts 1983b, p. 7], INSIGHT provides a graphical model representation that must be translated manually into INSIGHT statements. INSIGHT provides the usual statistical utilities for random number generation but also provides assistance for output analysis. A default output of model behavior can be supplemented through a TABLE statement, and the utilization of FORTRAN is always available for the user of this preprocessor. 8.7
CONCLUDING SUMMARY
The history of simulation programming languages is marked by commercial competition, far more intense than that of general purpose languages. Perhaps that single fact explains the identifiable periods of remarkably similar behavior. Such competition might also be the motivator for the numerous concepts and techniques that either originated with an SPL or gained visibility through their usage in the language. Among the most significant are: • the process concept, • object definition as a record datatype, • definition and manipulation of sets of objects, • implementation of the abstract data type concept, • quasi-parallel processing using the coroutine concept, • delayed binding with run-time value assignment, • English-like syntactic statements to promote self-documentation, • error detection and correction in compilation, • dynamic storage allocation and reclaim, and • tailored report generation capabilities. Acknowledged as the first object-oriented programming language, SIMULA 67 with its combination of features such as encapsulation, inheritance, the class and coroutine concepts, still remains a mystery to the large majority of the programming language community. Moreover, it remains an unknown to the majority of those hailing the object-oriented paradigm, irrespective of their knowledge in discrete event simulation.
DISCRETE EVENT SIMULATION LANGUAGE SESSION
407
RICHARD E. NANCE
Although the ALGOL roots are often cited as the cause of SIMULA's relative obscurity, what dooms SIMSCRIPT to a similar fate? Is it the FORTRAN roots? Addressing the issue more seriously, the entity-attribute-relational view of data was both implicitly and explicitly enunciated in SIMSCRIPT fully ten years before Peter Chen's landmark paper in database theory [Chen 1976]. Yet, neither the database systems nor the programming languages community took notice. Given the early prominence attached to simulation programming languages, reflected by the significance of meetings such as the IFIP Working Conference [Buxton 1968] and the eminence of the attendees, what has led to the appearance of lack of interest by the larger community (be it programming languages or computer science)? Has this subdisciplinary insularity been counter-productive in the development of current general purpose languages? Is this insularity a two-way phenomenon and, if so, is MODSIM (a recently developed object-oriented SPL) likely to suffer for it? Although a series of questions might be thought unseemly to close a paper such as this, the answers to them seem crucial to answering a more fundamental question of the programming language community: Is the past only a prologue?
ACKNOWLEDGMENTS I am deeply indebted to Philip J. Kiviat for his guidance throughout the development of this paper. 1 am grateful also to those who provided personal information on various languages and other topics: Joseph Annino, Nick Cooper, Donald E. Knuth, C. Dennis Pegden, A. Alan B. Pfitsker, and Paul E Roth. My thanks also to my colleagues, James D. Arthur, for his help in language and translator characteristics, and Osman Balci, for discussions of language and model representational issues.
REFERENCES [Ackoff, 1961] Ackoff, Russell L., ed., Progress in Operations Research, I,blume 1, New York: John Wiley and Sons, 1961, pp. 375-376. [Annino, ! 992] Annino, Joseph, Personal Communication, April ! 992. [Belkin, 1965?] Belkin, J. and M.R. Rao, GASP User's Manual, United States Steel Corporation, Applied Research Laboratory, Moarocville, PA, undated (bolieved to bo in i 965). lBennctt, 1962] Bennett, R.E, P.R. Cooley, S.W. Hovey, C.A. Kdbs, and M.R. Lackner, Simpac User's Manual, Report #TM-602/000/00, System Development Corporation, Santa Monica, CA, April 1962. [Birtwistle, 1979] Birtwistle, Graham M., DEMOS: A System for Discrete Event Modeling on SIMULA, London: New York: Macmillan, 1979. [Birtwistlc, 1981] Birtwistle, Graham M., Introduction to Demos, In Proceedings tOrthe 1981 Winter Simulation Conference, T.I. Orcn, C.M. Delfosse, C.M. Shah, Eds., 1981, pp. 559-572] [Bryant, 1980] Bryant, R.M., SIMPAS--A simulation language based on PASCAL, In Proceedings of the 1980 Winter Simulation Conference, T.I. Oren, C.M. Shub, and EE Roth, Eds., 1980, pp. 25-40. [Bryant, 1981] Bryant, R.M., A tutorial on simulation programming with SIMPAS, In Proceedings of the 1981 Winter Simulation Conference, T.I. Oren, C.M. Delfosse, and C.M. Shub, Eds., 1981, pp. 363-377. [Buxton, 1966] Buxton, J.N., Writing simulations in CSL, The Computer Journal, 9:2, 1966, pp. 137-143.. lBuxton, 1968] Buxton, J.N., Ed., Simulation programming languages, In Proceedings of the IFIP Working Conference on Simulation Programming Languages, North-Holland Publishing Company, 1968. lBuxton, 1962] Buxton, J.N. and J.G. Laski, Control and simulation language, The Computer Journal, 5:3, 1962, pp. 194-199. [Buxton, 1964] - - , Courlaulds All Purpose Simulator, Programming Manual, Courtaulds Ltd., 1964. [CACI, 1983] CACI, SIMSCRIPT 11.5Programming, Language, CACI, Los Angeles, 1983. [Chen, 1976] Chen, EE, The entity-relationship model--toward a unified view of data, ACM Transactions on Database Systent¢, l:l, 1976, pp. 9-36. [Chnsman, 1966] Chdsman, J.K., Summary of the Workshop on Simulation Languages Held March 17-18, 1966, University of Pennsylvania, Sponsored by the IEEE Systems Services and Cybernetics Group and the Management Center, April 28, 1966. 408
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
[Clementson, 1966] Clementson, A.T., Extended control and simulation language, The Computer Journal, 9:3, 1966, pp. 215-220. [Conway, 1965] Conway, R.W., J.J. Deifausse, W.L. Maxwell, and W.E. Walker, CLP--The Com¢ll LISP processor, CommunicationsACM, 8:4, Apr. 1965, pp. 215-216. [Conway, 1967] Conway, Richard W., William L. Maxwell, and Louis W. Miller, Theory of Scheduling, Reading MA: Addison-Wesley, 1967. [Cox, 1984] Cox, Springer, GPSS/PC User's Manual, MINUTEMAN Software, Stowe, MA, 1984. [Crookes, 1982] Crookes, John G., Simulation in 1981, European Journal of Operational Research, 9: 1, 1982, pp. 1-7. [Delfoss¢, 1976] Delfosse, Claude M., Continuous Simulation and Combined Simulation in SIMSCRIPT II.5, Arlington, VA: CACI, Mar. 1976. [Derrick, 1988] Derrick, Emory Joseph, Conceptual Frameworks for Discrete Event Simulation, Master's Thesis, Department of Computer Science, Virginia Polytechnic Institute and State University, Blacksburg, Virginia, Aug. 1988. [Esso, 1963] C.S.L.: Reference Manual/Control and Simulation Language, Esso Petroleum Company, Ltd. and IBM United Kingdom, Ltd., 1 Mar. 1963. [Flshman, i 973] Fishman, George S., Concepts and Met/vMs in Discrete Event Digital Simulation, New York: John Wiley and Sons, 1973, pp. 22-58. [Flow Simulator, RCA, 1967] Flow Simulator, RCA publication #70-05-008, Oct. 1967. [Flow Simulator Information Manual, RCA, 1967] Flow Simulator Information Manual, RCA publication #70-35-503, Oct. 1967. [Forrester, 1961] Forrester, Jay W., Industrial Dynamics, Cambridge, MA: The MIT Press, 1961. [Geisler, 1966] Geisler, Murray A. and Allen S. Ginsberg, Man-machine simulation experience, In Proceedings IBM Scientific Computing Symlx~sium on Simulation ModeL~ and Gaming, White Plains, New York, 1966, pp. 225-242. [Ginsberg, 1965] Ginsberg, Allen S., Harry M. Markowitz, and Paula M. OIdfather, Programming by Questionnaire, Memorandum RM-4460-PR, RAND Corporation, Apr. 1965. [Gordon, 1966] Gordon, Geoffrey, Simulation languages for discrete systems, In Proceedings IBM Scient(fic Computing Symposium on Simulation Models and Gaming, White Plains, New York, 1966, pp. 101-118. [Gordon, 1981] - - , The development of the general purpose simulation system (GPSS), Hiswry of Programming Languages, Richard L. Wexelblatt Ed., New York: Academic Press, 1981, pp. 403-437. [GPS K, 1969] General Purpose Simulator K, Honeywell publication, file #123.8405.001 K, April 1969. [GPSS/NORDEN, 1971] GPSS/NORDEN Simulation Language, Norden Division of United Aircraft Corporation, form 910-1, Mar. 1971, pp. I-3. [GPSS V, 1970] General Purpose Simulation System V, User's Manual, IBM publication #SH20-0851-0, Oct. 1970. [GPSS V, 1971] General Purpose Simulation System V, Introductory User's Manual, IBM publication #SH20-0866-0, Oct. 1971. [GPSS V/6000, 1975] GPSS V/6000 General Information Manual, Control Data Corporation, 84003900, 1 Dec. 1975. [Greenberg, 1972] Greenberg, Stanley, GPSS Primer, New York: John Wiley and Sons, 1972. [Greenberger, 1968] Greenberger, Martin and Malcolm M. Jones, On-Line Incremental Simulation, in Simulation Programming Languages, J.N. Buxton, Ed., North-Holland, 1968, pp. 13-32. [Greenberger, 1965] Greenberger, Martin, Malcolm M. Jones, James H. Morris, and David N. Ness, On Dash Line Computation and Simulation: The OPS-3 System, Cambridge, MA: MIT Press, 1965. [Heidorn, 1972] Heidorn, George E., Natural Language Inputs to a Simulation Programming System, Naval Postgraduate School, NPS-55HD72101A, Oct. 1972. [Heidom, 1976] , Automatic programming through natural language dialogue, a survey, IBM Journal (~fResearch and Development, July 1976, pp. 302-313. [Henriksen, 1976] Henfiksen, James O., Building a better GPSS: a 3:1 enhancement, In Proceedings of the 1975 Winter Simulation Conference, Montvale, NJ: AF1PS Press, 1976, pp. 465-469. [Hills, 1969] Hills, B.R. and T.G. Poole, A Method for Simplifying the Production of Computer Simulation Models, T1MS Tenth American Meeting, Atlanta, Georgia, Oct. I-3, 1969. [Holbaek-Hanssen, 1977] Holbaek-Hanssen, Erik, Peter H~indlykken, and Kristen Nyganrd, System Description and the DELTA Language, DELTA Project Report No. 4, Second Printing, Norwegian Computing Center, Feb. 1977. [Houle, 1975] Houle, P.A. and W.R. Franta, On the structural concepts of SIMULA, The Australian Computer Journal, 7:1, Mar. 1975, pp. 39-45. [IBM, 1965] International Business Machines, General Purpose Simulator I11: Introduction, Application Program, Technical Publications Department, White Plains, New York, 1965. [IBM, 1977] International Business Machines, APL GPSS, Form #G320-5745 and SH20-1942, Armonk, NY, 1977. [IBMUK, 1965] IBM United Kingdom Ltd., CSL Reference Manual, 1965.
DISCRETE EVENT SIMULATION LANGUAGE SESSION
409
RICHARD E. NANCE
[lwata, 1975] lwata, H.Y. and Melvin M. Cutler, CSP 11--A universal computer architecture simulation system for performance evaluation, Symposium on the Simulation of Computer Systems, 1975, pp. 196-206. [Jones, 1967] Jones, Malcolm M., Incremental Simulation on a Time-Shared Computer, unpublished Ph.D. dissertation, Alfred P. Sloane School of Management, Massachusetts Institute of Technology, Jan. 1967. [Jones, 1971a] Jones, Malcolm M. and Richard C. Thurber, The SIMPL Primer, Oct. 4, 1971. [Jones, 1971b] - - , SIMPL Reference Manual, Oct. 18, 1971. [Karr, 1965] Karr, H.W., H. Kleine, and H.M. Markowitz, SIMSCR1PT 1.5, CAC165-1NT-1, Los Angeles: CACI, Inc., 1965. [Kelly, 1962] Kelly, D.H. and J.N. Buxton, Montecode--an interpretive program for Monte Carlo simulations, The Computer Journal, 5, p. 88. [Kiviat, 1962a] Kiviat, Philip J., Algorithm 100: add item to chain-linked list, Communications of the ACM, 5:6, June 1962, p. 346. [Kiviat, 1962b] - - - , Algorithm 100: remove item from chain-linked list, Communications t~fthe ACM, 5:6, June 1962, p. 346. [Kiviat, 1963a] - - , GASP: General Activities Simulation Program Programmer's Manual, Preliminary Version, Applied Research Laboratory, Monroeville, PA: United States Steel Corporation, Jan. 16, 1963. [Kiviat, 1963b] - - , GASP--A General Purpose Simulation Program, Applied Research Laboratory 90.17-019(2), United States Steel Corporation, undated (believed to he around Mar. 1963). [Kiviat, 1963c] - - , Introduction to Digital Simulation, Applied Research Laboratory 90.17-019(1), United States Steel Corporation, Apr. 15, 1963 (stamped date). [Kiviat, 1966] , Development of new digital simulation languages, Journal c~flndustrial Engineering, 17:11, Nov. 1966, pp. 604-609. [Kiviat, 1967] , Digital Computer Simulation: Modeling Concepts, RAND Memo RM-5378-PR, RAND Corporation, Santa Monica, California, Aug. 1967. [Kiviat., 1968] Kiviat, Philip J., R. Villanueva, and H.M. Markowitz, The SIMSCRIPTII Programming Language, Englewood Cliffs, NJ: Prentice Hall, Inc., 1968. [Kiviat, 1969] - - , Digital Computer Simulation: Computer Programming Languages, RAND Memo RM-5883-PR, RAND Corporation, Santa Monica, CA, Jan. 1969. [Kiviat, 1991a] - - , Personal Communication, May 13, 1991. [Kiviat, 1991b] - - , Personal Communication, July 5, 199 I. [Kiviat, 1992] , Personal Communication, Feb. 3, 1992. [Knuth, 1992] Knuth, Donald E., Personal Communication, Nov. 24, 1992. [Knuth, 1964a] Knuth, D.E. and McNeley, J.L., SOL--a symbolic language for general purpose system simulation, IEEE Transactions on Electronic Computers, EC-13:4, Aug. 1964, pp. 401-408. [Knuth, 1964b] - - , A formal definition of SOL, IEEE Transactions on Electronic Computers, EC-13:4, Aug. 1964, pp. 409-414. [Kosy, 1975] Kosy, D.W., The ECSS 11Language for Simulating Computer Systems, RAND Report R1895-GSA, Dec. 1975. [Krasnow, 1967] Krasnow, H.S., Dynamic presentation in discrete interaction simulation languages, Digital Simulation in Operational Research, S.H. Hollingsdale, Ed., American Elsevier, 1967, pp. 77-92. [Krasnow, 1964] Krasnow, H.S. and R.A. Merikallio, The past, present, and future of general simulation languages, Management Science, 11:2, Nov. 1964, pp. 236-267. [Lackner, 1962] Lackner, Michael R., Toward a general simulation capability, In Proceedings qfthe SJCC, San Francisco, CA, 1-3 May 1962, pp. 1-14. [Lackner, 1964] - - , Digital Simulation and System Theory, System Development Corporation, SDC SP-1612, Santa Monica, CA, 6 Apr. 1964. [LaLshmanan, 1983] Lakshmanan, Ramon, Design and Implementation of a PASCAL Based Interactive Network Simulation Language for Microcomputers, unpublished Ph.D. dissertation, Oakland University, Rochester, MI, 1983. [Law, 1991] Law, Averill M. and David Kelton, Simulation Modeling and Analysis, Second Edition, New York: McGraw-Hill, Inc., 1991. [Licklider, 1967] Licklider, J.C.R., Interactive dynamic modeling, Prospects for Simulation and Simulators of Dynamic Systent~, George Shapiro and Milton Rogers, eds., Spartan Books, 1967. [Llewellyn, 1965] Llewellyn, Robert W., FORDYN: An Industrial Dynamics Simulator, Typing Service, Raleigh, NC, 1965. [MacDougall, 1979] MacDougall, M.H., The simulation language SIML/I, In Proceedings of the National Computer Conference, 1979, pp. 39---44. [MacDougall, 1973] MacDougall, M.H. and J. Stuart MacAlpine, Computer simulation with ASPOL, In Proceedings Symposium on the Simulation of Computer Systems, 1973, pp. 92-103.
410
CHAPTER VIII
PAPER: A HISTORY OF DISCRETE EVENT SIMULATION PROGRAMMING LANGUAGES
[Markowitz, 1979] Markowitz, Harry M., SIMSCRIPT: past, present, and some thoughts about the future, Current Issues in Computer Simulation, N.R. Adam and All Dogramaci, Eds., New York: Academic Press, pp. 27-60, 1979. [Markowitz, 1963] Markowitz, Harry M., Bernard Hansnar, and Herbert W. Karr, SIMSCRIPT: A Simulation Programming Language, The RAND Corporation, Englewood Cliffs, NJ: Prentice Hall, Inc., 1963. [Mathewson, 1975] Mathewson, Stephen C., Interactive simulation program generators, In Proceedings of the European Computing Conference on Interactive Systems, Bronel University, UK, 1975, pp. 423-439. [Mathcwson, 1977] Matbewson, Stephen C. and John A. Alan, DRAFT/GASP--A program generator for GASP, In Proceedings of the Tenth Annual Simulation Symposium, Tampa, Florida, W.G. Key, et al., Eds., 1977, pp. 211-228. [Metz, 1981] Metz, Walter C., Discrete event simulation using PL/I based general and special purpose simulation languages, In Proceedings of the Winter Simulation Conference, T.I. Oren, C.M. Delfosse, C.M. Shub, Eds., 1981, pp. 45-52. [Meyerhoff, 1968?] Meyerhoff, Albert J., Paul E Roth, and Philip E. Shafer, BOSS Mark II Reference Manual, Burroughs Corporation, Defense, Space, and Special Systems Group, Document #66099A, undated. [Mills, undated] Mills, Ronald E. and Robert B. Fetter, CML: A Conversational Modeling Language, Technical Report #53, undated. [Morgenthaler, 1961] Morgenthaler, George W., The theory and application of simulation and operations research, Progress in Operations Research !, New York: John Wiley and Sons, 1961. [Mourant, 1983] Mourant, Ronald R. and Ramon Lakshmanan, INTERACTIVE--a user friendly simulation language, In Proceedings of the 1983 Winter Simulation Conference, S. Roberts, J. Banks, and B. Schmeiser, Eds., 1983, pp. 481-494. [Nance, 1981] Nance, Richard E., 1981, The time and state relationships in simulation modeling, Communications ACM, 24:4, Apr. 1981, pp. 173-179. [NGPSS, 1971] User's Guide to NGPSS, Norden Report 4339 R 0003, Norden Division of United Aircraft Corporation, 15 Dec. 1971. [Nygaard, 1981] Nygaard, Kdsten and Ole-Johan Dahl, The development of the SIMULA languages, HL~toryof Programming Languages, Richard L. Wexelblatt, Ed,, New York: Academic Press, 1981, pp. 439-491. [Oldfather, 1966] Oldfather, Panla M., Allen S. Ginsberg, and Harry M. Markowitz, Programming by Questionnaire: How to Construct a Program Generator, Memorandum RM-5129-PR, Nov. 1966. [O'Reilly, 1983] O'Reilly, Jean J., SLAM 11 User's Manual, Pritsker and Associates, Inc., West Lafayette, IN, 1983. [Overstreet, 1986] Overstreet, C. Michael and Richard E. Nance, World view based discrete event model simplification, Modeling and Simulation Methodology in the Artificial Intelligence Era, Maurice S. Elzas, Tuner E. Oren, and Bernard P. Zeigler, Eds., North Holland, 1986, pp. 165-179. [Parkin, 1978] Parkin, A. and R.B. Coats, EDSIM--Event based discrete event simulation using general purpose languages such as FORTRAN, The Computer Journal, 21:2, May 1978, pp. 122-127. [Pegden, ! 991 ] Pegden, C. Dennis, Personal Communication, Jane 11, 1991. [Pegden, 1990] Pegden, C. Dennis, R.E. Shannon, and Randall P. Sadowski, Introduction to Simulation Using SIMAN, New York: McGraw-Hill, 1990. [Pritsker, 1967] Pfitsker, A. Alan B., GASP 11User's Manual, Arizona State University, 1967. [Pritsker, 1969] Pritsker, A. Alan B. and Philip J. Kiviat, Simulation with GASP !I: A FORTRAN Based Simulation Language, Englewood Cliffs, NJ: Prentice Hall, 1969. [Pritsker, 1970] Pritsker and R.R. Burgess, The GERT Simulation Programs: GERTs 111, GERTs ill-Q, GERTs, Ill-R, NASA/ERC contract NASI 2-2113, Virginia Polytechnic Institute and State University, Blacksburg, VA, 1970. [Pntsker, 1974] Pritsker, A. Alan B., The GASP IV Simulation Language, New York: John Wiley and Sons, 1974. [Pritsker, 1975] Pritsker, A. Alan B. and R.E. Young, Simulation with GASP_PL/I, New York: John Wiley and Sons, 1975. [Pntsker, 1979] Pritsker, A. Alan B. and Claude Dennis Pegden, Introduction to Simulation and SLAM, John Wiley and Sons, 1979. [Pritsker, 1986] - - , Introduction to Simulation and SLAM 11, Systems Publishing Corporation, 1986. [Pritsker, 1990] , Papers, Experiences, Perspectives, Systems Publishing Company, 1990. [Pfitsker, 1991] - - , Personal Communication, 13 June, 1991. [Pugh, 1963] Pugh, Alexander L., 111,DYNAMO User's Manual, Cambridge, MA: The MIT Press, Second Edition, 1963. [Pugh, 1973] , DYNAMO II User's Manual, including DYNAMO II (Subscript F). Cambridge, MA: The MIT Press, Forth Edition, 1973. [Pugh, 1976] - - , DYNAMO User's Manual, including DYNAMO 11/370, DYNAMO I1/F, DYNAMO 111, Gaming DYNAMO, Cambridge, MA: The MIT Press, Fifth Edition, 1976. [Reifer, 1973] Reifer, Donald J., Simulation Language Survey, Hughes Aircraft Corporation, Interdepartmental Correspondence, Ref. 2726.54/109, 24 July, 1973. [Reitman, 1967] Reitman, Julian, The user of simulation languages--the forgotten man, In Proceedings ACM 22nd National Conference, 1967, pp. 573-579.
DISCRETE EVENT SIMULATION LANGUAGE SESSION
411
RICHARD E. NANCE
[Reitman, 19777] Reitman, Julian, Personal Communication, around 1977. [Reitman, 1992] Reitman, Julian, How the software world of 1967 conspired (interacted?) to produce the first in the series of Winter Simulation Conferences, In Proceedings of the 1992 Winter Simulation Conference, James J. Swain, Robert C. Craln, and James R. Wilson, Eds., 1992, pp. 52-57. [Roberts, 1983a] Roberts, Stephen D., Simulation Modeling and Analysis with INSIGHT, Regenstrief Institute for Health Care, Indianapolis, IN, 1983. [Roberts, 1983b] Roberts, Stephen D., Simulation modeling with INSIGHT, In Proceedings of the 1983 Winter Simulation Conference, Stephen D. Roberts, Jerry Banks, Bruce Sehmeiser, Eds., 1983, pp. 7-16. [Regeberg, 1973] R¢geherg, Thomas, Simulation and Simulation Languages, Norwegian Computing Center, Publication No. S-48, Osio, Norway, Oct. 1973. [Rosen, 1967] Rosen, Saul, Programming systems and languages: a historical survey, Programming Systems and Languages, S. Rosen, Ed., New York: McGraw-Hill, 1967. [Roth, 1992] Roth, Paul E Personal Communication, Feb. 1992. [Sammet, 1969] Sammet, Jean E., Programming Languages: History and Fundamentals, First Edition, Englewood Cliffs, N J: Prentice-Hall, 1969, p. 650. [sehmidt, 1980] Schmidt, Bernd, GPSS _ FORTRAN, New York: John Wiley and Sons, 1980. [sehriber, 1974] Schriber, Thomas J., Simulation Using GPSS, New York: John Wiley and Sons, 1974. [Schriber, 1984] - - , Introduction to GPSS, In Proceedings of the 1984 Winter Simulation ConJerence, Sallie Sheppard, Udo W. Pooch, C. Dennis Pegdcn, Eds., 1984, pp. 12-15. [sehriher, 1991] - - - , An Introduction to Simulation, New York: John Wiley and Sons, 1991. [Shantikumar, 1983] Shantikumar, J.G. and R.G. Sargent, A unifying view of hybrid simulation/analytic models and modeling, Operations Research, 31:6, Nov.-Dec. 1983, pp. 1030-.-1052. [Sheppard Nelson, 1977] Sheppard Nelson, Sallie, Control Issues and Development of a Conversational Simulation Language, unpublished Ph.D. dissertation, University of Pittsburgh, 1977. [Shreider, 1966] Sehrioder, Yu A., Ed., The Monte Carlo Method: The Method ¢~fStatistical TriaLt, Tarrytown, NY: Pergamon Press, 1966. [SIMPL/I, 1972] SIMPL/I (Simulation Language Based on PL/I), Program Reference Manual, IBM publication number SH19-5060-0, June 1972. [Systems Research Group, Inc., 1964] Systems Research Group, Inc. MILITRAN Programming Manual, Prepared for the Office of Naval Research, Washington, DC, June 1964. [Teichrow, ! 966] Teichrow, Daniel and John Francis Lubin, Computer simulation--discussion of the technique and comparison of languages, Communications of the ACM, 9:10, Oct. 1966, pp. 723-741. [Tocher, 1965] Tocher, K.D., Review of simulation languages, Operational Research Quarterly, 16:2, June 1965, pp. 189-217. [Tocher, 1966] - - - , Some techniques of model building, In Proceedings IBM Scientific Computing Symposium on Simulation Models and Gaming, White Plains, New York, 1966, pp. 119-155. [Tother, 1960] Tocher, K.D. and D.G. Owen, 1960, The automatic programming of simulations, In Proceedings offthe Second International Conference on Operational Research, pp. 50-68. [Tonge, 1965] Tonge, Fred M., Peter Keller, and Allen Newell, Quikscript--a simseript-like language for the G-20, Communications ¢~ftheACM, 8:6, June 1965, pp. 350.-.-354. [UNIVAC 1100, 1971a] UNIVAC I100 Series General Purpose Simulator (GPSS I100) Programmer Reference, UP-7883, 1971. [UNIVAC 1100, 1971b] UNIVAC 1100 General Purpose Systems Simulator H Reference Manual, UP 4129, 1971. [Uyeno, 1980] Uyeno, D.H. and W. Vaessen, PASSIM: a discrete-event simulation package for PASCAL, Simulation 35:6, Dec. 1980, pp. 183-190. [Virjo, 1972] Virjo, Antti, A Comparative Study of Some Discrete Event Simulation Languages, Norwegian Computing Center Publication #S-40 (reprint of a presentation at the Nord Data 1972 Conference, Helsinki). [Wallington, 1976] Wallington, Nigel A. and Richard B. Were, SLAM: a new continuous-system simulation language, In SCS Simulation Councils Prt~'eedings Series: ~ward Real-Time Simulation (Languages, Models, and Systent~), Roy E. Crosbie and John L. Hays, Eds., 6:1, Dec. 1976, pp. 85-89. [Washam, 1976a] Washam, W.B., GASPPI: GASP IV with Process Interaction Capabilities, unpublished Master's thesis, Purdue University, West Lafayette, IN, 1976. [Washam, 1976b] Washam, W.B. and A. Alan B. Pritsker, Putting Process Interaction Capability into GASP IV, ORSA/TIMS Joint National Meeting, Philadelphia, 1976. [Wexelblatt, 1981] Wexeiblatt, Richard L. History t~f Programming Languages, New York: Academic Press. This is the Proceedings of the ACM SIGPLAN History of Programming Languages Conference, 1-3 June 1978. It is a volume in the ACM Monograph Series.
412
CHAPTER VIII
TRANSCRIPTOF SIMULATIONPRESENTATION
[Wilson, 1992] Wilson, James R., The winter simulation conference: perspectives of the founding fathers, twenty-fifth anniversary panel discussion, In Proceedings of the 1992 Winter Simulation Conference, James J. Swain, Robert C. Crain, and James R. Wilson, Eds., 1992 (to appear). [Wortman, 1977a] Wortman, David B., Steven D. Duket, and Deborah J. Siefert, Modeling and analysis using SAINT: a combined discrete/continuousnetwork simulationlanguage,In Proceedings of the 1977 WinterSimulation Conference, Harold J. Highland, Robert G. Sargent, J. William Schmidt,Eds., 1977, pp. 528-534. [Wortman, 1977b] Wortman, David B., Steven D. Duket, R.L Hann, G.P. Chubb, and Deborah J. Siefert, Simulation Using SAINT:A User-OrientedInstructionManual, AMRL-TR-77-61,AerospaceMedical ResearchLaboratory,Wright-Patterson Air Force Base, Ohio, 1977. [Wortman, 1977c] Wortman,David B., Steven D. Duket, R.L. l-lann,G.P. Chubb, and Deborah J. Siefert, The SAINT User's Manual, AMRL-TR-77-62,AerospaceMedical ResearchLaboratory,Wright-PattersonAir Force Base, Ohio, 1977. [Young, 1963] Young, Karen, A User's Experience with Three Simulation Languages (GPSS, SIMSCRIPT,and SIMPAC), System DevelopmentCorporation,Report #TM-1755/000/00, 1963.
T R A N S C R I P T OF PRESENTATION DICK NANCE: I ' m going to stand a little closer to the projector and carry you through a number of slides fairly rapidly. I encourage you to read the paper, since obviously I am not covering anywhere near the extent of the material that's provided in the paper. I ' m skating, and pulling material that appears to me to be perhaps the most interesting to you. (SLIDE 1) I'll talk about the technical background very briefly, give you some idea o f the historical perspective, the organization of the talk, and how periods arose as a way of organizing the material here. In other words, I've taken a horizontal cut in time, in talking about all simulation languages during that horizontal period. The reason for it is that they went through a number of very similar experiences, and then there will be selected language sketches; I cannot talk about all the languages. I will pick and choose just a few, and then give a concluding summary. (SLIDE 2) In terms of simulation, I think the term is often associated with three different forms: discrete event simulation portrays state changes at particular points in time, continuous simulation is typically thought o f as state equations for solutions of differential equations or equational models, and Monte Carlo simulation, which is a sequence of repetitive trials in which you have a very simple state representation, nothing like the complexity you can have in a discrete event model. And then there are, as I have shown across the bottom, three sorts of different forms based on how you view the relationship with the three above. A hybrid model will fall within a discrete event simulation model, typically. Combined simulation deals with combined discrete event and continuous modeling, and then gaming is an area where simulation is very crucial, but there are other factors too that need
Simulation Taxonomy and Terminology
Presentation Outline • Technical Background • Historical Perspective and Organization
• Discrete Event: State changes at precise points in simulated time. • Continuous:
• Periods of Partitioning t3 General Description 0 Selected Language Sketches • Concluding Summary
Equational models without explicit time and stale relationships • Monte Carlo: Repetitive trials (simple state representation) Q Hybrid
SLIDE
1
DISCRETE EVENT SIMULATIONLANGUAGESESSION
: ] Combined
D Gaming
SLIDE 2
413
RICHARD E. NANCE
Language Perspectives for Di~rete Event Simulation (DES) (1) Requirements for a DES language
Requirements for a DES Language (1) Random number generation (2) Process transformers U (0, 1) ~ G ( __, __ )
(2) Language forms (3) Conceptual framework~
(3) 1.ist processing capability (4) Statistical analysis of output (5) Report generation (6) Timing executive (time flow mechanism)
SLIDE 3
SLIDE
4
to be considered. In the red or magenta, are shown the two forms that I will concentrate on, both here and in the paper, the discrete event and the combined. (SLIDE 3) There are three different perspectives that I advance in the paper for looking at discrete event simulation and languages for discrete event simulation: the requirements for a language, the different forms for a language, and then something that is very important to people working in the field of discrete event simulation, the conceptual framework that a language supports. (SLIDE 4) Each simulation language must meet these six requirements: a means of random number generation, some way of transforming the random numbers (from the U(0,1) to a more general set of distributions), a capability for list processing (creating, deleting, and manipulating objects), a basis for statistical analysis of output, some means of report generation (so that behavior can be characterized), and then a timing executive or a time-flow mechanism. (SLIDE 5) In terms of language forms, we find simulation packages being a very predominant form. Now I know that a language purist doesn't view a package as a language p e r se, but I had to include them here, because they have had such a major effect historically. GSP, the general simulation program, GASP, the general activities simulation program, and the Control and Simulation Lang u a g e - t h r e e packages from the very early days that, in fact, have influenced--and continue to influence---languages today. Pre-processors are another form, and two of the current languages, SLAM, Simulation Language for Alternative Modeling and SIMAN simulation analysis language, represent preprocessors. Then the more typical programming languages themselves, GPSS (was represented at the first conference by Geoffrey Gordon), Simscfipt II from the Rand Corporation--Phil Kiviat and Harry Markowitz--you've already heard Harry Markowitz mentioned; you'll hear Phil Kiviat mentioned a great deal. And in fact, at this point, let me say, that I am in debt to Phil Kiviat for his help in preparing both the paper and the presentation. Phil is a tremendous resource and a great individual to work with. And then SIMULA, which needs no introduction--you've already heard several people in the conference and preceding speakers discuss the effect SIMULA has had in areas like LISP, and Per Brinch Hansen noted its effect in operating systems and Concurrent Pascal. (SLIDE 6) To explain conceptual frameworks, this third perspective, let me start with a very simple example of a type of model that is used in discrete event simulation, a single server queuing m o d e l R i f you like to think in applications, think of a single barber in a barber shop. In such a model, you will have a process model of jobs or customers arriving and a queue formed if the server is busy. You will have a first-come first-served order to the service, and a server idle if that queue is empty. The objective
414
CHAPTER VIII
TRANSCRIPT OF SIMULATION PRESENTATION
Language Forms
Conceptual Frameworks Time and state characterization: single-server queue model
• Simulation packages:
GSP (Tocher), GASP (Kiviat), CSL (Buxton and Lash) *
Prepcocessof~:
SLAM 0a*ritsker), S1MAN (Pegden)
~2 'I'bJ I
• Simulation Programming Languages (SPLs): GPSS (Gordon), SIMSCRIPT II (Kiviat and Markowitz), SIMULA (Dahl and Nygam'd)
~
I
I
I
I
I
.1¢£,2
Jibl
Jab2
Jeb3
I
I
I
I
I
I
Jabl Al~rl~
SLIDE
I----
•
AnON C,m:qptW~CmnmpM~ Arrl~
5
SLIDE
Tl/l~
6
there may be to compute the job wait versus the server idle time, because they represent costs that you are trying to balance. Now, the views that are exemplified by the time and state characterizations of such a model, might be when events occur, when jobs arrive, or when services end. (SLIDE 7) This has been characterized by Mike Overstreet as temporal locality and the US refers to where it geographically was considered the way to describe a system: in this case, the United States. Event scheduling or next event languages were typical of the US view of how to do simulation modeling. Activity duration, where you concentrated on the state of the simulation over some period of time, was more popular in the United Kingdom--there you might look at the state of a model, of a job waiting, or a job in service, for the period where the server is idle. The third framework, the object existence, the encapsulation here of locality of object as Overstreet characterized it, in contrast with locality of state or locality of time. You look at all that occurs with respect to the job; its entire experience as it goes through a system, as we have described above. (SLIDE 8) Now, the event scheduling conceptual framework focused on the epochs marking state change. What happens or what are the consequences of a job arriving? Well, I have to describe them as "what is the next thing that will happen to this j o b - i t will be served if the server is available?" But, you notice here, there are points in time which are pulled out for emphasis in the description;
Conceptual Frameworks (Alternative Characterization)
Conceptual Frameworks
Time and state characterization: event scheduling Framework
Technical (Locality)
Event Scheduling
Geographical
Tcmporal
U.S.
Activity Scml Precess Interaction
State (Machine)
ILK.
Object
Europe
Pl:
Tcrap°raw Object (Material)
Transaction
[
SLIDE
I----- I
s*2 ~*
I I
I
I I
I
I
I
Job2 Jab3 Arrl~q~ Arrl~ C~iFh¢,~CempMet Ar~ Jd~l
U.S.
Jd~2
Jabl
"rim*
Zp*duMmta~ 7
DISCRETE EVENT SIMULATION LANGUAGE SESSION
SLIDE
8
415
RICHARD E. NANCE
Conceptual Frameworks
Conceptual F r a m e w o r k s
Time and state characterization: activity scan
Time and state characterization: process interaction (transaction)
~'
I I-----I
I I Jabl Anl~
I
I
I
Jab3 Artl~
,.lilb t Cimpl=te
Jab2 CCml~lll~
I
I
I
SLIDE
I----
~l
I I
I
~.b=
I
9
I
I
"rhm
i
Tempwxry Object:
I
I
I
I
I
I
I
Jdbl An'l~
Jr62 Affl~
$ebl CGmpk~
Jtdb2 Cl~lM~
Jeb3 Ard~
I Jeb3 /ord~
I
{I
|d,t
I Jeb2
P---I
I
I Id'~ I
SLIDE 10
those points in time relate to the job, very obviously, but also to something not so obviously and that is the server. (SLIDE 9) The activity-scan or class of languages concentrated on state, and described the state duration for the separation of the two events that either initiated or terminated the two state activities: job one arrives, and job one completes, but in between that time, job two arrives and must wait until the server is available. (SLIDE 10) Now in the process interaction, the third form described as locality of object, we really have two subforms--the first process interaction or transaction view, as it was characterized in GPSS, was that you looked at the temporary objects, the customers or jobs, as they came into the system--you focused on what happened to that job. But behind the scenes, was the server, the permanent object, which is not well characterized. (SLIDE 11) In fact, the problem, or the difference between the transaction view and the more traditional process interaction view, is the explicit representation of the server as a process as well as jobs as processes. Now you're characterizing what's happening with the server and jobs, and the points where they interact. (SLIDE 12) What are some of the influences and consequences we see for having these differing conceptual frameworks that underlay the whole development of simulation languages? Well, the conceptual frameworks sort of created conceptual communities in and of themselves, and as we heard our friends talk about LISP, these communities were equally isolated--they didn't talk to each other much. Phil Kiviat characterized this, in his Rand Report of 1967, as an inversion of theory and interpretation. Where the language should be an interpretation of the theory, it became the theory, and so people working in SIMULA didn't talk to people working in SIMSCRIPT II. On the other hand, there was knowledge of the work going on, in many cases. I would say that the people working on the languages had far more knowledge of the other language forms than the people actually using the languages. There were differences because of application domains, and the frameworks themselves were at least stimulated by the application domains. And then there was a contrast in educational and industrial desires and constraints. Many simulation languages were developed because of a desire to use them in an educational setting. They had very different constraints and very different objectives from those developed to use in a business or industrial setting. The consequence, of course, is that we ended up with numerous simulation languages--however you wish to define "language." In 1966-.-1967, two reviews at that time identified 21 different discrete event simulation languages--that does not include the continuous (simulation) languages. In 1981,
416
CHAPTER VIII
TRANSCRIPT OF SIMULATION PRESENTATION
ConeeptmdFrameworks Timeandstatecharacterization:proccssinteraction I ~'J I ~'=
I
I
I
I-----
~,
I I Jdbl Ard~
Priam C / l a ¢ l l
~s~.~.i=,*.:
I-- I
I
i
I I ~kb2 Anlvw
~
I
I
dl~bl
Jeb3 CaxqFtau
.nip2
I-'---- I
~
I
I J*b~ Am,~
• Differingconceptualframeworks • Applicationdomaindependentperspectives • Contrastin educationaland industrialdesires~constraints {Consequences}'~VNumeroussimulation"languages" 1) 21 [Teichroewand Lubin,1966;Krasnow,1967] 2) 137 [Crookes,1981]
I 'I'3 |
I-----I SLIDE
Tt~
lnfluencers and Consequences
I
11
SLIDE 12
John Crooks said that he could count 137 different simulation programming languages (SPLs). If the estimate of a thousand programming langauges is correct, then SPLs number over 10 p e r c e n t - - t h a t ' s a very healthy number. Now, I ' m sure that many o f these are dead, and some of those that aren't perhaps should be. (SLIDE 13) When I started preparing for this talk, I thought about different ways I could present the material. I could talk about, for instance, the different languages within a framework family. What were the activity scan languages? What were the event scheduling languages,etc. (SLIDE 14) I could also talk about a genealogy of a particular language following GPSS or S I M U L A or S I M S C R I P T and follow it through its rather interesting history o f spinning off and creating others. (SLIDE 15) But I chose a different way, I chose probably a horizontal perspective, where I cut across in periods of time and I did that because there are very interesting similarities that occur in all the languages during that period of time. I think it is interesting to ask why do they occur? What is driving that? (SLIDE 16) So there are the five periods that I will talk about. (SLIDE 17) The period o f search. That was the period prior to the existence o f any simulation language, per se, from roughly 1955 to 1960. There were new general purpose languages appearing in that period o f time, and there were some simulation models that were done in assembly language
lthtoHcalOrllnuizallon:Cmeeptnnl
HistoricalOrganization:VerticalDevelopmentby MajorLanguage
@ • Advantages: 13Evolution~"conceptin comparisons,and Q Contrastsin implementation • Disadvantage: 13ilistoricalinversion SLIDE 13 DISCRETE EVENT SIMULATION LANGUAGE SESSION
• Advantages: I;3"Natural"genealogicalapproach 171Clearpictureof languagefamily • Disadvantage: 13Nopictureof inter-family relationships
l GpssII r-G~* ~ Ill
SLIDE 14 417
RICHARD E. NANCE
Historical Organization: HorizontalDevelopment by Period '"
,.
I
_I__I
1
r
I_
• Advantage.e: ~3Clearpictureof inter-familyrelationships 13Strikingsimilarities • Disadvantages: ~3 Less than "natural"
Periods of Partitioning
• The Periodof Search(1955-1960) • TheAdvent(1961-1965) • The FormativePeriod ( 1966-1970) • The ExpansionPeriod(1971-1978) • Consolidationand Regeneration( 1979-1986)
Q More difficult, even argumentative
SLIDE 15
SLIDE 16
and the new general purpose languages. General Electric was one place, and the study o f scheduling rules by Jackson, Nelson, and R o w e at U C L A around the 1958 or 1959 time period. Then, around 1958, Tocher and O w e n in the U K published a paper on the General Simulation Program. ( S L I D E 18) T h e General Simulation Program was essentially a search for a simulation structure. K.D. Tocher realized w h e n he did p r o g r a m m i n g o f a simulation m o d e l he repeatedly did several things. H e d e v e l o p e d an initialization f o r m or an initialization routine. H e d e v e l o p e d the description o f what he called state-based activities or events and time-based events. T h e n he also had a report generator. So what he began to do, as every p r o g r a m m e r does, is to create his set o f routines which he reuses as he p r o g r a m s later simulation models. This b e c a m e known as the General Simulation Program. ( S L I D E 19) W h e n w e m o v e into The A d v e n t (of real languages), we find s o m e interesting things, at least I find them interesting, for today. For instance, this continuing legacy. All the m a j o r simulation p r o g r a m m i n g languages o f today can trace their roots back to the languages d e v e l o p e d in the period o f 1960 to 1965. With Control and Simulation Language, it was an activity scan language, a F O R T R A N preprocessor and graphical input was provided for. O n e drew a picture o f the model. G A S P was an event scheduling language, also a F O R T R A N package, and again a graphical interface was provided. G P S S was a process interaction, transaction language, interpretive in terms o f its
The Period of Search (1955-1960)
418
General SimulationProgram
• Programmingin assemblylanguages • Appearanceof new generalpurposelanguages(GPLs), e.g., FORTRAN • Specificmodelsin GPLs ra GeneralElectric U,UCI.A: Jackson,Nelson,Rowe • GeneralSimulationProgram(GSP): K.D.Tocher,D.G. Owen(1958)
• Purpose:"Searchingfor a simulationstructure" • Programorganization LIInitialization(Parametersfor processtransformers, termination) Q C Activities(Contingent: state-basedevents) B Activities(Bound: time-basedevents) [3 ReportGeneration(Couldbe "C" or "B" activity) t3 Subroutine(s)
SLIDE 17
SLIDE 18
CHAPTER VIII
TRANSCRIPT OF SIMULATION PRESENTATION
The Advent (1960-1965)
• ContinuingLegacy CSL:AS,FORIRANPrepfoc~sot,Graphical Q GASP:ES,FORTRANPackage,Graphical t3 GPSS:PI/T,Interpreter,Graphical t3 SIMSCRIPT: ES,FORTRANPreprocessor,Textual ~1 SIMULA: Pl, ALGOLExtension,Textual • Others:DYNAMO,OPS-3
SLIDE
19
SPL Sketches
• Creator(s),Developer(s) • Organization(s)
• • • •
Contributors Predecessors/Influencers LevelofEffort DistinctiveCharacteristics/Points
SLIDE
20
translation and was also graphical. SIMSCRIPT, event scheduling, again a FORTRAN preprocessor and textual in nature, no graphical interface. SIMULA, the process interaction ALGOL extension, is textual. There were others: DYNAMO and OPS-3. You might ask why are you including DYNAMO? DYNAMO was not a discrete event simulation language. That's true. But according to the persons who have contributed so much to the development of languages that are discrete event, they go back to claim many interesting influences, many interesting discussions with the developers of DYNAMO, and also, that they watched very carefully what was happening at MIT during the period of DYNAMO's development. (SLIDE 20) In trying to provide a language sketch, I both apologize and ask your understanding about the brevity of the sketches. I'll try to identify the creators or developers of each language that I include, the organization or organizations here, contributors to the language, the predecessors or influencers, that is, preceding language or language versions. In some cases information about the level of effort is included, although it is not easy to pull that out. And then, any distinctive characteristics or points about the language. (SLIDE 21) Control and Simulation Language (CSL), originating in 1962, John B uxton and John Laski were the developers. It was a joint development of Esso Petroleum and IBM UK. They cite Tocber and Hartley in Cambridge and Cromar of IBM as persons influential on them in the development of the language. The predecessors include Tocher's GSE Montecode, and FORTRAN Montecode being a simulation model that was developed in the 1960 time frame. CSL eventually became a compiled language, taking about nine staff-months in the development of the language. I could find no indication of how much effort was devoted to design. The second version of the language in 1965, called by some, C.S.L.2, provided dynamic checking of array subscripts, which I thought was an interesting capability at that point in time. (SLIDE 22) GASE the General Activity Simulation Program, began in 1961 with Philip Kiviat's arrival at US Steel. It was basically a one-person effort although Belkin and Rao authored the GASP Users Manual, we think around 1965. It was done as a FORTRAN or FORTRAN package and had a lot of influence from the steel-making application domain. It took approximately 12 staff-months for both design and code, and was viewed principally as a problem-solving tool, not really a language for doing simulation. For instance, it had a regression model of input that was very capable for that period of time. It indicated an understanding of dependencies in the input stream, which you don't find in other languages of that period.
DISCRETE EVENT SIMULATION LANGUAGE SESSION
419
RICHARD E. NANCE
C S L : Control end SimulaUon L a n g u a g e
G A S P : General Activity Simulation P r o g r a m
• John N. Buxtoa and John G. Laski (1962)
• Philip J. Kiviat
• Jointly: Esso PetrolEum + IBM U.K.
• United States StEel
• K.D. Tocher, D.F. Hartley (Cambridge), l.J. Cromer (IBM)
• JackBelkin andM.R. R a o ( G A S P U s e r ' s M a n u a l , 1965.9)
• GSP, Montecode, FORTRAN
• FORTRAN, Application domain
• Compiler:. 9 staff-months; Design : ?
• Approximately 12 staff months: Design + Code
• Second version (1965), ~ C.S.L. 2 - - Dynamic checking
• Problem-solving focus, regression model of input
SLIDE
21
SLIDE
22
(SLIDE 23) GPSS is described in detail in HOPL I, so I include it here only for completeness. (SLIDE 24) SIMSCRIPT, whose conceptual father was Harry Markowitz, a Nobel Laureate in Economics, was based on the entity, attribute, and set discriptors. Much of what is later included in the entity-relationship model is found in SIMSCRIPT. (SLIDE 25) SIMULA, Dahl and Nygaard, 1961--and as those of you who have read the proceedings from HOPL I know, this has had a major influence on simulation programming languages, general purposes languages, and computer science. I would like to say that if there is any question about it, as far as I am concerned and I think I could defend this--SIMULA w a s the first and is the first object-oriented language. It was developed at the Norwegian Computing Center. Jan Garwick, the father of Norwegian computing, is identified as a major influence. SIMSCRIPT and ALGOL, of course, were mutual influencers in their own right. Bernard Hausner, who was one of the early developers of SIMSCRIPT 1.5--in fact, he was the chief programmer--actually joined the team in 1963 at the Norwegian Computing Center. As the report in the 1981 HOPL proceedings indicate, Dahl and Nygard suddenly discovered the event scheduling view of the world that they had never even thought about. You notice the effort here is considerable, 68 staff-months, and this was just for SIMULA I. Key here are the process and code routine concepts. You immediately say, "what about the inheritance, what about class?" That really came with SIMULA 67 about four years later.
SIMSCRIPT
G P S S : General P u r p e s e System Simulation
• Geoffrey Gordon (1960)
• Harry Markowitz, Bernard Hausner, HErbert Karr
• IBM
• U.S. Air Force Project RAND
• R. Barbieri, R. Efron
• R. Conway(Cornell)
• Sequence Diagram Simulator (D.L. DietmeyEr), Gordon Smiulator • ApproximatEly 24 staff-months
• GEMS (Morton Allen), SPS-I (Jack Little) • Approximately 36 staff-months • Entity/Attribute/Set Description
• Block diagram, Interpreter, GPSS II, GPSS 111
SLIDE
420
23
SLIDE
24
CHAPTER VIII
TRANSCRIPT OF SIMULATION PRESENTATION
oPS-3: On-Line Programming System (Process Synthesizer)
SIMULA
* Ole-Johaa Dalai and Kristen Nygaard (1961) •
NorwegianComputingCenter
• M. Greenberger, M.M. Jones, J.H. Morris, Jr., D.N. Ness
and
• Jan V. Garwick
• Sloan School of Management, M IT
• S1MSCRIPT, ALGOL
• M. Wantman, G.A. Gorry, S. Whitelaw, J. Miller
• Approximately 68 staff-months
• CTSS, OPS
• Process and co-routine concepts
•
Unknown
• System, not simply a SPL: Interactive
SLIDE
25
SLIDE
26
(SLIDE 26) OPS-3, a very interesting language, not because of the influence it had, but because of what it set as goals for the future. OPS-3, developed at MIT, Martin Greenburger and Mal Jones, major influences there, at the Sloan School of Management. I always found it referred to as the "On-Line Programming System," however, Jean Sammet in her book in 1969 indicated that it was actually the "On-Line Process Synthesizer" and that is why I have shown that title in parentheses. Using CTSS, the creators of OPS-3 showed us what a language and a capability for simulation could look like in a kind of time-sharing domain that few had at their disposal at that time. I cannot say much about the level of effort. The distinctive point here is that OPS-3 was considered a system not a language. It was a system for doing interactive development and model execution. As such, it really pushed into a domain that sort of defined a path or identified a path. (SLIDE 27) To summarize: In the period of the advent, there were numerous simulation programming languages other than the ones that I have sketched--SIMPAC at SDC, Simulation Oriented Language, that Knuth and McNeley created. There were also several interesting comparison papers; I note seven papers during that period of 1963 to 1967. People were interested in what others were doing; what alternatives were being taken--I think in part because the simulation language and simulation modeling was such an intensive effort, both in development and in execution. There were many workshops, and Dan Teichrow--at Case at the time, and John Lubin at Pennsylvania were called by Kiviat "the honest brokers," the people who did not have vested interests in language but kept trying to move along the whole technology of language development. There was an IBM symposium in 1964 on simulation models and gaming. Tocher and Geoff Gordon spoke at that. There were several conferences. The 1967 IFIP Working Conference on SPLs, Doug Ross was at least one person there. There could be others here that attended that conference. It read like a "who's who" of personages in computer science. Tony Hoare was there. An interesting anecdote from this conference asked what were the plans for SOL. Knuth said, "We have no plans for SOL, I found everything save the wait-on-state condition that is provided in SOL provided in SIMULA, and I would encourage you to go to SIMULA." In 1967, there also was the conference entitled Applications of Simulation Using GPSS that later expanded into Simulation Applications and then finally the Winter Simulation Conference, that's what WSC stands for. And today it remains as the premier conference for discrete event simulation. (SLIDE 28) During the next period, which I have called the Formative Period, we find all the languages beginning to really focus on their concepts--to revise and refine these concepts and set forth what really distinguished that language from others. The Extended Control and Simulation
DISCRETE EVENT SIMULATION LANGUAGE SESSION
421
RICHARD E. NANCE
The
The Advent (1960-1965)
• NumerousSPLs:SIMPAC(SDC);SOL(Knuth& McNeley) • LanguageComparisons:Sevenpapers(1963-1967) • ConferencesandWorkshops 121Worksholx~(1964-1966):D. Teichroew,J. l.ubin O Symposia:IBM-- SimulationModelsandGaming(1964) LIConferences: IFIPWorkingConferenceonSPLs(22-26May 1967) ApplicationsofSimulationUsingGPSS(November196'7) wsc
FormativePeriod (1966-1970)
• ConceptExtraction,Revision.Refinement O ECSL(Clemeutson): FORTRANabandoned CAPS(ComputerAidedProgrammingSystem) CiGASP11(lh-itskerandKiviat): Target ~ Smallcomputers Q GPSS/360and GPSSV: Expandedset operations Externalaccess(HELP) Free-formatcoding
SLIDE 27
SLIDE 28
Language (ECSL), now Allen Clementson became the major mover and FORTRAN was abandoned. A front end, which was called the Computer Aided Programming System (CAPS), was added. GASP II by Alan Pritsker and Phil Kiviat--really Alan Pritsker--becoming the mover and its target was simulation capability on small computers. GPSS-360 and then GPSS-V expanded the set operations, provided the external access to other languages through HELP, and then provided free-format coding. (SLIDE 29) In concept extraction, revision, and refinement, we see that SIMULA now includes the object and class concept and the virtual concept. SIMSCRIPT II comes into being and OPS-4 provides a PL1 based language with all three world views. (SLIDE 30) During this period, no language had really more effect than SIMSCRIPT. SIMSCRIPT II by Kiviat, Markowitz, and Villanueva at RAND became a prime competitor with GPSS. It took approximately 150 staff-months. It was interesting in that it had five different levels and an Englishlike forgiving compiler. (SLIDE 31) Other languages, the Burroughs Operational System Simulator (BOSS), Q-GERT, a network modeling language proposed by Pritsker, and SIMPL/I, a language from IBM based on PI.,/I. (SLIDE 32) During 1971 to 1978 we find the period of extensions and enhancements (Period of Expansion). Now languages previously described in terms to distinguish them began to effect a blurring of these distinctions. GASP from Pritsker emerged as GASP IV in 1974, which had the capability for doing combined discrete event/continuous modeling, and then also provided a process
SIMSCRIPTII
The Formative Period (1966-1970)
• ConceptExtraction,Revision,Refinement SIMULA67 Object/classconcepts Virtualconcept o SIMSCRIPTII Q OPS-4
PL/Ibased Threeworldviews
SLIDE 29 422
• • • • • •
P.J.Kiviat,H. Markowitz,R. Villanueva RAND G. Benedict,B. Haussner,J. Urman(IBM) SIMSCRIPT1.5 Approximately150staff-months Levels1-5,English-like,"Forgiving"compiler
SLIDE 30 CHAPTER VIII
TRANSCRIPT OF SIMULATION PRESENTATION
T h e Formative Period (1966-1970)
The Expansion Period (1971-1978) • Extensions and Enhancements
• Other Languages 13 BOSS: Burroughs Operational System Simulator (1967) A.J. Meyerhoff, P.F. Roth, P.E. Sharer 13 Q - G E R T - - Network-modeling (1970) A.A.B. Pritsker 13 SIMPL/I: IBM, Based on PL/I (1967) N. Cooper, K. Blake, U. Gross
SLIDE
171GASP (Pritsker) GASP IV (1974): Combined capability, PI GASP_PL/I 13 GPSS NGPSS and/NORDEN: J. Reitman (1971-73) Interactive, Animation (erude) Numerous versions: GPSS V/6000, GPDS, GPSS 1100, GPSS/UCC GPSS-H: Compiled version
31
SLIDE
32
interaction--that is, GASP provided a vehicle to look much like GPSS in terms of its view of the world. GPSS took a different form in the Norden GPSS and GPSS/NORDEN versions, Julian Reitman being a major mover here. It actually had interactive capability, and provided some basis for rather crude animation to look at the output. Then there were other versions of GPSS. (SLIDE 33) During this period, SIMSCRIPT 11.5 develops a combined view for discrete event/continuous models and also adopts a transaction view like GPSS. And then extensions for computer system modeling emerge. SIMULA 67 really moves away from the machine and toward the user with this idea of a pure system description language called Delta. (SLIDE 34) Then ECSL moves into program generators. Program generators are an interesting concept--they actually began at RAND in 1965, but interactive generators in the UK became the major means of creating models. They were based on the original Tocher Wheel Charts, but became well known as activity or entity cycle diagrams. They were not intended to provide a complete model description but a draft. And, in fact, that is what Mathenson at Imperial College called his generator DRAFT of a model that can then be transformed into different implementation forms. (SLIDE 35) This is just one example of a single server queue shown as an entity cycle diagram, where you see jobs arriving from the world, going into a queue, then meeting the server in the period of service, and then going back to the world. This became a way of describing a model. It could be automatically translated into a draft or outline of an executable program.
Program Generators
The Expansion Period (1971-1978)
• Extensions and Enhancements O SIMSCRIPT II.5 Combined - - C-SIMSCRIPT (C.M. Delfosse) Transaction View - - Limited Pl concept Computer system modeling: ECSS (Kosy 1975) and CSP II (lwata 1975) t.I SIMUI.A 67 Pure system dc.seription language: DELTA O ECSL Program Generators
SLIDE
Initiated with Programmingby Questionnaire (FBQ) E~ A. Ginsberg, H. Markowitz, P. Oldfathcr (1965-1966) at RAND O Job shop model for batch cxccullon Interactivegenerators in U.K. (1972-1977) O Based on Tocher's Wheel Chain: { ¢l!yhy ! Cycle Diag...... ~nncy J Q Provided a "draft" to be completed CAPS-ECSL (Clemcntson, Birmingham)
{ FORTRAN'~ DRAFT
33
DISCRETE EVENT SIMULATION LANGUAGE SESSION
GASP SIMON l ' i SIMULA 3
SLIDE
(Math©wson,hnp¢rial CColl©ge)
34
423
RICHARD E. NANCE
Program Generators • Activity Cycle Diagram
The Expansion Period (1971-1978) • Interactive Simulation Languages ~3 CML: Conversational Modeling Language R.B. Fetter, R.E. Mills of Yale (mid 1970s?) GFL capabilities
N (IPU 3I' *~ ~ SLIDE
CONSIM: CONvcrsationalSIMulation S. Sheppard [Nelson], Pittsburgh SIMULA 67 design
35
SLIDE
36
(SLIDE 36) We also had interactive simulation languages, the Conversational Modeling Language from Yale and the Conversational Simulation Language by Sallie Sheppard at Pittsburgh based on SIMULA 67. (SLIDE 37) Other simulation languages were created; I have identified some of them here. You notice that SIMPL is a descendent of OPS-4. SIML/I, by MacDougall was primarily for computer system modeling. Then there was a family of languages introduced by Pritsker Corporation or Pritsker and Associates that included the GERTS language and the SAINT languages--Systems Analysis for Integrated Systems of Tasks (I think that is what SAINT stood for). (SLIDE 38) In '79 to '86 we had the period that I called the Consolidation and Regeneration. Now we have different versions of GPSS appearing on personal computers; we have a GPSS FORTRAN in Germany, and we have a GPSS/APL. Did you know that there was such a beast? We had different application domain dialects being developed for SIMSCRIPT II.5, SIMFACTORY II.5, NETWORK II.5, and COMNET II.5. There is even a LanNet II.5. Then with SIMULA 67, we have an extension DEMOS that makes it look again like GPSS, in that it takes a transaction world view which is viewed as a much simpler approach for teaching. (SLIDE 39) In terms of regeneration we find two languages, SLAM and SIMAN. Of interest here is that the people creating these two languages worked together, and then worked separately and you
The Expansion Period (1971-1978)
Consolidation and Regeneration (1979-1986)
• OtherSPLs
SM I P:]/.I
t.l The PldI Branch Announced in 1972 PL/I Prepfoceuor with GPSS "flavor" r ~ SIMPLfl X or PL/I GPSS SIMPL: (M.M.Jones. R.C.Thurbcr) Descendaad of OPS-4 Implemented o n MULTICS SIML/I: (M.H. MaeDougall): Computer System Modeling Pl (SOl. influence) rt The Pritsker Family GERTS: Network modeling -- FORTRAN SAINT: Combined modeling FORTRANIV (U.S. Air Force)
SLIDE 37
424
• Consolidation
/
[3 Versions of GPSS ~ / t3 Application domains _ _ for SIMSCRIPT 11.5 ~
Personal computer FORTRAN APL SIMFACTORY II.5 NETWORK 11.5 COMNET 11.5
r~ DEMOS: transaction world view in SIMULA 67
SLIDE
38
CHAPTER VIII
TRANSCRIPT OF SIMULATION PRESENTATION
SLAM and SLAMII
Con~lidation and Regeneration (1979-1986)
• Regeneration ClSLAM(PritskerCorlx~ration): SimulationLanguge for AlternativeModeling SLAM(1979)and SLAMII (1983) t3 SIMAN(SystemsModelingCorlx~ation):SIMulation ANalysis Initialidea: 1979 Released:1983 ElLitigation SLIDE 39
• • • • • •
A.A.B.Pritskerand C.D.Pegden PritskerandAssociates,Inc. J. Sabuda,W. Wa~ham GASP,Q-GERT,SAINT EffortthroughGASPevolution(graduatestudents) FORTRANpreprocessor,Graphical,Multipleworld views,Combinedsimulation
SLIDE 40
notice the third bullet. You can read in the paper what is said about the result of the court suit between S I M A N and SLAM. ( S L I D E 40) S L A M developed by Prisker and Pegden, was a natural evolution of GASP. It b e c a m e a preprocessor though, as opposed to a language package. It consolidated a lot of things developed by Prisker's graduate students. It still is a F O R T R A N preprocessor, using a graphical input, and providing multiple world views and c o m b i n e d simulation. (SLIDE 41) Pegden's S I M A N , was a faculty project at Penn S t a t e - - r e a l l y a single person effort that took approximately 24 staff-months over a four-year period. It drew from a lot of different languages but I would have to say notably from S L A M since Pegden was a codeveloper there. It was the first major simulation p r o g r a m m i n g language on a PC. It showed the PC as a viable platform. It had m a n u f a c t u r i n g applications features and provided a C I N E M A animation report capability. (SLIDE 42) In conclusion I find that simulation p r o g r a m m i n g language history is characterized by a n u m b e r of things. First o f all, a large n u m b e r o f languages---4ong lived major languages, those that have been with us for thirty y e a r s - - a n d very spirited commercial competition. Pick up a copy o f Industrial Engineering and note the n u m b e r of advertisements for simulation software. In part, this spirited competition contributed to the similarities in SPL development during the recognized periods used for organizational division. While the advent of a new general purpose language, such as Pascal or C, typically led to simulation packages in that language, a mutual
SIMAN • C. DennisPegden(1979-1983)
• • • • •
Facultyproject(PennState) Singleperson GPSS,SIMSCRIPT,SLAM,GASP,Q-GERT Approximately24 staff-months(overfour-yearperiod) FORTRANpreprocessor,Graphical,Multipleworld views.Combinedsimulation,CINEMAanimation
SLIDE 41 DISCRETE EVENT SIMULATION LANGUAGE SESSION
Concluding Summary
• SPL historycharacterizedby 1:3Largenumberof languages t.,Il,oug-livedmajorlanguages ~3Spiritedcommercialcompetition ~3Pc'riodsof comparativelysimilardevelopment t3 Progressivemutualdisinterest (Simulation,:::.Programminglanguages)
SLIDE 42 425
TRANSCRIPT OF QUESTION AND ANSWER SESSION
indifference has characterized the relations between the two language communities. Hopefully the recognition of programming as a form of modeling and the evolution of model development environments will produce a more symbiotic relationship.
TRANSCRIPT OF QUESTION AND ANSWER SESSION HERBERT KLAEREN (Univ. of Tubingen): It seems to me that your six requirements for a discrete event simulation language can be fulfilled using a library for any general purpose programming language. What are the drawbacks of the "library approach" that justify the development of dedicated simulation languages? NANCE: Perhaps my paper makes it clearer than the presentation that packages in GPLs have always been major contributors, and my conjecture is that, during the period covered (1955-1986) more simulation models have been developed in GPLs than in SPLs. However, there are major advantages to using an SPL: (1) statistics collection can be made much simpler for the user, (2) the user interface can accommodate nonprogrammers more readily, and (3) application domain knowledge can be incorporated, or the provisions made for doing so, with less difficulty. R o s s HAMILTON (Univ. of Warwick): Your categorization of periods in the development of simulation languages seems to infer that they have "evolved" and that they have now completed their evolution. Would you please care to comment on this? NANCE: That inference is certainly not intended. However, my perhaps biased (by my own research interests) view is that current emphasis is on model specification at a more abstract level, with transformation to an execution specification that remains hidden from the user. This emphasis follows the "automation based paradigm" of [Balzer 1983], and attempts to move the model development responsibility to users more expert in the application domain that are not programmers. Nevertheless, problems remain that motivate new implementation concepts, and specification techniques will be offered commercially that are tied to existing SPLs or their progeny. As I note in my paper, developments after 1986 are so recent as to defy a historical perspective. CHARLES LINDSEY (U. of Manchester): Has there been any standardization activity in the field (ANSI or ISO), and would such be desirable? NANCE: Yes, there is a standard for Simula67, and those standards activities are well managed from what I see. GPSS/H and Simscript II.5 are proprietary and have active user groups. For other SPLs, whether increased standardization would be welcomed and by whom is not clear. JAN RUNE HOLMEVIK (Univ. of Trondheim): Do you see any difficulties in explaining historical developments genealogically, like in Figure 8. ! on page 373 of your paper? NANCE: First, I would not characterize the genealogical tree as an "explanation" of historical developments. The tree shows chronological relationships that furnish a perspective on a large body of work. Clearly, an understanding of historical developments requires far more in the way of textual and graphical material; else, I might have supplied you with a paper containing a single figure. TOM MARLOWE (Seton Hall Univ.): Does the move to make symbolic languages work in a standard interface/environment, such as Windows, address your concerns about language extension in any way (at least as far as the issues of familiarity and "front-end")?
426
CHAPTER VIII
BIOGRAPHY OF RICHARD E. NANCE
NANCE: Most definitely, and my colleague Osman Balci and I have been working for the last ten years on research in model development environments. Specification of model behavior must be done at a higher level of abstraction than the implementation level. Further, our expectations are producing models far larger and more complex than we can hope to deal with successfully unless we can call upon automated support for diagnosis of specifications for correctness, component reuse at both design and program levels, etc. You might wish to examine a summary paper that describes this work [Balci 1992].
REFERENCES (for Questions and Answers) [Balci, 1992] Baici, Osman and Richard E. Nance, The simulation model developmentenvironment: An overview,In Proceedings of the 1992 WinterSimulation Conference,JamesJ. Swain, RobertC. Crain, and JamesR. Wilson, Eds., 1992, pp. 726-736. [Balzer, 1983] Balzer, Robert, ThomasE. Cheatham and Cordeil Green, Software technologyin the 1990s: Using a new paradigm, Computer, 16:11, Nov. 1983, pp. 39-45.
BIOGRAPHY OF RICHARD E. NANCE Richard E. Nance is the RADM John Adolphus Dahlgren Professor of Computer Science and the Director of the Systems Research Center at Virginia Polytechnic Institute and State University. He received B.S. and M.S. degrees from N.C. State University in 1962 and 1966, the Ph.D. degree from Purdue University in 1968. He has served on the faculties of Southern Methodist University and Virginia Tech, where he was Department Head of Computer Science, 1973-1979. Dr. Nance has held research appointments at the Naval Surface Weapons Center and at the Imperial College of Science and Technology (UK). Within the Association for Computing Machinery (ACM), he has chaired two special interest groups: Information Retrieval (SIGIR), 1970-1971 and Simulation (SIGSIM), 1983-1985. He has served as Chair of the External Activities Board and several ACM committees. The author of over 100 papers on discrete event simulation, performance modeling and evaluation, computer networks, and software engineering, Dr. Nance has served on the Editorial Panel of Communications ACM for research contributions in simulation and statistical computing, 1985-1989, as Area Editor for Computational Structures and Techniques of Operations Research, 1978-1982, and as Department Editor for Simulation, Automation, and Information Systems of liE Transactions, 1976---1981. He served as Area Editor for Simulation, 1987-1989 and as a member of the Advisory Board, 1989-1992, ORSA Journal on Computing. He is the founding Editor-in-Chief of the ACM Transactions on Modeling and Computer Simulation and currently serves as the US representative to TC-7: System Modeling and Optimization of the International Federation for Information Processing. He served as Program Chair for the 1990 Winter Simulation Conference. Dr. Nance received a Distinguished Service Award from the TIMS College on Simulation in 1987 and was inducted as an ACM Fellow in 1996. He is a member of Sigma Xi, Alpha Pi Mu, Upsilon Pi Epsilon, ACM, liE, and INFORMS.
DISCRETE EVENT SIMULATION LANGUAGE SESSION
427
IX FORMAC Session
Chair: Thomas J. Bergin Discussant: Joel Moses
THE BEGINNING AND DEVELOPMENT OF FORMAC (FORmula MAnipulation Compiler) Jean E. Sammet Programming Language Consultant R O. Box 30038 Bethesda, MD 20824
ABSTRACT The first widely available programming language for symbolic mathematical computation to have significant practical usage was FORMAC (FORmula MAnipulation Compiler). This paper discusses the earliest conceptual work in detail, and then provides information about later developments of the language. Other languages and systems of the early and mid-1960s are described briefly, with emphasis on their relation to FORMAC. There are also a few glimpses into the software management process at IBM. Finally there is an evaluation of FORMAC and its influence. CONTENTS 9.1 Introduction 9.2 Project Planning and Organization 9.3 Other Early Languages and Systems 9.4 Rationale for the Content of the Language 9.5 The PL/I-FORMAC Development 9.6 FORMAC 73 9.7 Evaluation of FORMAC 9.8 Implications for the Future of Languages for Symbolic Mathematics Acknowledgments References
9.1
INTRODUCTION
The language FORMAC (standing for both FORmula MAnipulation Compiler and FORMal Algebra Compiler) was the first language for symbolic mathematics that had significant use. Its development really involved three phases, in which the following versions of the language were developed: 1. 7090/94 FORTRAN-based version, 2. System/360 PL/I-based version, and 3. FORMAC 73. 429
JEAN E. SAMMET
The first two phases took place in IBM in Cambridge, Massachusetts, and the third occurred entirely outside of IBM, and largely in Europe. This paper emphasizes the first two phases and provides some information on the third. The paper also provides some details about two other formula manipulation languages (ALTRAN and Formula ALGOL), which were developed around the same time or only slightly after FORMAC. There is also some information about the general milieu of computation in symbolic mathematics (known then as formula manipulation). I will use the latter term throughout much of the paper for consistency with the early documents.
9.2
9.2.1
PROJECT PLANNING AND ORGANIZATION
Initial Activity in IBM
On October 9, 1961, I joined IBM's Data Systems Division (DSD) with an assignment to establish and manage a group in the Boston, Massachusetts area to do applied research/advanced development in software. The reason for establishing the Boston Advanced Programming Department was the feeling within IBM that there were probably very good people in the Boston area who would be interested in joining the company but who would not be interested in working in Poughkeepsie, New York, which is where the bulk of the DSD software people were located. It was also felt that having a high-quality software group (even if small), which was involved with R&D rather than production software, would make it easier to establish informal and useful contacts with the faculty at MIT and Harvard. My immediate manager was Nathaniel Rochester, who was in charge of a department called Advanced Computer Utilization, whose mission was to take a forward look at software for the division. At that time, DSD was responsible for the large computers (e.g., 7090, 7080), operating systems (e.g., IBSYS), and the major language compilers (i.e., FORTRAN and COBOL). Rochester initially reported to Bob Evans (the Division Vice-President, who later managed the System/360 development). Throughout most of the work on FORMAC, Rochester reported to Carl Reynolds, who was in charge of almost all the programmers in the division--many hundreds and perhaps as many as a thousand. Thus I had the advantage of reporting to a relatively high level in spite of having a small department (which never exceeded 30 people). 9.2.2
Early Thoughts
Rochester's instructions to me were rather general, but he did say that I should plan a project in the area of symbol manipulation. This term was not defined by him, and it was left to me to decide how to interpret it. For the first six months, I was very busy with organizational problems such as recruiting a staff, finding appropriate offices, etc. In the spring of 1962, I proposed to Rochester that we do an evaluation of various symbol manipulation systems which then existed. In the terminology of that time, those systems included LISP, COMIT (a string processing language), as well as various others. Rochester replied that he preferred that we do something that would produce a practical---even if experimental--system. I then came up with the idea of developing an extension to the FORTRAN language, which would enable people to do "formula manipulation"--although the more accurate term is "formal algebraic manipulation"---of the type done in high school and college (e.g., expansion of expressions, formal differentiation, and substitution). The two key aspects of this idea were that the system was to be an extension of the FORTRAN language, and that it was to be practical. My reasoning was that the people
430
CHAPTER IX
PAPER:THE BEGINNING AND DEVELOPMENT OF FORMAC
who might use such a proposed system were engineers and mathematicians already using FORTRAN for numeric work, and thus they would find it easier to absorb these new ideas. At the time I was starting these considerations, the pendulum of mathematical work had gone from the precomputer era of analytic solutions to the computer era of numeric solutions. The reason for this was very simple--the early facilities, such as subroutines for trigonometric functions, square root, etc., all applied to numeric information, as of course did FORTRAN. What I was proposing (although not stating it so specifically) was to swing the pendulum back to the precomputer era, but using the full power of the computer. This point is important, because throughout the 1960s, and to a lesser extent even into the 1990s, there was an intellectual selling job that needed to be done to make the potential users realize that they really could use the computer in a practical way to do analytic work. The general state of the art around that time is described in Sammet [1966a, 1966c].
9.2.3
Initial Project Description
One of the people I hired in 1962 was Robert G. Tobey, who was finishing his Ph.D. in Applied Mathematics at Harvard University. With his assistance, I sent a formal project description to Rochester [Sammet 1962a]. What follows is a quotation from parts of that memorandum (which was seven pages single-spaced). The word "provide" was used as a synonym for "develop" because at this stage I certainly was not thinking about issues of distribution or support.
OBJECTIVES •.. To provide a system which has basic Fortran capabilities and also the ability to do symbolic mathematics. •.. To provide a system which can be used for production runs of problems involving both symbolic and numeric mathematics. To provide a system which can be useful to application areas which have previously used numerical approximations because the analytic methods were too time-consuming and prone to errors . . . . • . .
METHOD • . .
The system has two parts: a language and a compiler to translate the language. The language will consist
of (a) control statements (b) arithmetic statements (c) symbol manipulation statements (d) declarative statements for the compiler usage (e) subprogram statements (O input/output statements Parts (a) and (b) will be upward compatible with FORTRAN IV. Parts (d), (e), and (f) will be as upward compatible with FORTRAN IV as possible . . . . Among the symbol manipulation capabilities will be the following: •.. substitution.., rearrange a given symbolic expression.., simplify.., extract specific coefficients... expand an expression•.. JUSTIFICATION •., Preliminary investigations show that there are groups which could use a system of the kind being planned. Among these are astronomers, aerodynamic engineers, and molecular chemists . . . .
FORMAC SESSION
431
JEAN E. SAMMET 9.2.4
Constant Need for Justification
Because the idea of producing a practical system to do this type of symbolic mathematics was new, there was a constant need for both quantitative and conceptual justification. After all, we were providing a system for people to do something they had never done before, and it wasn't clear how many of them would be receptive. This need for justification continued throughout the project's first two phases. In August 1962, I sent a memo to Rochester [Sammet 1962b], which contained estimates of potential usage, as well as the planned name for the system--SYMACOM (SYmbol MAnipulation COMpiler). One of the examples we cited as justification for the project was the following [Bond 1964, p. K2.1-1]: Of 4 months spent on a project in perturbation theory, a senior physicist spent 2 months trying to correctly complete manipulations in tedious algebra. Many algebraic errors were found only after the programmer had debugged the program for the numeric calculations and had sought futilely for several weeks for additional programming errors. We generally provided information on intended usage from two angles: application areas and mathematical areas. Included in the former were astronomy, hydrodynamics, physics, and stress analysis. The latter included curve fitting, elliptic functions, quaternions, and series operations. Tables 9.1a and 9.1b, from Sammet [1962b], show the full list of application areas and mathematical areas that we identified at that time. These were not idealistic or abstract lists, but were based on actual interviews with individuals who had specific applications. This same memo included an estimate that almost 2000 man-years were being spent in doing symbolic manipulation of this kind by hand; I believe this estimate was based on work by scientists and engineers in the United States. It should be remembered that in those days there was no consideration of "selling software." The justification of the project was needed to make sure that IBM's resources were being spent in a way that would benefit customers. 9.2.5
Start of Work
Rochester was enthusiastic about this project, and gave me a hearty "go-ahead." By then I had recruited more people, and we started developing the detailed language specifications. In December, 1962, we issued the FORMACPreliminary Language Specifications with the authors R. J. Evey, S. F. Grisoff, J. E. Sammet, and R. G. Tobey [Evey 1962]. By that time, the name had been changed to FORMAC (FORMULA MAnipulation Compiler or FORMal Algebra Compiler or FORmal MAthematics Compiler; the first became the official name associated with the acronym). Several other names had been considered, and a vote had actually been taken within the group earlier; the other names considered were ALMACOM (ALgebraic MAnipulation COMpiler), MAMACOM (MAthematical MAnipulation COMpiler), APS (Algebraic Programming System), MAPS (MAthematical Programming System), ALMANAC (ALgebraic MANipulation Automatic Compiler), ALMANS (ALgebraic MANipulation System), and FORMAN (FORmula MANipulator). The following footnote from the first page of the preliminary language specifications ([Evey 1962]) highlights the terminology of that time period: The terms 'symbol manipulation', 'tedious algebra', 'formal algebra', 'formal mathematical computations', and 'non-numeric mathematics' are all to be considered equivalent for the purposes of this report. The use of the word 'algebra' does not preclude other mathematical elements, e.g., trigonometric expressions, formal differentiation, etc.
432
CHAPTER IX
PAPER:THE BEGINNINGAND DEVELOPMENTOF FORMAC TABLE 9.1a List of application areas needing formula manipulation. (Source: [Sammet 1962b]) Astronomy Chemistry (theoretical) Economic models Flight simulation (missile and plane) Heat transfer High frequency vibration of quartz crystals Hydrodynamics Logical circuit design Meteorology Missile and aircraft design Perturbation problems of higher order Physics (theoretical and mathematical) lens design molecular physics nuclear physics Prediction of radioactive fallout Reactor physics--neutron and gamma ray distributions Stress analysis War gaming
TABLE 9.1b List of mathematical areas needing formula manipulation. (Source: [Sammet 1962b]) Algebraic and trigonometric expression simplification Analytic differentiation (ordinary and partial) Analytic solution of linear equations Boolean matrices Calculus of variations Continued fractions Curve fitting Differential equations (solution by successive iterations) Eigenfunctions Elliptic functions Laplace and Fourier transforms Linear dependence tests on vectors Matrix manipulations Numerical analysis Quatcrnions Recurrence equations (computation of functions) Rewrite functions to permit integration around a singularity Series operations (e.g., expansion of series coefficients, polynomial manipulation, Fourier series) Stability analysis Symbolic determinants
FORMAC SESSION
4:33
JEANE. SAMMET These were terms we used ourselves, but I believe they were also used by others in the field at that time. The current terms for the same concepts tend to be "symbolic computation" or "symbolic mathematics." The objectives stated for the system in Evey [ 1962] were essentially the same as those in my August 1962 memo, except that two additional objectives were added: To provide a tool useful in improving numerical analysis techniques. To provide for eventual usage with remote terminals on a time-sharing basis, thus permitting man-machine interaction. (In today's environment, with a computer on every desk, it is hard to remember that in 1963 the only personal interactions with the computer were primitive systems involving typewriters connected to mainframes, which could be used in a time-sharing mode. Very very few people had access to these systems, and almost everyone "communicated" with a computer via physical media such as punched cards or paper tape.)
9.2.6 Consultant and Joint Study Agreement Early in the considerations of this system, I talked to Professor Michael Barnett of the MIT Physics Department. He was one of several physicists who needed more computer software than was normally available in order for him to do his work in physics. Barnett became involved in the development of the software, and actually became more interested in that than in the physics. In any case, as he was both a potential user and someone with significant knowledge of software, he became an unofficial, and later an official, consultant to the project. Because there were others at MIT who might be interested in using an early version of FORMAC, we negotiated a joint-study agreement in January 1963 between IBM and MIT to enable various faculty members to use the system as it was being developed. There were certain political difficulties inherent in this, because Barnett was MIT's Principal Investigator on this contract, and he ran a computing laboratory that was different from, and sometimes in conflict with, the main computing facility at MIT. (The latter group developed the Compatible Time-Sharing System [CTSS] on the 7090 [Crisman 1965], and it appears to have been the first general time-sharing system to have had substantial use.)
9.2.7
Project Personnel and Operation
By June 1963, I had hired or had IBM transfers of several more people, namely Marc Auslander, Elaine R. Bond, and Stephen Zilles. Somewhat later, Robert Kenney and Matthew Myszewski joined the project. With those people, as well as Evey, Grisoff, and Tobey, who had worked with me on the preliminary language specifications, we had a full team. However, we did use several students from MIT and Harvard on either a part-time and/or summer basis, namely A. Anger, R. Bobrow, S. Bollt, R. Gruen, and A. Rosenberg. Other IBM employees who participated in the later stages of the work were Larry Bleiweiss and Jim Baker. With the shift of the work from language design to the implementation, Bond became essentially the technical leader. I remained as the project manager, but I was also responsible for other projects, as well as running an off-site department (i.e., located in a city distant from any IBM laboratory or administrative facility). To make sure that everybody was kept informed, I started a series of internal memos dealing with the language and its implementation; we issued more than 100 of these memos.
434
CHAPTER IX
PAPER:THE BEGINNING AND DEVELOPMENTOF FORMAC 9.2.8
Planned Schedules and Costs
The planned schedule (following the basic defining memo [Sammet 1962a]) was to produce language specifications by December 1962, do the system design from January to June 1963, and do most of the coding by December 1963. The system was scheduled to be fully operational by April 1964. I specifically established early completion rather than efficiency as a major objective. We met the April 1964 completion date with a reasonably tested, running system! Although the project originally had no intention of releasing FORMAC in any way, we did want to get feedback and experience. We initiated a number of joint-study contracts with various organizations to permit them to use the system and get some assistance from us. In addition to MIT, joint-study contracts existed with Raytheon, Jet Propulsion Lab, United Aircraft, and others. Word quickly spread, and as a result of various lectures by our staff and informal dissemination of information, there was strong pressure to release the system in some way. In November 1964, FORMAC was released as an official Type III program for the 7090/94 family of computers [Bond 1965a, p. 1; IBM 1965]. That gave it more status than merely an experiment, and meant that the tape would be distributed by the normal IBM distribution center, rather than by us. However, there was no guarantee of support to the users. In that time period, Type I programs were those systems that IBM was fully committed to support (e.g., FORTRAN and COBOL compilers). Type II were application programs also receiving full support. The Type II! programs were those developed by IBM personnel but released on a "user beware" basis. This meant that IBM was n o t responsible for supporting them in any way, although the development group frequently did so. My group provided support because we were very anxious to learn about the successes and problems of our users to see if we had achieved our objectives and produced a useful system. The cost to produce the operational prototype (i.e., the expenditures in the period from 1962 to April 1964) are as follows, where the information is based on a typed--but otherwise unidentified sheet--in my files. Manpower Machine Time Miscellaneous
$181.1K 55.7K 9.5K
Total for prototype
$ 246.3K
Additional costs of $256.4K were incurred from May to December 1964, resulting in a total cost of $502.7K, essentially through the initial Type III release. The manpower expended was around 20 man-years, including: • conception, design, implementation, testing, etc. • preliminary specifications for the System/360 • modified CTSS versions • some interaction with users • participation in forecasts of potential FORMAC usage • much documentation (manuals, technical reports, and published papers) 9.2.9
Interaction with Users
We felt it was extremely important to work closely with the users--helping them and learning from them--because this would assist in justifying our work to IBM management. FORMAC SESSION
435
JEAN E. SAMMET
Because of the constant need to justify the work on both the 7090/94 and proposed System/360 systems, I issued several detailed memos describing actual usage (e.g., [Sammet 1965a]). In addition to our work, SHARE (the users' group for IBM scientific computers at that time) set up a project with which we cooperated strongly. The heavy involvement with SHARE continued for many years, including their eventually "taking over" the system after IBM dropped it. In June 1965, we held a user symposium attended by more than 30 non-IBM users, as well as numerous IBM personnel. Critique forms we requested be filled in provided us with useful information. Generally, the users' comments were favorable, but since the details differ in each case it is not feasible to summarize them here. Over a period of more than a year, various internal memos were written summarizing user interest and accomplishments (e.g., [Sammet 1965a]). A number of reports and journal articles by people outside IBM were published describing the use of FORMAC in practical problems. Some of them are listed in Section 9.7.1 (points 3 and 6). 9.2.10
Desk Calculator Version
In January 1965, we developed a "desk calculator FORMAC," which essentially allowed people to use a simplified version of FORMAC in the context of a time-sharing system, where each statement was executed immediately after it was typed in. It was installed on an IBM system, under the MIT Project MAC CTSS [IBM 1966]. Details of the system are in Bleiweiss [1966]. 9.2.11
Publications and Lectures
Because part of our task was "selling" the concept--intellectually although not financially--we had a fairly ambitious set of publication and lecture activities. The first full journal publication was in an IEEE Transactions [Sammet 1964a], and this was followed shortly by a paper in the ACM Conference Proceedings [Bond 1964]; this was the first presentation at a conference. Numerous lectures were given at universities and user organizations. Other publications are shown in the reference list (e.g., [Sammet 1967]), and referred to elsewhere in this paper. Many more publications are not even mentioned here, to avoid an even longer paper!
9.3 OTHER EARLY LANGUAGES AND SYSTEMS In considering other languages and systems known at the time I started the FORMAC project, it is crucial to distinguish between a language and a system, where the latter generally involves an integrated package of routines, but not a programming language connecting them. As will be seen later, there were several of the latter, but only one of the former. 9.3.1
ALGY
By 1962, when the project description was written, there was only one programming language that had ever been developed to do formula manipulation, and that was ALGY, developed for the Philco 2000 [Bernick 1961 ], ALGY contained commands for removing parentheses, substitution, factoring with respect to a single variable, and a few other commands. It did not have any relation to an existing language. As I stated in my book: "Although ALGY apparently never received too much usage or publicity, I consider it a major contribution to the field because it was the first system to try to provide multiple capabilities on a general class of expressions all in one system. In fact, for some ideas, ALGY was a conceptual forerunner of FORMAC." [Sammet 1969, p. 474]. 436
CHAPTER IX
PAPER:THE BEGINNINGAND DEVELOPMENTOF FORMAC
My reason for the last sentence is that ALGY helped me realize that what would be most helpful to users was a language rather than a set of subroutines. The only other effect that ALGY had on my thinking was the actual commz~nds; however, since the ALGY commands are all obviously necessary, I am sure that I would have derived them independently even ifI had never seen ALGY. Thus, ALGY's primary influence was the concept of a language with commands operating on the formal expressions.
9.3.2 Other Systems (Not Languages) There were several formula manipulation systems known around the time FORMAC started, although many of them were either experimental and used only by their developers, or based on a specific, relatively narrow, class of applications. A fairly detailed description of these systems is given in Sammet [1966a], and a very detailed annotated bibliography is in Sammet [1966b]. (A retrospective look at that time period, from the hindsight of 25 years, is given in Sammet [1990]). The more widely mentioned or used nonlanguage systems of that time included ALPAK (developed at Bell Labs) [Brown 1963-1964], and PM (developed at IBM Research Center) [Collins 1966]; both dealt with polynomials or rational functions and emphasized efficiency for those classes of expressions. (The evolution of ALPAK into the language ALTRAN is discussed in the next section.) ALPAK and PM were probably developed in parallel with FORMAC. Information on other efforts was difficult to obtain since the field was not cohesive, and the people involved generally did not know each other at this early stage nor was there an effective methodology for communication. As will be indicated later in Section 9.7.1 (point 7), solving this communication problem was one of the major motivations for my forming the ACM Special Interest Committee on Symbolic and Algebraic Manipulation---SICSAM.
9.3.3 Other (Later) Languages By the time FORMAC was made available to users, as described in Section 9.2.9, two other languages were also under development, namely ALTRAN (based on ALPAK) [Brown 1966] and Formula ALGOL [Perlis 1964, 1966], although documents for these systems were not available to us at that time. Knowledge of both these languages was certainly available to us as we started the PL/I version of FORMAC (as described in Section 9.5). It is worth noting the difference in philosophy among the three languages in the period 1964-1965. All three were languages. ALTRAN was essentially an extension of FORTRAN (as FORMAC was) and was based on the existing ALPAK system. A version called "Early ALTRAN" was running on the 7090/94 sometime in the period 1964-1966, but the date is unclear due to discrepancies among the ALTRAN documents I have seen. However, ALTRAN dealt only with polynomials and rational functions, whereas FORMAC permitted trigonometric, exponential, and logarithmic functions as well. The greater generality allowed for FORMAC expressions resulted in FORMAC having less object time efficiency than ALTRAN when handling problems involving polynomials or rational functions. Formula ALGOL, as a language, was a superset of ALGOL 60 and permitted manipulation of transcendental functions. The first major difference in philosophy between FORMAC and Formula ALGOL was the selection of the base language, which was an obvious choice in both cases, since IBM had initially developed and promulgated FORTRAN, and Perlis had been on the ALGOL 58 and ALGOL 60 committees. Formula ALGOL provided the user with more elementary/basic capabilities and let the user build up the type of capability desired. This is best illustrated by considering simplification. FORMAC had a well-defined set of rules, which did certain things automatically (e.g., FORMAC SESSION
437
JEAN E. SAMMET A*I was automatically replaced by A--see Section 9.4.3.2), whereas Formula ALGOL provided facilities for doing this replacement but did not force it on the user. Those of us involved (particularly AI Perlis and his group, as well as myself and people in my group) had many long, albeit informal, debates on this issue at various times and places, and each group stuck to its technical philosophy. The best analogy is that in Formula ALGOL the facilities for manipulating formal algebraic expressions are similar in spirit to an assembly language; the user has the ability--but also the requirement--to write and hand-tailor many facilities that are provided automatically in FORMAC. It was the classical debate between the merits of an assembly language and a high-level language such as FORTRAN. Formula ALGOL also had facilities for dealing with strings and lists, which made it the most general of the languages that could be used for formula manipulation. Other more minor languages, which were implemented by 1965-1966, were Magic Paper [Clapp 1963], MATHLAB [Engelman 1965], Symbolic Mathematical Laboratory [Martin 1967], and FLAP [Morris 1967]. A brief summary of these is given in Sammet [ 1969, Chapter VIII. Of this set, I consider MATHLAB to be the most interesting, as it was the first complete on-line system with formal algebraic manipulation facilities, and it was written in Lisp. Furthermore, MATHLAB, and its later version MATHLAB 68 [Engelman 1971 ], were precursors for the major system MACSYMA [Martin 1971 ; Moses 1974]. A representation of the state of the art in languages and systems as of 1965-1966 occurred in the first SYMSAM (ACM SYMposium on Symbolic and Algebraic Manipulation) held March 29-31, 1966; a full issue of the ACM Communications [ACM 1966] represented the proceedings. SYMSAM was followed shortly by a small IFIP conference held in September 1966 in Pisa, Italy; the book that served as the proceedings of that conference also provided a good representation of the state of the art at that time [Bobrow 1968]. An updated bibliography [Sammet 1968] was included in that book. The milieu of five years later is reflected in the second symposium--SYMSAM 1971 [Petrick 1971 ]. For those readers familiar with more current systems such as MACSYMA, MAPLE, Mathematica, and REDUCE, they did not exist in 1965. The initial version of REDUCE was not a language but rather a set of routines [Hearn 1966, 1967]. (Partially at my urging, REDUCE was eventually developed into a language based on ALGOL 60, even though it was implemented in Lisp [Hearn 1971].)
9.3.4 FORMAC Not Influenced by Other Languages It should be clear from the preceding remarks that the 7090 FORMAC was not influenced at all by the work occurring around the same time. The primary inspiration for the language was the desire to provide reasonable capability within the framework of a good syntactic and semantic extension of FORTRAN. (Knowledge of ALGY was only minimally useful to us, because the information about it was too sketchy, and the language itself too primitive to have more than a minor effect. Furthermore, it was a "stand-alone" language, which was contrary to my basic objective of a FORTRAN extension.) By the time the PL/I-FORMAC version was developed, we were too convinced of the correctness of our approach, and also had the confirming experience of our users, to make major conceptual changes or use many ideas from other systems.
9.3.5
Involvement with LISP
The preceding discussion has not yet mentioned LISE That language was a"low-level language"from the viewpoint of actually doing formal algebraic manipulation. LISP could ~---and was--used to develop routines such as differentiation, simplification, and so on, but it did not provide those basic 438
CHAPTER IX
PAPER: THE BEGINNING AND DEVELOPMENT OF FORMAC
capabilities ab initio. Considerable work in various aspects of symbolic computation was done using LISP, including programs for doing simplification and integration, as well as specific applications in physics [Sammet 1966a, 1966c]. One of the early considerations was whether to use LISP to implement FORMAC. I made the decision not to do so, because I didn't see any great advantage to using LISE We implemented FORMAC in MAP (the 7090 assembly language). The developers of the SCRATCHPAD/I [Griesmer 1971] and REDUCE [Hearn 1966] systems clearly did not agree with me; they used LISP as the implementation language and were also able to incorporate some existing LISP routines to build up their systems. One of the obvious questions about the operational FORMAC concerned its efficiency. Unfortunately, we had no basis of comparison as there was no other system remotely resembling it. I hired Joel Moses for the summer of 1964, because he was then a graduate student at MIT and thoroughly familiar with LISP. Moses later became the leader of the large, major MACSYMA system development ]Moses 1974]. It was not surprising that the results of all the comparisons we ran in 1964 were mixed. In those cases that made use of LISP capabilities (e.g., sublists), the problem ran faster on LISP than on FORMAC, whereas in other cases the converse was true. In some instances the coding of FORMAC problems was trivial (e.g., 15 statements long) versus the LISP coding which took two weeks, because LISP did not have existing routines, such as EXPAND, that might be needed in a specific problem. (Note that the comparisons were made to "pure LISP" and not to LISP-based symbolic mathematical systems.)
9.4
RATIONALE FOR THE CONTENT OF THE LANGUAGE
9.4.1 FundamentalConcepts The fundamental concept introduced by FORMAC was that of a general language rather than a package of routines. It was felt from the very beginning--see Section 9.2.3 regarding the Initial Project Description--that the intended users were undoubtedly already familiar with FORTRAN and thus we should build on that rather than introduce a brand new language. In fact, the development of FORMAC as a "superset" required that the user know FORTRAN (or at least learn it). For the time period, this was quite logical, as the only other significant numerical language at the time was ALGOL 60, and that certainly was not in wide use in the United States nor (I have been told) even in industrial companies in Europe. To clarify the difference between FORTRAN and FORMAC, note the following two very simple examples: FORTRAN A= B--
5 3
C
(A
=
+
B)
*
(A
-
B)
These statements resultin the value ]6 being assigned to C. FORMAC LET
A
=
X
LET
B
=
Y
LET
C
=
(A
+
B)
*
(A
-
B)
These statements result in the expression (X + Y) * (X - Y) being assigned to C. FORMAC SESSION
439
JEAN E. SAMMET
In both cases, the evaluation occurs when the object code for the third statement is executed. A more complete example, namely a program to produce the symbolic roots of a quadratic equation, is provided in Figure 9.1. The language was defined using the same metalanguage as had been used for COBOL and which can be seen in any early COBOL manual. Considering the time period, however, the system obviously had to be batch-oriented. Some experimental work was done to make FORMAC available on a terminal, but this was never significantly used. That work was mentioned in Section 9.2.10.
FIGURE 9.1 Example of FORMAC program to find the symbolic roots of three quadratic equations where coefficients can be either expressions or numbers. INPUT
TO FORMAC PREPROCESSOR $IBFMC QUDIST NODECK
(FOR
C
THIS
C C
QUADRATIC EQUATION CAN BE EXPRESSIONS
C
ALTHOUGH
C C C
PROGRAM
FINDS
THIS
FORTRAN THE
ON
IBM
SYMBOLIC
ROOTS
CASE
WAS
(3),
OF
A
WHERE THE COEFFICIENTS OR NUMBERS. SET
UP
TO
RUN
ONLY
COULD OBVIOUSLY BE GENERALIZED BY SUBROUTINE AND READING RXPRESSIONS OBJECT TIME SYMARG ATOMIC X,Y,K DIMENSION
709/7090)
3 CASES
IT
USING A IN AT
Xi(3),X2(3)
LET LET
CASE(l) CASE(2)
= X**2 + 2*X*(Y+i) = 2 + X*~2 - 4*X
LET
CASE(3)
= 3"X*'2
+
(Y+i}**2
+ K*(X+X**2+i)
+4
N=3 DO
88
LET
~ = i,
RVEXPR
N
= EXPAND
REMOVE
C
CASE
(I)
PARENTHESES
LET A = COEFF RVEXPR, X**2 LET B = COEFF RvExpR, X LET C = COEFF RVEXPR, X**0 C
THE
EXPANSIONS
C
ARE
DONE
C
REMOVED
TO
PERMIT
THE THE
NEXT
THREE
PARENTHESES
STATEMENTS MUST
MAXIMUMCOLLAPSING
BE OF
EXPRESSIONS
C
LET LET 88
IN
BECAUSE
DISCRM = EXPAND B**2 - 4*A*C Xi(I) = EXPAND (-B + D I S C R M * * ( i / 2 ) ) / ( 2 * A )
LET X2(I) CONTINUE
= EXPAND
(-B
- DISCRM**(I/2))/(2*A)
FMCDMP STOP END
440
CHAPTER IX
PAPER: THE BEGINNING AND DEVELOPMENT OF FORMAC
9.4.2 Key Elements of the FORMAC Language Since FORMAC was to be an extension of FORTRAN IV, we introduced a new data type, known as a "FORMAC variable." This was really a symbolic data type, to contrast with the normal numeric data types in FORTRAN. This basic concept was crucial, and no symbolic commands could adequately be developed without it. The commands and functions provided in FORMAC are shown in Table 9.2. Noticeable (perhaps) by their absence from this list are commands or functions for integration and general factoring. The reason for their omission is merely that both those capabilities were well beyond the state of the art at the time the first FORMAC was developed. A few general comments are worth making here. First, the philosophy of automatic simplification is discussed in Section 9.4,3.2. Second, there is a differentiation operator, but not an integration operator. This reflects the state of the art in the early 1960s. Differentiation is a relatively straightforward task (sometimes assigned to freshmen as homework today). Differentiation was in fact the first known use of a computer to do any type of symbolic computation--see Sammet [1966a]. However, in ! 962 when we started FORMAC, integration was an extremely difficult task. It was not until the development of the integration system SIN (Symbolic INtegration) by Joel Moses for his Ph.D. thesis [Moses 1967] that sufficient algorithms and techniques were developed to enable symbolic integration to be implemented effectively. From a language viewpoint, the inclusion of an integration function TABLE
9.2
FORMAC executable statements and functions. Statements yieMing FORMAC Variables LET construct specified expressions (essentially an assignment statement for the symbolic variables) SUBST replace variables with expressions or other variables EXPAND remove parentheses COEFF obtain the coefficient of a variable, or a variable raised to a power PART separate expressions into terms, factors, exponents, arguments of functions, etc. Statements yielding FORTRAN variables EVAL evaluate expression for numerical values of the variables MATCH compare two expressions for equivalence or identity [yields a FORTRAN logical variable] FIND determine dependence relations or existence of variables CENSUS count Words, terms, or factors Miscellaneous Statements BCDCON convert to BCD form from internal form [needed for output] ALGCON convert to internal form from BCD form [needed for input] ORDER specify sequencing of variables within expressions AUTSIM control arithmetic done during automatic simplification [a few options were available] ERASE eliminate expressions no longer needed FMCDMP symbolic dump Functions FMCDIF FMCOMB FMCFAC FMCDFA
differentiation combinatorial factorial double factorial
Note: FORMAC also contained trigonometric, logarithmic, and exponential functions.
FORMAC SESSION
441
JEAN E. SAMMET
(or command) in the earliest FORMAC would have been trivial, but the difficulty of the object time routine to handle this was utterly beyond the scope of our project---or even our knowledge! There was a 1961 Ph.D. thesis at MIT by J. R. Slagle (later published in Slagle [1963]), that identified heuristic techniques for integration, but I don't recall whether I was even aware of his 1961 thesis when I started the FORMAC work. It was recognized that debugging might be difficult, but we did not realize just how difficult until practical output of many pages of algebraic expressions were produced. There was a command to permit a useful dump, and there were numerous diagnostic messages generated at both compile and object time. 9.4.3 9.4.3.1
Other Language Issues
General
We were constantly influenced throughout the entire project, and specifically during the language design, by the realization that we had to persuade engineers and scientists that they could use a computer for their nonnumeric computations in a way that none of them had ever done before. (Some of our relationship with potential and actual users was discussed in Section 9.2.9) We tried to do this in two ways--first, by providing an easy way of going back and forth between the numeric and symbolic computations, and second by providing adequate capabilities for the nonnumeric work. In actual practice, an application often requires massive symbolic computation to create an expression, which must then be numerically evaluated for a wide variety of values. FORMAC achieved this interaction by providing an EVAL command, which operated at object time by examining the expression just created, and generating object code for it "on the fly," which was then evaluated for the desired parameters. The alternative would have been to produce the expressions as FORMAC output and then require the user to reintroduce them into FORTRAN to do the numeric computation. We felt it was crucial to avoid that extra step. However, we eventually did have to provide that facility automatically when many problems took too long to execute the numeric evaluation (after finishing the symbolic computation) because it was interpretive. In those cases the FORMAC system generated symbolic output in exactly the form that FORTRAN needed as input, generated the FORTRAN commands to do the numerical computations indicated by the EVAL command, and automatically fed this back into the FORTRAN compiler to obtain a pure numeric compilation and computation. With respect to providing "adequate capabilities," the question has arisen as to whether the lack of integration or complete factoring was a serious problem in persuading users to try FORMAC. While this might have been true in a few cases---obviously those involving complex integration--I do not think it was a significant deterrent in most cases. I know that there were many problems where what was needed was only the ability to perform the four arithmetic operations on massive expressions, and then simplify and/or evaluate them. In fact, one of our earliest test cases for debugging involved generating a series that involved nothing more than addition, multiplication, and simplification of expressions; but the first few terms could be do,ae easily by hand, each additional term required many hours to generate it, and the time required grew with each term! We certainly expected that programs would only be written by a single person. As far as libraries were concerned, we planned to use the capability in FORTRAN but nothing beyond that. There was no intention of trying to achieve significant portability--the system was meant to be implemented as a preprocessor to FORTRAN IV using the operating system on the 7090/94, namely IBSYS/IBJOB.
442
CHAPTER IX
PAPER:THE BEGINNINGAND DEVELOPMENTOF FORMAC The users did not seem to have much difficulty learning the FORMAC facilities once they understood the basic difference between the numeric computations of FORTRAN and the symbolic computations of FORMAC. 9.4.3.2
Simplification
One of the major technical/philosophical issues in any formula manipulation system is the amount, type, and style of simplification. It is obvious from high school algebra that the expression AB - BA simplifies to 0, and that A 2 * A 3 simplifies to A 5. It is not at all obvious in a computerized system that these simplifications will---or even should--occur; if one wants them to occur, then routines must be coded and properly invoked. The FORMAC group decided on a specific set of rules for automatic simplification, and these are described in Tobey [1965b]. In considering simplification, the language specifications must specify exactly which simplifications the system will perform automatically and which the programmer can request, since simplification is a relative term that depends on the intent of the user at a particular point in the program. Most people would agree that in normal scientific and engineering work: A * 0 should result in 0 A ** 1 should result in A AB - BA should result in 0 but it is less obvious whether A(B + C) should be left alone or automatically expanded to AB + AC. Conversely, the existence of AB + AC could be factored into A(B + C) by the system, but the user might not want that. It is also not obvious whether (A - B) * (A + B) should be left in that form, or expanded to produce A 2 - B 2. These particular decisions were left for the user to specify in the program through the EXPAND command. There was also a command (AUTSIM) that gave the user control over whether factorials and/or trigonometric functions should be evaluated or left in symbolic form; for example, the user could decide whether to leave FAC(4) in that symbolic form or have it evaluated to produce the number 24. As discussed in Section 9.3.3, the amount of simplification that should be done automatically versus the amount that should be controlled by the user was an issue of much philosophical debate among those of us developing differing systems throughout this period. Even within the FORMAC project itself we didn't always agree! 9.4.3.3
Rational Arithmetic
One of the more interesting features of FORMAC is its ability to permit mixed-mode expressions and, of even more importance, rational arithmetic. The latter simply means that if we add the fractions (A/B) + (C/D) we obtain (AD + BC)/BD. Thus, 5/12 + 1/3 yields 3/4 when the result is reduced to lowest terms. While this may seem obvious, and is of course consistent with elementary school arithmetic, it was actually a rather innovative idea in software systems at the time. This feature was not in the original design ideas, nor even in the Preliminary Language Specs. I personally realized this was crucial when I was doing a hand formula calculation to check the computer runs. The latter produced either a floating-point number or an incorrect answer (e.g., in FORTRAN 1/3 + 1/3 produced either . 6 6 6 . . . rounded to .7 or produced 0). Neither of these is acceptable in expressions that are often of the form x/3 + x 2 * (2/3) + x 3 * ( 4 / 3 ) . . .
FORMAC SESSION
443
JEAN E. SAMMET
In a few cases, FORMAC was used primarily (or even exclusively) because of its rational arithmetic capability, which I believe was not available in any other system of that time period.
Effect of the Implementation on Language Design
9.4.3.4
Although the basic plan for implementation did not have a major impact on the language, it did have some. For that reason it is worth briefly indicating the overall plan. Details may be found in Bond [ 1965a]. The basic concept of the implementation was to use a preprocessor, which changed FORMAC statements into COMMENT statements and generated CALL statements for each FORMAC executable statement. The preprocessor built various tables of information and inserted pertinent FORTRAN executable and declarative statements. The output of the preprocessor became input to the regular FORTRAN IV compiler. However, it is crucial to understand that from the user's viewpoint this was transparent, and the user had a truly respectable language to work with, rather than just a series of CALL statements. Thus, the user might write something of the following form, following the normal FORTRAN conventions for fixed- and floating-point arithmetic: LET M= LET
A -~ B + 3 * C 4 Z = S U B S T A, (B,
M),
(C,
FMCDIF(X
**
2,
X,
i))
At object time the result would be that Z was assigned the value X*
6.
+ 4.
This is achieved because initially the SUBST command causes the variable M to replace the variable B in the expression A, and then M is assigned the value 4. (in floating point because B is a floatingpoint variable). Finally, the differentiation operator FMCDIF causes the value X * 2. to be substituted into C since X * 2 is the derivative of X ** 2. (Note again that the distinction between a FORTRAN integer [e.g., 2] and a floating-point number [e.g., 2.] is kept in the FORMAC statements and in the results.) The preceding example was implemented by the preprocessor which generated a series of FORTRAN statements of the form C A L L L E T (A, (B + 3 * C)) M= 4 CALL SUBST (Z, (A, (B, M ) ,
(C,
FMCDIF(X
**
2,
X,
i))))
Note that the key word L E T was used to identify the executable FORMAC statements, which were transformed into legal FORTRAN CALL statements that invoked the appropriate subroutines and which were then handled by the regular compiler. In the previous example, the original statement M=
4
remains unchanged, because it is a pure FORTRAN statement. The execution time subroutines for arithmetic on formal variables (i.e., LET), for substitution (SUBST), and the differentiation function (FMCDIF) are generated with the appropriate parameters. The language design was not significantly affected by concerns about object code efficiency, although we certainly had major concerns about this. Some of our projections about where the object time would be spent turned out to be wrong. For example, we were deathly afraid that the system would spend most of its time doing the automatic simplification, but this did not turn out to be true. 444
CHAPTER IX
PAPER:THE BEGINNINGAND DEVELOPMENTOF FORMAC
The biggest difficulty in implementation was something that we did not foresee, and could not have prevented in the language even if we had known it earlier. The biggest problem was running out of storage space because the expressions became very large; the initial implementation frequently expanded everything before using simplification or any other means to contract the size of the resulting expression. Thus, although the final result of multiplying two expressions might be quite small, the "intermediate expression swell" could exceed the storage capacity of the machine. An illustration of this storage problem can be seen in the following simple example: EXPAND
(A
-
B)
*
(A
+
B)
-
A
**
2
+
B
**
2
This results in the system generating (internally at object time) the expression A
*
A
+
A
*
B
-
B
*
A
-
B
*
B
-
A
**
2
+
B
**
2,
which the simplification routine automatically reduces to 0. Thus, the expression being expanded might be very large in its intermediate (fully expanded) form, but actually result in a small final expression. This intermediate form could exceed the storage capacity of the computer and thus cause trouble before the simplification reduction occurred. This problem, and the solution of continuously compressing the intermediate results, is well described in Tobey [ 1966a]. In other words, we modified the system to perform frequent simplification to reduce the size of the partially expanded expressions. (This is somewhat analogous to frequently using a garbage collection routine in a list-processing program to improve object time efficiency.) 9.5
9.5.1
THE PL/I-FORMAC D E V E L O P M E N T
Initial Planning
Before even seeing the early somewhat successful reception of our experimental version on the 7090/94, we were naturally anxious to provide a production version for the IBM System1360, which was (to be) announced in April 1964. ] felt we could make significant improvements based on user experience without changing the basic model, which seemed to be quite satisfactory. I decided that we should develop the second version with PL/[ as a base, rather than FORTRAN. In selecting PL~ for the second version of the language, ] was truly operating as a "good corporate citizen." There was a strong plan and intent by the IBM programming managers responsible for PL/] for it to replace COBOL and FORTRAN and become the single major language for users. Since [ believed this was a worthwhile goal, and definitely wanted to support it, the logical choice was to apply the same symbolic concepts to PL/I that were applied to FORTRAN. (For the sake of accuracy in nomenclature, I wish to point out that at the time these considerations were under way, the initial name for PL/I--i.e., NPL was in use. Hence, all the memos referred in some way to a EORMAC associated with HPL. I have chosen to use the term PL~ in this paper for ease of reading by people who don't know what NPL was, hut the references themselves accurately reflect the usage of"NPL" at the time.) As early as May 1963 [Sammet 1963a], consideration of a EORMAC version for the Systend360 using PLf[ started. This was long before the 7090/94 BORMAC system was fully implemented (and certainly long before there was any experience with it), and it was even before the existence of any preliminary specifications for PL/L Additional considerations for a System~360 version of EORMAC were expressed in Sammct [1963b]. My basic intent---expressed a year later, after some experience-was to emphasize and develop the system in a time-sharing environment. ] wrote, "Furthermore, ! have stated from the very beginning that the most effective use of FORMAC would be in a FORMAC SESSION
445
JEAN E. SAMMET
terminal system where the user can see the results of a statement before going on to the next." [Sammet 1964b]. However, later funding decisions forced me to change that plan back into developing a batch version. One of the characteristics of that time period is that estimating development costs for software was a difficult (or nonexistent) activity. Since I naturally had to provide a proposed budget for the development of the PL/I-FORMAC, I decided that the easiest way to do this was to develop the estimate as a percentage of the cost of developing a FORTRAN compiler. When I provided that percentage, I was told that nobody knew what it cost to develop a FORTRAN compiler! As is almost always true, it was essential to fight for budget and staff, At the time, there were numerous projects competing for the "software support" dollars for the System/360. Rochester and I made a presentation in April 1965 to John W. Haanstra (President of the Data Systems Division). Our objective was to persuade him to authorize the PL/I-FORMAC as a Type I (i.e., fully supported) program, and also to allow us to prepare an experimental version of a conversational FORMAC (also based on PL/I). Haanstra was fully supportive and sent a memo [Haanstra 1965] to his immediate manager Paul W. Knaplund. This memo said in part: "I have had a more thorough review of FORMAC and am convinced that we must proceed with this work." We were allocated budget and head count. Unfortunately, as time went on, the requirements for other software (e.g., OS/360--the operating system for the mid/high-end System/360 machines) became very large, and the full support for a Type I program for formula manipulation was dropped. We were allowed to continue as a Type II! program, and the PL/I-FORMAC system was released in November 1967. Management discussions continued for many months in 1964 and 1965 over such issues as (a) whether to emphasize a batch or a time-shared version, (b) whether it was to be a production version or another advanced technology version, or (c) whether a production version would be done in my Boston department or somewhere else. The paper flow on these subjects is too large to even summarize here! These discussions are of interest because they indicate some of the issues being faced by the software development and technology transfer activities in IBM in that time period. Many of the discussions applied to other software projects as well as FORMAC, and some of these technology transfer issues exist even into the 1990s. By January 1965, we had a 350-page document [Tobey 1965a] containing preliminary specifications for a batch version as an extension to PL/I on the System/360, with new implementation approaches. Both the language and implementation ideas were significant advances over the 7090/94 version, but retained the fundamental concept of adding the formula manipulation capability to an existing programming language. This document also contained ideas for even further extensions-specifically, integration, complex variables, and non-Abelian simplification, among others. It also contained a proposal for a separate object time subsystem to handle polynomials. Unfortunately, due to a lack of resources, none of these ideas---or several others--was ever implemented. In the latter part of 1965, I relinquished management of the Boston Advanced Programming Department to Rochester, who wanted to move to Boston from White Plains. That gave me the time to write my book on programming languages [Sammet 1969]. The manager for the PL/I-FORMAC project was Elaine Bond; she had been appointed manager for the 7090 work in the latter part of 1964. Thus, I had virtually no direct involvement with the development of the PL/I-FORMAC. 9.5.2
Technical Approach
Later in 1965, many of the ideas for the PL/I-FORMAC were modified and coalesced into the description given in Bond [1968], which was actually written in 1967. Although this proposal was 446
CHAPTER IX
PAPER: THE BEGINNING AND DEVELOPMENT OF FORMAC
not the description of the actual version implemented, it is an interesting published version of the type of thinking involved. The following highlights did appear in the final system. They are all based on the plan to (I) extend PL/I as little as necessary and (2) incorporate lessons learned from usage of the 7090/94 FORMAC: a. introduce a new category, Domain, which included the PL/I arithmetic variables and a new formal data type for formula manipulation; extend the PL/I declarations as needed; b. provide additional functions to control the expansion of expressions (which is, of course, a form of simplification); c. provide alternativecommands for simultaneous versus iterative substitution into an expression; d. provide additional factoring capability (but still only with respect to a single variable or its powers); e. provide fraction-handling functions to allow expressions to be written in the general form a/b (which requires developing a common denominator); and f. provide better primitives with which the user could build new formula manipulation routines. Such primitives include lead operator functions, ways to count arguments, several ways to partition expressions, search for a particular expression, and various ways to use the pointer capabilities of PL/I but applied to formal variables and expressions. A published paper describing the system that was actually implemented is in Xenakis [ 1971], and the official manual is that of IBM [1967]. The PL/I-FORMAC system was implemented by using a preprocessor to the PI./I compiler, just as the FORTRAN version had been. It is interesting to note that one of the most important improvements made was not actually a language feature, but was to the format of the output. The 7090 FORMAC produced expressions printed in a completely linear fashion using FORTRAN notation. It is an understatement to say that they were not really readable except by dedicated users who really needed the output! As can be seen in Figure 9.2a, the normal rules of arithmetic precedence apply and parentheses are used where necessary. Given the expression: ((X
+
1)
*
(X
-
Z))/(X
-
1)
the System/360 version produced two-dimensional output with the exponents appearing as superscripts, although fractions were still indicated via parentheses and the "P' (see Figure 9.2b). 9.5.3
Market Forecast Activity
In this time period, the forecasting of potential software usage or demand was generally not done. Remember that software was given away with the hardware, and all that was required to start new software projects was a management judgment that the software was worth developing in the context of increasing the sales of hardware. In 1965, attempts were just starting to get a handle on how to forecast software usage, as had traditionally been done for hardware. (I don't know if the upper management of IBM already had in mind what became known as IBM's "1969 unbundling decision," although I have reason to think that they did.) When it came time to consider a new and upgraded version for the System/360, an unusual step was taken. While I can't be certain that it was the first of its kind in IBM, it certainly was one of the earliest. We commissioned Arthur D. Little to do a study of "the utility and marketability of FORMAC," and they produced an interesting report [A. D. Little 1965]. They interviewed more than
FORMAC SESSION
447
JEAN E. SAMMET 60 people in more than 20 organizations, and they tried the 7090/94 system themselves. Their recommendations were basically positive; i.e., they felt a system like FORMAC would be quite useful. In any case, I was asked ifI would be willing to be a "guinea pig" and allow the existing primitive IBM techniques for forecasting software usage to be applied to the potential System/360 FORMAC. (The Arthur D. Little study was not considered an official IBM forecast.) I agreed, and various numbers were produced. They were not conclusive, in the sense that they didn't prove that a PL/I-FORMAC would significantly increase hardware sales, but they did indicate there would be s o m e increase. Part of the problem was that some of the FORMAC users were doing their work without the knowledge of the systems people who were responsible for their organization's computer systems; those systems people were the ones normally contacted by the IBM marketing representatives. Until this became understood, the numbers of future usage were actually lower than our current usage on the 7090/94! As a result, the eventual decisions regarding FORMAC funding were made "the old-fashioned way"--by management fiat!
9.5.4 Availability, Usage, and Other Systems Although the higher-management decision was made not to provide PL/I-FORMAC as a Type I program (i.e., fully supported), it was (again) released as a Type III program, and did receive considerable usage. By the time of the Second Symposium on Symbolic and Algebraic Manipulation sponsored by ACM SIGPLAN [Petrick 1971], newer languages were under construction, namely MACSYMA and SCRATCHPAD/I. Further work was also reported at that conference on earlier systems, such as ALTRAN, MATHLAB, and REDUCE.
FIGURE 9.211 Example of high-speed printer output from 7090/94 FORMAC. (Same problem as in Figure 9.2b, but in the original output
format.) Taylor series for e x sin(x) to 20th degree (Normal rules of arithmetic precedence apply, and parentheses are used where necessary) X / l I +2"X*'2/21 + 2 " X * ' 3 / 3
I-4"X*'5/5
+16"X*'9/91
!+ 3 2 * X * * i i / i i I - 6 4 * X * * i 3 / 1 3
+32"X**i0/i0
I-8"X*'6/6
-128*X**i5/151+256*X**i7/171+512
X
!-8"X*'7/71 !-128"X**14/141
18/18!+512
X
19/19.
FIGURE 9.2b
Example of high-speed printer output from PL/I-FORMAC. (Source: [Xenakis 1971, p. 106])
Taylor series for e x sin(x) to 20th degree TAYLOR .
.
.
.
.
.
.
448
.
.
ffi X .
.
.
.
.
/ ii
.
.
.
.
.
8 X 7 / 71
+
.
.
.
.
64 .
.
.
.
.
.
.
.
.
X13/ .
512
.
.
.
.
.
.
.
.
.
+ .
.
.
.
.
+ 16 .
.
131
X18/
.
.
.
.
.
.
.
.
.
.
.
.
.
128 .
+
.
.
.
.
.
.
.
.
X 9 / 91
-
181
2 X 2 1 21 .
.
.
.
.
.
.
.
.
.
+
.
.
.
2 X 3 / 31
.
.
.
.
+ 32 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
-
.
.
.
.
X 10 / 1 0 l
X 14 / 1 4 1
512
.
.
.
.
.
.
.
.
.
128 .
.
.
.
.
.
.
.
4 X 5 / 51 .
.
.
.
+ .
.
.
.
.
.
32 .
.
.
.
.
.
.
.
.
.
-
.
.
.
8 X6 / .
.
.
.
61
X 11 / iiI .
X Is / 1 5 1 ~
.
.
.
+ .
.
.
.
.
.
.
.
256 .
.
.
.
.
X 17 / 1 7 1 .
.
.
.
.
.
.
.
.
.
.
.
X 19 / 191
CHAPTER IX
PAPER:THE BEGINNINGAND DEVELOPMENT OF FORMAC
9.6
FORMAC 73
By 1970, IBM no longer had anybody involved with FORMAC, and released the source code. The SHARE project in Europe prepared a list of known errors and proposed extensions, and several people developed a new preprocessor. Although several people worked on providing improvements, the key individual to do this was Knut Bahr (of the GMD, Institut fiJr Datenfernverarbeitung in Darmstadt, Germany). Among the improvements planned or implemented in ! 974 [Bahr 1974], and referred to as "novelties" in Bahr [1975], are the following: • the EVAL function permitted the use of the phrase "for any x," denoted $x; • the user could write functions as procedures; • the function CODEM, which put an expression over a common denominator, was made more powerful by having the system attempt to remove or make use of common factors; and • the R E P L A C E function was made more general by permitting the user to specify integration rules and thus apply REPLACE to do some integration. In addition, Bahr created a new FORTRAN-FORMAC on the System/360, which was compatible with the PL/I-FORMAC [van Hulzen 1974]. A revised manual was issued in several stages, a later one of which is SHARE [ 1983]. Furthermore, a Conversational FORMAC was developed in the early 1980s at Pennsylvania State University [Penn State 1983], where the key individual was H. D. (Skip) Knoble, who was the Chairman of the SMC Committee in the SHARE Math Software Project. FORMAC 73 continues to be used, but certainly is far behind the current technology. 9.7
EVALUATION OF FORMAC
In examining the objectives set forth in the original project description [Sammet 1962a], and excerpted in Section 9.2.3, it seems fair to say that FORMAC met its objectives, On the other hand, in terms of some of the larger objectives that I personally had for FORMAC, it has not been that successful. It is appropriate to be much more specific about this mixed evaluation, and these issues are the focus of this section. 9.7.1
Influence of FORMAC
FORMAC had significant, although sometimes indirect, influence in a number of areas and on other systems. There is certainly a difference between the influence of FORMAC as a language and a system, and my own personal influence (manifested largely, but not entirely, through establishing ACM SIGSAM). Both these factors are mentioned in this section. I. FORMAC made clear that a language--as contrasted with a package of subroutines--was important to the user. In that sense both FORMAC and I influenced REDUCE and subsequent systems, which were developed as real programming languages for symbolic mathematics. Memories of the key participants, as well as later documents, apparently differ over whether our work had any influence in causing ALPAK to evolve into the language ALTRAN. The ALTRAN documents do not mention FORMAC, but nevertheless I have a strong recollection that we had at least an indirect effect on their work; unfortunately, I cannot find a document to support my recollection. Circumstantial evidence exists in the sense that we published two significant papers describing FORMAC in 1964 [Sammet 1964a; Bond 1964]. The Early ALTRAN version seems to have been developed in the 1964-1966 period [Brown 1971, p. A3], FORMAC SESSION
449
JEAN E. SAMMET
but (as stated earlier) there is a conflict in the dates given in the numerous ALTRAN documents that I have. In my own view, the development of a language was the most significant contribution of FORMAC. Furthermore, I believe that the concept of adding to an existing major language was a large contribution, although clearly the workers in this field do not agree with me. (See point 1 in Section 9.7.2.) These are the contributions of which I am the proudest. 2. Because of our fairly large "publicity campaign" of publications, talks, and direct work with users, a significant number of scientists and engineers realized that a computer could be used quite effectively to save them the manual labor of formal mathematics. Along with ALTRAN in the mid-1960s, FORMAC made it clear to users that this was a viable approach to solve many problems. 3. One of our test cases--known as the "f and g series" [Sconzo 1965] became a benchmark for performance comparison for almost all systems for many years. (This certainly was not an objective, or our intent; it just happened.) 4. We introduced--I believe for the first time--the significant use of rational number arithmetic. (See Section 9.4.3.3 for a fuller description of this.) 5. We made it clear that the users really needed more than just polynomials and rational functions. 6. Numerous early practical uses of FORMAC [Cuthill 1965; Duby 1968; Howard 1967; Neidleman 1967; Walton 1967] clearly demonstrated that many practical problems could and should be solved in a batch mode. A broader summary of real applications developed using FORMAC is given in Tobey [ 1966b]. While many problems absolutely need interactive user decisions to direct the course of the symbolic computation as it proceeds, there are also many other problems that don't need that interaction and hence can be done in a pure batch mode. 7. Because of the desire to be able to interact freely with others working in this area (which was normally prevented by IBM policies unless there was an external organizational "umbrella"), I founded (and chaired) the ACM Special Interest Committee on Symbolic and Algebraic Manipulation (SICSAM) in 1965. I defined and charted its scope to be primarily formal algebraic manipulation. In accordance with ACM procedures, this group evolved into the Special Interest Group (SIGSAM) in 1967. At that time, I declined to continue as Chairman because I was no longer actively involved in this field and was concentrating on finishing my programming languages book [Sammet 1969]. SIGSAM has been, and still is, a major organizational focus of work in this area. 8. I organized the first real technical conference in this subject area (namely SYMSAM--ACM Symposium on Symbolic and Algebraic Manipulation, held in March 1966) and served as both General Chair and Program Chair. The August 1966 issue of the Communications of the ACM [ACM 1966] represented its proceedings. This was the initial activity of SICSAM, and started a long series of conferences organized by different groups, including (but not limited to) ACM SIGSAM. 9. The PL/I-FORMAC version on the IBM System 360/370 is still in use today, in spite of a lack of support by IBM or anybody else. PL/I-FORMAC is distributed through SHARE. In summary, it seems reasonable to suggest that FORMAC and the creation of ACM SIGSAM were the major--although by no means the only--activities that started significant practical work in the field of symbolic computation.
450
CHAPTER IX
PAPER:THE BEGINNING AND DEVELOPMENT OF FORMAC
9.7.2
Problems, Difficulties, Failures
1. I am personally most disappointed that no other significant language development has chosen to follow the philosophy of adding on to an existing scientific language. The more modern systems are completely independent languages (e.g., MACSYMA, Maple, and Mathematica). . Early FORMAC usage was significantly hindered by people who were not used to thinking of using computers for formula manipulation, particularly in a batch mode. By the time there were significant numbers of people interested in doing symbolic computation, FORMAC had been overtaken by more modern systems, most of which are interactive. . Although FORMAC is still being used in the 1990s, it has been a minor language since the 1970s. The failure of IBM (or any other organization) to provide major technology updates means that it will never be widely used. . Although not the fault of the FORMAC effort, I find it disappointing that the people concerned with scientific and mathematical computation continued for many years to prefer numerical to nonnumerical calculations. The conference on Mathematical Software held in April 1970 contained only one paper that was not purely numericalknamely, mine [Sammet 1971]. Fortunately, since then, there has been more realization of the usefulness of symbolic computation in the general field of mathematical software. 9.7.3
Mistakes or Desired C h a n g e s
For its time, I think FORMAC did moderately well. Aside from minor points, I don't think we made many mistakes within the scope o f our basic intent and resources, nor would I make many changes (except minor ones) if I had it to do all over again. That sounds self-serving, and perhaps it is, but FORMAC represented a particular philosophy that I continue to believe was a reasonable one. Obviously, in today's environment, FORMAC is obsolescent because there was no organization with sufficient support to modernize it as symbolic mathematical technology progressed. One indication of the types of faults that Rochester perceived at the time of the 7090/94 FORMAC is recorded in Sammet [1965b]. Quoting from that memo: 1. FORMAC is quite inefficient compared to ALPAK in the handling of polynomials. 2. The output is terrible. 3. FORMAC handles expressions and not equations. This causes difficulties in problems. 4. FORMAC is not open ended. In a slightly different category, but equally valid, are two major capabilities which are lacking--namely, integration and vector and matrix handling. My own reactions to these points, based on 25 years of hindsight, are about the same as they were then, namely: I. Since FORMAC had no special capabilities to make polynomial handling efficient, it was indeed inefficient when the application involved polynomials or rational functions. I tried strongly to get this into PL/I-FORMAC, even to the extent of issuing a memo to Bond indicating that this must be done ]Sammet, 1965c]. However, by the time the work was actually under way, I was no longer responsible for the activity and could not enforce this. 2. Rochester's criticism was certainly true, and the output format was significantly improved in the PL/I-FORMAC version. FORMAC SESSION
451
JEAN E. SAMMET
. Point 3 is not terribly significant because the intent of FORMAC was to handle formal mathematical expressions and not equations. This is an interesting semantic distinction but I never found any cases where it made any difference. In practice, it was "expressions" that were being manipulated and not "equations." . I really can't recall exactly what Rochester meant about not being open ended, and so I am not sure of its importance. However, I do remember vividly that he criticized FORMAC for not having the language features needed to write its own compiler. I protested vigorously to him that compiler writing was a specific type of application, just as was symbolic mathematics, and that it was unreasonable (and made no sense) to expect a system such as FORMAC to do both. With regard to the basic scope of FORMAC, certainly the absence of integration and vector/matrix handling, and the inefficient handling of polynomials and rational functions were weaknesses, but they certainly could have been corrected if FORMAC had become a system supported by IBM. The obstacle was not the language itself but the resources needed to implement the object time routines; after all, it was trivial to add a command called INTEGRATE to the language! Stated another way, I don't feel there was anything in the language, or in the basic concepts, that would have prevented the correction of any perceived technical deficiencies or omissions in FORMAC, had there been an appropriate management decision to do so.
9.7.4 MajorProblem--Storage Space The major problem that actually occurred was clearly not a language issue, but rather one of performance in terms of running out of storage space. The large machines of the 1960s were small compared to the personal computers of today. FORMAC users frequently suffered because of the enormous amount of storage needed to run some of their applications. Fortunately, some tricks and techniques were found to alleviate some of the difficulties of that time period. This was discussed in Section 9.4.3.4.
9.7.5 Why Didn't FORMAC Become a Major System? As part of the evaluation, it is appropriate to examine the question of why FORMAC did not become a major system. After all, it was the first formula manipulation language that was used for real problems, and even the first version did receive significant usage. It seems to me albeit with obvious bias--that there are two main reasons that FORMAC is of more interest historically than as a current viable system. Certainly the first and most important reason is that IBM never supported it, beyond allowing the developers to provide rudimentary help to the users. It was never a fully supported Type I system (pre-1969 unbundling) and certainly never became a program product (after 1969). In spite of the fact that we had a large early technical lead in this area, it was never possible to persuade the management that formula manipulation/symbolic computation in general, and FORMAC in particular, was more important than other software systems competing for resources. The net result of this lack of support is that FORMAC was not able to improve as better technology became known and available. It is worth noting that various users did become interested enough to upgrade the PL/I-FORMAC to FORMAC 73 (as discussed in Section 9.6). However, in that time period, it was difficult for users to take a large complex system and make major improvements.
452
CHAPTER IX
PAPER:THE BEGINNINGAND DEVELOPMENTOF FORMAC The second reason is perhaps the very fact that F O R M A C was very early in a relatively new and unknown technical area. An enormous amount of our effort throughout the 7090/94 development had to be spent explaining to people what the system could do for them, and how it would enhance their productivity and the accuracy of their results. Although this activity was crucial, it deflected a large portion o f our resources from making significant improvements to the system. A third possible reason for F O R M A C ' s lack of growth is the fact that newer s y s t e m s q w h i c h had far more functional c a p a b i l i t y q w e r e "stand-alone" languages. Some users became persuaded that this was a better approach than adding to an existing language. Naturally I feel otherwise, but I don't believe there have been any studies comparing the merits o f the two approaches. A fourth reason is F O R M A C ' s tie-in to PL/I, which never became a major language. Clearly, PL/I never achieved its goal o f replacing FORTRAN and COBOL. Because F O R T R A N was much more widely used than PL/I for scientific computation, our initial decision to build the System/360 version on PL/I (instead o f on FORTRAN) limited its use. The later development o f the user-developed version o f F O R T R A N - F O R M A C on the System/360 was not sufficient to overcome the other difficulties.
9.8
IMPLICATIONS FOR THE FUTURE OF LANGUAGES FOR SYMBOLIC MATHEMATICS
As I have tried to indicate in this paper, FORMAC played a leading role in the initial stages of the field of symbolic mathematical computation. By the 1970s, the field of symbolic mathematics (including users, language designers, and implementors) had learned all that could be learned from FOPJV[AC in both positive and negative directions--most notably that a language (rather than just a package of routines) is important, but that adding the symbolic computation facilities to an existing scientific language is not crucial. The field has progressed very far beyond FORMAC now, and so there is nothing more that it can contribute. FORMAC will probably continue to be used by a small group of people, but certainly it has no significant future. ACKNOWLEDGMENTS 1 am extremely grateful to James H. Gfiesmer, who reviewed several drafts of this lengthy paper with great patience and great diligence. He did a superb job of pointing out both conceptual problems as well as small errors of fact and typographical errors. Seldom have I seen such care exerted in helping someone else write a paper! I am also very grateful to Michael Mahoney, the HOPL-II conference consulting historian, for helping me clarify issues, sharpen various points, and include material I might otherwise have overlooked. Brent Hailpem, Robert Rosin, and unknown referees were also very helpful in pointing out various flaws and omissions. Tim Bergin provided significant editing assistance. However, all flaws remaining in the paper are due to me and not to the very helpful referees.
REFERENCES [A. D. Little, 1965] FORMAC MARKET STUDY. Report to IBM, C-66891, Arthur D. Little, Inc., March 1965. IACM, 19661 Comm. ACM. Vol. 9, No. 8, Aug. 1966, entire issue. [Bahr, 1974] Bahr, Knat and Smith, J&~p.Tuning an Algebraic ManipulationSystem through Measurements, in Proceedings of EUROSAM 74, ACMSIGSAMBulletin, Vol. 8, No. 3, Aug. 1974, pp. 17-23. [Bahr, 1975] Bahr, Knut. Utilizing the FORMAC Novelties,ACM SIGSAM Bulletin, Vol. 9, No. 1, Feb. 1975, pp. 21-24. [Bemick, 1961] Bemick, M. D., Callender, E. D., and Sanford, J. R. ALGY--An Algebraic Manipulation Program, in Proceedings of the Western Joint Computer Conference, Vol. 19, 1961, pp. 389-392. [Bleiweiss, 1966] Bleiweiss,L. et al. A Time-Shared AlgebraicDesk CalculatorVersionof FORMAC, IBM Corp., TR00.1415, Systems DevelopmentDivision,Poughkeepsie,NY Mar. 1966.
FORMACSESSION
453
JEAN E. SAMMET [Bobrow, 1968] Bobrow, D. G., Ed. Symbol Manipulation Languages and Techniques, Proceedings of the IFIP Working Conference on Symbol Manipulation Languages, Pisa, Amsterdam: North-Holland, 1968. [Bond, 1964] Bond, E. R. et al., FORMAC--An Experimental FORmula MAnipulation Compiler, in Proceedings of the ACM 19th National Conference, 1964, pp. K2.1-I-K2.1-11. [Bond, 1965a] Bond, E. etal. Implementation of FORMAC, TR00.1260, IBM Systems Development Division, Poughkeepsie Laboratory, NY, March 1965. [Bond, 1968] Bond, E. R. and Cundali, P. A. A Possible PL/I Extension for Mathematical Symbol Manipulation, in Symbol
Manipulation Languages and Techniques, Proceedings of the IFIP Working Conference on Symbol Manipulation Languages, D. G. Bobrow, FEd.,Amsterdam: North-Holland, 1968, pp. 116-132. [Brown, 1963-1964] Brown, W. S., Hyde, J. P., and Tague, B. A. The ALPAK System for Nonnumedcal Algebra on a Digital Computer, Bell System Technical Journal, Vol. 42, No. 5, Sept. 1963, pp. 2081-2119; Vol. 43, No. 2, Mar. 1964, pp. 785-804; Vol. 43, No. 4, Part 2, July 1964, pp. 1547-1562. [Brown, 1966] Brown, W. S. A Language and System for Symbolic Algebra on a Digital Computer, in Proceedings of the IBM Scientific Computing Symposium on Computer-Aided Experimentation, IBM Corp., 320-0936-0 Data Processing Division, White Plains, NY 1966, pp. 77-114. [Brown, 1971]. •ALTRANUSER•SMANUAL(Sec•ndEditi•n)•Be••Te•eph•neLaborat••es••n•.•MurrayHiu•NJ••97•. [Clapp, 1963] Clapp, L. C. and Kain, R. Y. A Computer Aid for Symbolic Mathematics, in Proceedings of the Fall Joint Computer Conference, Vol. 24, Nov. 1963, pp. 509-517. [Collins, 1966] Collins, G. E. PM, A System for Polynomial Manipulation, Comm. ACM, Vol. 9, No. 8, Aug. 1966, pp. 578-589. [Crisman, 1965] Crisman, P. A., Ed., The Compatible Time-Sharing System, A Programmer's Guide, Second Edition, Cambridge, MA: MIT Press, 1965. [Cuthill, 1965] Cuthill, E., Voigt, S., and Uilom, S. Use t~f Computers in the Solution ttf Boundary Value and Initial Value Problems, Annual Progress Report, SR011-01-01 Task 0401 AML Problem 821-911, David Taylor Model Basin, Washington, DC, June 1965. [Duby, 1968] Duby, J. J. Sophisticated Algebra on a Computer--Derivatives of Witt Vectors, in Symbol Manipulation
Languages and Techniques, Proceedings of the IFIP Working Conference on Symbol Manipulation Languages, D. G. Bobrow, Ed., Amsterdam: North-Holland, 1968, pp. 71-85. [Engelman, 1965] Engelman, C. MATH-LAB: A Program for On-Line Machine Assistance in Symbolic Computations, in Proceedings of the Fall Joint Computer Conference, Vol. 27, Part 2, i 965, pp. 413--422. [Engelman, 197 i ] , The Legacy of MATHLAB 68, in Proceedings of the Second Symposium on Symbolic andAlgebraic Manipulation, S. R. Petrick, FEd.,New York: ACM, Mar. 1971, pp. 29-41. [Evey, 1962] Evey, R. J., Gdsoff, S. E, Sammet, J. E., and Tobey, R. G. FORMAC Preliminary Language Specifications, IBM, Boston Advanced Programming, Advanced Computer Utilization Dept., Data Systems Division, Dec. 14, 1962. [Griesmer, 1971] Griesmer, J. H. and Jenks, R. D. SCRATCHPAD/I--An Interactive Facility for Symbolic Mathematics, in Proceedings of the Second Symposium on Symbolic and Algebraic Manipulation, S. R. Petrick, Ed., New York: ACM, 1971, pp. 42-58. [Haanstra, 1965] Haanstra, J. W. FORMAC, Memo to P. W. Knaplund, IBM, April 12, 1965. [Hearn, 1966] Hearn, Anthony C. Computation of Algebraic Properties of Elementary Particle Reactions Using a Digital Computer, Comm. ACM, Vol. 9, No. 8, Aug. 1966, pp. 573-577. [Hearn, 1967] , REDUCE USERS'MANUAL, Memo No. 50, Stanford Artificial Intelligence Project, Feb. 1967. [Hearn, 1971] , REDUCE 2, A System and Language for Algebraic Manipulation, in Proceedings of the Second Symposium on Symbolic and Algebraic Manipulation, S. R. Petfick, Ed., New York: ACM, 1971, pp. 128-133. [Howard, 1967] Howard, J. C. Computer Formulation of the Equations of Motion Using Tensor Notation, Comm. ACM, Vol. 10, No. 9, Sept. 1967, pp. 543-548. [IBM, 1965] FORMAC (Operating and User's Preliminary Reference Manual), IBM Corp., No. 7090 R21BM 0016, IBM Program Information Dept., Hawthorne, NY, Aug. 1965. [IBM, 1966] DESCRIPTION OF TIME-SHARED FORMAC, IBM, Boston Programming Center, No. CC-257, Computation Center, MIT, March 1966, [IBM, 1967] PL/I-FORMAC Interpreter, IBM Corp., Contributed Program Library, 360D 03.3.004, Program Information Dept., Hawthorne, NY, Oct. 1967. [Martin, 1967] Martin, W. A. Symbolic Mathematical Laboratory, MIT, MAC-TR-36 (Ph.D. thesis), Project MAC, Cambridge, MA, Jan. 1967. [Martin, 1971] Martin, W. A. and Fateman, R. J. The MACSYMA System, in Proceedings t¢fthe Second Symposium on Symbolic' andAIgebraic Manipulation, S. R. Petrick, Ed., New York: ACM, 1971, pp. 59-75.
454
CHAPTER IX
PAPER:THE BEGINNINGAND DEVELOPMENTOF FORMAC [Morris, 1967] Morris, A. H., Jr. The FLAPLanguage--A Programmers Guide, U.S. Naval Weapons Lab., K-8/67, Dahlgren, VA, Jan. 1967. [Moses, 1967] Moses, Joel. Symbolic Integration, MAC-TR-47, Project MAC, MIT, Dec. 1967. [Moses, 1974] . , MACSYMA--The Fifth Year, in Pn)ceedings t~fthe Eurosam Conference, ACM SIGSAM Bulletin, Vol. 8, No. 3, Aug. 1974, pp. 105-110. [Neidleman, 1967] Neidleman, L. D. An Application of FORMAC, Comm. ACM, Vol. 10, No. 3, Mar. 1967, pp, 167-168. [Penn State, 1983] CFORMAC: CONVERSATIONAL FORMAC, The Pennsylvania State University Computation Center, Aug. 1983.
[Perlis, 1964] Perlis, A. J. and Iturriaga, R. An Extension to ALGOL for Manipulating Formulae, Comm. ACM, Vol. 7, No. 2, Feb. 1964, pp. 127-130. [Perlis, 1966] Perlis, A. J., lturriaga, R., and Standish, T. A. A Definition of FormulaALGOL, Carnegie Inst. of Tech., Pittsburgh, PA, Aug. 1966. [Petrick, 1971] Petrick, S. R., Ed., Proceedings of the Second Symposium on Symbolic and Algebraic Manipulation, New York: ACM, 1971. [Sammet, 1962a] Samrnet, Jean E. Project Description for Symbol Manipulation Compiler, internal memo, IBM, Aug. 1,1962. [Sammet, 1962b] _, Numerical Estimates for Justification of SYmbol MAnipulation COMpiler, internal memo, IBM, Aug. 13, 1962. [Sammet, 1963a] . FORMAC and NPL, internal memo, IBM, May 20, 1963. [Sammet, 1963b] .... Implementation of FORMAC for NPL, internal memo, IBM, Nov., 23, 1963. [Sammet, 1964a] _, and Elaine R. Bond, Introduction to FORMAC, IEEE Trans. Elec. Comp., Vol. EC-13, No. 4, Aug. 1964, pp. 386-.-394. [Sammet, 1964b] _, Proposed FORMAC Activity in 1965, internal memo, IBM, Oct. 12, 1964. [Sammet, 1965a] _, Updated Summary of Interest on FORMAC, internal memo, IBM, Sept. 27, 1965. [Sammet, 1965b] , Faults with FORMAC, internal memo, IBM, May 28, 1965. [Sammet, 1965c] ., Efficient polynomial manipulation capability for OS/360 FORMAC, internal memo, IBM, Mar. 23, 1965. [Sammet, 1966a]. _, Survey of Formula Manipulation, Comm. ACM, Vol. 9, No. 8, Aug. 1966, pp. 555-569. [Sammet, 1966b] ~ , An Annotated Descriptor Based Bibliography on the Use of Computers for Non-Numerical Mathematics, Computing Reviews, Vol. 7, No. 4, July-Aug., 1966, pp. B-I-B-31. [Sammet, 1966c] ., Survey of the Use of Computers for Doing Non-Numerical Mathematics, IBM Systems Development Division, Poughkeepsie Laboratory, NY, TR 00.1428, Mar. 1966. [Sammet, 1967] 0 Formula Manipulation by Computer, in Advances in Computers, Vol. 8, E L. AIt and M. Rubinoff, Eds., New York: Academic Press, 1967, pp. 47-102. [Sammet, 1968] , Revised Annotated Descriptor Based Bibliography on the Use of Computers for Non-Numerical Mathematics, in Symbol Manipulation Languages and Techniques, D. G. Bobrow, Ed., Amsterdam: North-Holland, 1968, pp. 358--484. [Sammet, 1969] , PROGRAMMING LANGUAGES: History and Fundamentals, Englewood Cliffs, NJ: Prentice Hall, 1969. [Sammet, 1971] , Software for Nonnumerical Mathematics, in MATHEMATICAL SOFTWARE, John Rice, Ed., New York: Academic Press, 1971, pp. 295-330. [Sammet, 1990] , Symbolic Computation: The Early Days (1950-1971), in Computers in Mathematics, David V. Chudnovsky and Richard D. Jenks, Eds., New York: Marcel Dekker, 1990, pp. 351-366. [Sconzo, 1965] Seonzo, P., LeSchack, A. R., and Tohey, R. G. Symbolic Computation of f and g Series by Computer, Astnmomical Journal, Vol. 70, No. 4, May 1965, pp. 269-271. [SHARE, 1983] SHARI3-FORMAC, No. 360D-03.3.01311, Aug. 1983. [Slagle, 1963] Slagle, J. R. A Heuristic Program that Solves Symbolic Integration Problems in Freshman Calculus, J. ACM, Vol. 10, No. 4, Oct. 1963, pp. 507-520. [Tobey, 1965a] Tobey, g. G. et al. Preliminary Specifications for FORMAL NPL (System/360 FORMAC), internal report, IBM, Jan. 28, 1965. [Tohey, 1965b] Tobey, R. G., Bobrow, R. J., and Zilles, S. N. Automatic Simplification in FORMAC, in Proceedings off the AFIPS Fall Joint Computer Conference, Vol. 27, Nov. 1965, pp. 37-52. [Tobey, 1966a] Tobey, R. G. Experience with FORMAC Algorithm Design, Comm. ACM, Vol. 9, No. 8, Aug. 1966, pp. 589-595. [Tobey, 1966b] , Eliminating Monotonous Mathematics with FORMAC, Comm. ACM, Vol. 9, No. 10, Oct. 1966, pp. 742-751.
FORMAC SESSION
455
JEAN E. SAMMET
[van Hulzen, 1974] van Huizen, J. A. FORMACToday,or What Can Happen to an Orphan, ACM SIGSAM Bulletin, Vol. 8, No. I, Feb. 1974, pp. 5-7. [Walton, 1967]Walton,J. J. TensorCalculationson Computer:Appendix,Comm.ACM, Vol. ! 0, No. 3, Mar. ! 967, pp. 183-186, [Xenakis, 1971] Xenakis,J. The PL/l--Formac Interpreter,in Proceedingst~ftheSecond SymluJsiumon Symbolic andAlgebraic Manipulation, S. R. Petrick, Ed., New York:ACM,Mar. 1971, pp. 105-114.
T R A N S C R I P T OF PRESENTATION
JEAN SAMMET." I want to start by expressing thanks to two people. One is Jim Griesmer, formerly from IBM, who was an enormous help in the preparation of the paper, and I want to give my thanks to Dick Wexelblat who prepared--from a physical point of view--the foils that you are about to see. He has far better capability than I do. If the intellectual content is bad, that's my fault but if the physical format is nice, it's his credit. (SLIDE 1, SLIDE 2) There are three phases of the work on FORMAC that I want to discuss. The first and major one from my point of view was on the 7090/94 in the time period of 1962 to 1965. Then, somewhat briefly, the System/360 on PL/I for some years after that, and then a little on the FORMAC 73, which was done outside IBM. (SLIDE 3) When I joined IBM, aside from being told to set up a group to do advanced R&D work in software, my boss said to me, "Do something in symbol manipulation." And that was the extent of the directive I got from him, and, in particular, that term was not defined. So I made a couple of false starts and then came up with an idea as described in the next slide. (SLIDE 4) The basic objectives I had for the system that eventually became known as FORMAC, were to provide a system that extended FORTRAN from a language point of view, with capabilities for symbolic math. It was to be practical, not experimental. I guess it was experimental in the sense that it was brand new and was something that had never been tried before because it was to allow for both symbolic and numerical mathematics. Finally, what I wanted to do all along--r-and I ' m not sure I ever said this explicitly--was to sort of reverse the clock. What had happened was that prior to the use of computers, a great deal of analytic mathematical work had been done by people by hand. Then computers came along and they were obviously great number crunchers. So the analytic work that had been done by people in using formal differentiation or any kind of mathematical expressions or integration then reverted to being done as numerical computations because that was what was being done on computers, and I wanted to reverse that.
"The Beginning and Development of FORMAC (FORmula MAnipulation Gompiler)" Jean E. Sammet
Programming Language Consultant ACM SIGPLAN HOPL-II Conference April 1993
SLIDE 1 456
THREE PHASES OF WORK Version
Mlt[Qr Time Period
7090/94 (FORTRAN)
(1962-1965)
SystenV360 ( P L / 1 )
(1964-1968)
FORMAC 73 (PL/I)
(1970 ft. - -
(outside IBM)
SLIDE 2 CHAPTER IX
TRANSCRIPT OF FORMAC PRESENTATION
MY BASIC OBJECTIVES FOR THE PROPOSED PROJECT (1962)
DIRECTIVE TO ME FROM MY MANAGER "Plan a symbol manipulation project"
Provide a system that is--. • a language extension of FORTRAN with capabilities for symbolic mathematics. • practical for problems involving symbolic and numerical mathematics • useful to applications being done with numerical approximations where analytic techniques are preferable
but...
the term "symbol manipulation" Wall undefined
SLIDE 3
SLIDE 4
(SLIDE 5) There were a lot of terms that we used then and which were all pretty much equivalent. It depended on what you wrote or spoke, and who you talked to, but you can see the list that was there. The more common current terms are "symbolic mathematics" and "symbolic computation," but if I use any or all of these in the course of the talk, they are all meant to be equivalent. Many of you are saying, "What the devil is FORMAC, and why is it different?" So the next slide is going to attempt to explain this. (SLIDE 6) On the left we have a real complicated FORTRAN Program. [sarcasm] If I take (9 + 4) x (9 - 4), unless I've made a gross mistake, we'll get 65. So what? FORMAC is very different. We are dealing with symbols here; we are dealing with mathematical expressions. The word L E T was simply a key word that we used from a language or compiling point of view. We said suppose that the variable A has the value of the symbolic variable X; B was assigned Y; and, now C was going to be (A + B) * (A - B). And the result would be, depending on which form you preferred, X 2 - y 2 or (X + Y) * (X - Y). There was an internal representation for that, but C was assigned the value of X 2 _ y2. Now, for almost any project--regardless of whether you are in a large company like IBM, or applying for a grant, or even trying to get some seed money from any organization--you need to justify what it is that you are doing.
SOME EQUIVALENT TERMS
FORTRAN vs. FORMAC EXAMPLE
Then Symbol manipulation Formula manipulation Tedious algebra Formal algebra
!l
FORTRAN
FORMAC
II
X-
r.,wl'A-x
,
!! ,, 4 c - (X+a)* (&-a)
I.,WX' B ,, Y raft c - (A+B)* (A-e)
C ~ 65
C ~-- (X+Y)*(X-Y)
Nonnumedcsl mathematics
Current
! Symbolic mathematics Symbolic computation
SLIDE 5 FORMAC SESSION
[
II
c~x=.y=
lL SLIDE 6 457
JEAN E. SAMMET
EXPECTED USAGE AND NEED FOR JUSTIFICATION (1 of 2)
EXPECTED USAGE AND NEED FOR JUSTIFICATION (2 of 2)
Some Application Areas
Some Mathematical Areas
Astronomy Chemistry Meteorology Physics (many kinds) Strus analysis
Analytic differentiation Differential equations Laplace & Fourier transforms Matrix manipulations Series operations
SLIDE 7a
SLIDE 7b
(SLIDE 7a) So we did a lot of exploring of areas in which such a system might be useful, and I ' v e listed four or five here. There is a longer list in the paper. Here, they are specifically listed by application areas, as distinguished from the next slide, which shows the mathematical areas, which, of course, can be used in any or all of the preceding application areas. (SLIDE 7b) Now, the next slide will give you a time scale and some cost information. (SLIDE 8) I wrote the proposal for this earlier in 1962, and we had fairly detailed and complete language specifications by December 1962. We did most of the system design in the first half of 1963, and had almost all of the coding finished in December 1963. The integration and testing went on over the next year, as you would expect, and it was operational in December 1964. As best my records will indicate, and I have boxes and boxes of records on this, there were approximately 20 person-years involved. But, that included a lot of documentation, and we really did do a lot of documentation, because implicit in that was some of the justification that we also had to do. There were lots of other activities--for example, user interaction forecasts, and attempts to explain to people what it was we were doing, because this was brand new and therefore it was very hard for people to understand what such a system could do in any way, shape, or form. (SLIDE 9) I want to talk about systems that existed at the time. Before I even get to these, let me point out that all the systems that you have heard of today are not on this list, because they didn't exist. The earliest of them came into existence in the mid-60s and by that time we were well on our way; we had finished the 7090 version, and as you will see in a few minutes, we had started on the PL/I version. So if you note the absence of M A C S Y M A or Mathematica, or Maple or REDUCE, or anything else, it is because they all came afterwards. But, I do want to talk somewhat about some of the systems on the slide, none of which had any real influence on what we did. The first, interestingly enough, is called ALGY, which almost nobody has heard of. It is described very briefly in my 1969 book on programming languages, and if anything had an influence, it was that. It was a really neat little system that had some interesting commands in it. I think they implemented it, but they certainly never did anything with it. Then there were two systems and I - - a s many of you k n o w - - a m a purist with regard to language, and something is either a language or it is not. And just because it is not a language doesn't mean it's bad--it's just not a language. It's a taxonomy issue, not a value judgment. ALPAK was a system to manipulate polynomials. It was a series of subroutines added to FAP (an assembler on the 7090) that was being done at Bell Labs. PM was being done initially at IBM, and
458
CHAPTER IX
TRANSCRIPT OF FORMAC PRESENTATION
SCHEDULE AND COSTS Language specifications .. System design . . . . . . . . . . Coding (heslcally finished) Integration & testing Operational . . . . . . . . . . . . . . . . . . .
Dec. 1962 Jan. - J u n e 1963 Dec. 1963 J a n . - April 1964 Dec. 1964
Approximately 20 person.years, Including • much documentation • other activities (e.g., user Interaction & forecasts)
SLIDE 8
RELATED SYSTEMS (...though none had real influencel) • Eady language: ALGY • Systems (not languages): ALPAK, PM • Contemporary languages: ALTRAN, Formula ALGOL • Minor contemporary languages: Magic Paper, MATHLAB, Symbolic Mathematical Laboratory
SLIDE 9
that was another system to manipulate polynomials. And those people were very concerned about algorithms for how you handle polynomials efficiently. Then the ALPAK people at Bell Labs moved into the language concept and, as we did, added concepts to FORTRAN to produce ALTRAN, but still limiting the capability to the handling of polynomials or rational functions. It turns out that has a profound effect on what you do internally and from an implementation point of view. Polynomials, for those of you who maybe don't remember the mathematics, are simply something of the form A n + B m h y o u are simply dealing with variables to powers, products, and divisions of that, but it does not allow for trigonometric functions such as sine or cosine or exponential functions, like e x or any of those things. The implementation of dealing just with polynomials or rational functions is orders of magnitude easier than allowing for these other things. The other major contemporary language research work that was going on at this time, was Formula ALGOL. That was done under the guidance of Al Perlis at Carnegie Mellon. It is certainly not a surprise that, when I started this, I decided to add the language capabilities to FORTRAN, and when AI Perils started this, he decided to add the language capabilities to ALGOL. I think both of those are quite obvious. Formula ALGOL was the closest in concept to what we were doing, but even then we had very many differences--in particular, a different philosophy on simplification, which I will talk about a little later. There were some other minor contemporary languages that never became overly significant: Magic Paper done by Lew Clapp here in the Boston area, MATHLAB was done by Carl Engelman at MITRE, and Symbolic Mathematical Laboratory being done by Bill Martin as a Ph.D. thesis at MIT. MATHLAB and Symbolic Mathematical Laboratory had significant influences and eventually--I think, although Joel Moses might disagree with me--sort of metamorphosed and in some way eventually became the MACSYMA system. Now, let me show you, in the next few charts, the kind of capability that existed. (SLIDE 10a) The statements on the left are the FORMAC commands, and they were put in the middle of the FORMAC programs. The L E T statement was really just an assignment statement for symbolic variables. SUBST allowed you to do what you would expect, namely replace any variable by any other variable or an expression. EXPAND was to remove parentheses. C O E F F obtained the coefficient, and the PART was a shorthand for partition, and allows you to chop up expressions in various ways. (SLIDE 10b) The first of these, the EVAL, is probably the most important of the commands that are in there aside from the L E T commands, which are just the symbolic assignment statements. EVAL
FORMAC SESSION
459
JEAN E. SAMMET
FORMAC Executable statements and functions (1 o f 4)
Statementa yielding FORMAC variables z,w, . . . . . . constructspecifiedexprmione (assignment statement for symbolic variables)
FORMAC Executable statements and functions (20t4)
Statements yielding FORTRAN variables IWikT.,. . . . . e v a l u m e x p r m l o n for numerical values
smu~r . . . . replace variables with expressions or other variables
I n ' l ~ . . . . compare two exprmions for equivalence or Identity
m a w . . , remove p . r m t h e m c o r n . . . . obbdn the coefficient of a variable PssT . . . . . separate e ~ s i o n s into terms, f~tors, exponents, arguments of functions, etc.
rx~m . . . . . detmnine dependenoe relations or existence of varlabkm
SLIDE lOa
c l m m s . . , count words, terms, or ttaotom
SLIDE 10b
allowed us to evaluate the expressions for numerical values. The EVAL command was crucial, because our philosophy said that one wanted to generate these formal mathematical expressions, but then in many cases--in the practical engineering and mathematical examples---one wanted to evaluate them. And in essence, what we did was implement EVAL as an interpreter at object time. I will have something to say about that at the banquet tonight. The point of the EVAL command was to provide a seamless capability to the user wherein he/she put in the problem, generated these vast mathematical expressions, and then evaluated them numerically and came out with a number. The point being that they could not do the algebra by hand. There were many cases in which people spent not only hours but days, weeks, months, and in some cases even years, doing what we call "tedious algebra." The same kind of things that people did numerically before there were computers, were still being done by hand from an algebraic point of view. The MATCH command allowed you to do what it indicates, trying to compare expressions for equivalence or identity; there is a big difference, and it is quite significant in systems of this kind, as to whether you really have identical expressions or whether they are just mathematically equivalent. FIND and CENSUS are not very interesting; they are important to us, but they are not overly interesting. (SLIDE 10c) The first two of these just got us over a hurdlewto get to and from BCD (Binary Coded Decimal), which was the internal format of the machine--and these were needed for the input and output. The O R D E R was to do some kind of sequencing. AUTSIM was a very crucial thing and I'll say more about that later, because it had something to do with the automatic simplification. ERASE was to get rid of expressions which we didn't need. In that sense, it's like garbage collection in Lisp or something like that. And the last one (FMCDMP) was just a debugging tool. (SLIDE 10d) The FORMAC differentiation was crucial; that may be of some interest to you. As early as 1954--that's not an oral misprint, 1954, before there were many computers around--there were two master's theses done to do formal differentiation on a computer. One was done at Temple University by a student under the guidance of Grace Hopper, and it was done on a UNIVAC I. The other was done at MIT on Whirlwind. These were master's theses; now I think they are given as overnight homework exercises to freshmen. But at that time, it was quite a tour de force. We had differentiation, we had these other things, trig functions and so forth. You note the complete absence of integration. That was far beyond the state of the art at the time we started thismthe heuristics and the algorithms came much later, first with Jim Slagle, then with Joel Moses, then with Robert Risch. So that's why we never had integration. It was far too difficult, and for any of you who remember college calculus, you will perhaps recall that differentiation is a very straightforward algorithmic
460
CHAPTER IX
TRANSCRIPT OF FORMAC PRESENTATION
F O R M A C Executable statements a n d functions
F O R M A C Executable statements a n d functlons
(3 of 4)
(4 of 4)
Miscellaneous Statements ac~coM.., convert to BCD form from internal form [needed for output] xlracml.., convert to Internal form from BCD form [rmd~d for Inputl o~mml . . . . specify sequencing of variables within exprmlomt Ao,t'8;nll... control arithmetic done dudng automatic simpUfleation muum . . . . eilmlnab expressions no longer needod . . . symbolic dump
SLIDE lOc
Functions wecDzl.., ]mcotm... ~rAc... ]mcm,'A...
differentiation combinatorial factorial double factorial
Trigonometric, logarithmic, and exponential functions
SLIDE lOd
process, in which you write down a whole bunch of rules and therefore you can easily program a computer to do. At that time, at least, to integrate required a fair amount of intellectual gestalt as to what rules you were going to apply to the expressions. (SLIDE 11) Simplification is one of the issues in which people who work in these systems have a lot of difference of opinion. Most people would agree that if you end up in a situation where you are multiplying by 0, you want the result to be 0. If you multiply by 1 you want to get rid of the 1, and if the internal representation turns out that these variables are not in the same order, there should be something which will put them in the right order and have the system recognize this as being the same, and get 0. Now you get down to something like A * (B + C), and it's not clear what simplification means in that case. It may mean nothing; you may want it in that form, or you may want it in this expanded form (AB + AC), and it depends on the particular point in the activity in the program that you are doing this. One of the major differences in philosophy between Formula ALGOL and FORMAC was that we did a large amount of this automatically and gave the user a little bit of control over what could be done. Formula ALGOL insisted that the user specify exactly what it was that he wanted done throughout. (SLIDE 12) There are some special issues and some special problems that we encountered. The first one had to do with exceeding available storage, and we coined a version of Parkinson's Law. You know that the original Parkinson's Law said that "costs expand to exceed the amount of money available." A later version then became "the workload expands to exceed the amount of time available." And we had one that said "the size of the expression expanded to exceed the amount of storage available" because these things ate up storage like it was going out of style. Eventually we developed some better techniques and this is described in the paper. Even though we developed some better techniques to help save some storage, nevertheless they did eat up an enormous amount of storage. The next issue was the philosophy of simplification and I've already described that. Now, with respect to interactivity, I ask you to try and put yourself mentally back in the period of 1962 or 1963. There essentially were no terminals. By around 1964 there was one-----4think it was the 2741. There were some terminals you could hook up to a mainframe, but they were really just typewriters, albeit connected to the mainframe; it was all very primitive. So what we were doing was in batch. There was some debate on whether anybody could really do this kind of problem in a batch mode. Well, I ' m here to tell you that there were an awful lot of people, hundreds of them, who knew enough about what their problem was, that they could indeed write a batch program to get reasonable answers,
FORMAC SESSION
461
JEAN E. SAMMET
S I M P U F I C A T I O N : An InMrssting Issue 2*0 Jk*l JLIS - ]UL
--~o --)JL --~0
2 " (B4.C)
--~ ???
SOME SPECIAL ISSUES • Exceeding available storage • Philosophy of simplification • Interactive version • Market forecasting • Form of output
... not clear which is wanted: & * (B+c) JLB + JLC
SLIDE 11
SLIDE 12
either in a truly symbolic form or in numeric form. Some problems you couldn't because you needed to know what the expression looked like as you went along to know what the devil to do with it. And for that, you needed an interactive version, and as part of our experimental work, we developed a fairly simple version. We took the FORMAC on the 7090, and we did enough manipulation that people could do this on an interactive version. Market forecasting may strike you as being a strange thing to occur in this paper, but there is some more significant discussion about it in the paper. At the time, there was no forecasting for software, at least not within IBM and I assume nowhere else. They were very busy going around to determine if they were going to build some kind of a new box, how many people might buy it, and what they should charge. But since there was no charging for software, there wasn't much forecasting about its use either. And we were asked to be a "guinea pig" for some of this, and indeed we were. The results were not very conclusive, but at least we helped get IBM and others involved in the forecasting business. The form of output I will come back to with a couple of horrendous examples in a few minutes. (SLIDE 13) Now, let me go on and talk about the PL/I version. Naturally, before you finish the first version, you've got to be looking at the second one. Our objective was to use what we had learned with our experience on the original one, to improve the basic approach, add new commands, and clean up some of the ones that we had. And, more importantly, to add the language capability to PL/I instead of to FORTRAN. The reason for doing that, was at that t i m e b a s you may recall Fred Brooks noting in his keynote address--the original IBM strategy was to replace FORTRAN and COBOL by PL/I, and I felt we ought to be good corporate citizens and support that goal, which I thought was a pretty good goal; I ' m not trying to knock it in any way. It didn't succeed for a whole variety of reasons, but that's a different issue. We wanted to support that strategy so we were going to add this capability to PL/I. (SLIDE 14a) Imagine if you can, the time when you got pages and pages of output from a highspeed printer--and I saw engineers getting 20 pages of stuff that looked like that, or worse because it went further across the width of the paper. And they were absolutely delighted because they could go in and find some coefficients of some expressions and some new patterns that they didn't know about, and they could see. And they were thrilled with this stuff. It gives me a headache every time I look at it. But, I ' m not exaggerating when I say that lots of engineers and mathematicians with problems would get 20 pages of output for a single computer run, and be thrilled because it told them things about their problems and gave them data that they didn't have. These were the cases in which people did not want to evaluate--they really wanted to see what the expressions looked like. We 462
CHAPTER IX
TRANSCRIPT OF FORMAC PRESENTATION
PL/! VERSION ON IBM SYSTEM/360
Objective~ • Use experience to Improve basic approach • Add to PLJI instead of FORTRAN
Reason for changing languageev-• Support the IBM strategy of supplying PI./t to replace FORTRAN and COBOL
SLIDE 13 recognized this was pretty gruesome no matter how happy they were. We certainly weren't happy. After all, we had to do some debugging with this stuff ourselves. (SLIDE 14b) So, we improved matters a lot with regard to the PL/I format, because we got the exponents up where they belong and we got rid of the asterisks to denote the implicit multiplication. Things were a little bit better. Now, there were other people around that time who were doing much more work, and in fact better work, on getting better output, but that's not where our main thrust was. We wanted to get something that was rather more readable, but we weren't prepared, and we simply didn't have the resources to go as far as some other groups were doing at that time. (SLIDE 15) Let me go on to the last chart, which is my attempt at evaluation here. FORMAC, I think, had somewhat of an influence, but it was rather indirect. And I'm not sure what Joel is going to say; he may or may not choose to comment on that particular aspect of it. FORMAC was the first real formula manipulation language to receive significant usage. And I emphasize the word language because ALPAK at that time, which was the polynomial manipulation system developed at Bell Labs, was getting significant usage. But that was a series of subroutines added to an assembly language. The language that was represented by FORMAC was the first of the languages. Even ALTRAN came somewhat after. I became convinced--and I believe everybody else that followed us in any way agreed--that it was a language, not just subroutines, that was important. One of the areas that I felt
r
High-speed printer output from 7090/94
XI11+2*X**2/21+2*X**3/31 -4*X**5/51-8*X**6/61 -8*X**7171+Z6*X**9/91
High-speed pdnter output from PL/I-FORMAC TAY'Z,OR -
X /
11
4. 2 X 2 /
--;-;;-;-;;.-:-;
2!
:::::::::::::::::::::::::
SLIDE 14a FORMAC SESSION
;--;;;--\-;;-;;;-i;;;-3.V?
31
..... ............. ............
+32*X**10/101+32*X**11/111
-64*Z**13/131-128*X**14/14! -128*X**15/15!+256*X**17/17! +512*X**18/18!+512*X**19/191
+ 2 X3 /
;--;?--
.........
V ;;,; .......... ........................
SLIDE 14b 463
JEAN E. SAMMET
EVALUATION • I n f l u e n c e - s o m a was only Indirect • A language (not Just subroutines) Is important • Symbolic mathematics can be done in s practical way • Rational arithmetic • ACM SIGSAM
SLIDE
15
strongly about, and essentially nobody that followed us did, was that I felt that the language capability for the symbolic computation should be added to an existing language. I may have said that earlier, but I want to emphasize it here. One of the basic philosophies that we had was that we wanted to add this type of formal capability to an existing language. The issue was not so much which language but to a language. I believe that all of the people who followed us supported the concept of using a language but, I believe, in almost every case used a stand-alone language. That is to say, they did not choose to add to an existing language. And that's a matter of belief. I continue to believe that all these systems should add to an existing language because the user of these systems tends to be doing both numeric and nonnumeric work. And if the user is familiar with an existing language--and I don't care if it's FORTRAN or PL/I or Ada or whatever--then I think they ought to have this kind of formula manipulation capability added to that language rather than as a stand-alone language. But again, that is a matter of a philosophy that I have, that most people simply do not agree with. The next thing that was clear from what we did, was that symbolic mathematics could be done in a practical way. Primitive as this system was, and as dreadful as its 7090 output was, it really did produce useful results for a number of users. Before I talk about the last two points, I want to mention something which is not on a slide. I want to say something about what turned out to be FORMAC 73. After the PL/I FORMAC was done, IBM dropped all interest. In both cases, the systems (7090/94 and the PL/I version) were made available as what were then called Type III programs. This is before the days of unbundling, so these systems were being given away. IBM at that time, categorized software systems into a number of groups. Type I programs were the compilers and the operating systems, which were the major systems given away and had full major support. Type II systems were some application programs that got good support. Type III programs were given away on a "user beware" basis. That is to say, if the developing group in IBM wanted to make it available to the users, they could do that. No problem, but the user had to understand that they were not going to get any support officially from IBM. Again, if the developing group chose to provide support, then that was all right too. That was a management decision, and we supported this to the hilt. After the PL/I-FORMAC was done and released, IBM really dropped all interest. The development group, which by that time I was no longer managing, ceased to exist and it sort of faded. Then people in SHARE picked this up, modified it, improved it for PL/I, and made it available through SHARE. Some people in SHARE-Europe also put the PL/I version back onto FORTRAN. In other words, using the additional capabilities they put that back onto FORTRAN. Now, let me talk briefly about rational arithmetic, which I confess to feeling very proud of as being one of the contributions that had been made, because it's something people don't think of very often. 464
CHAPTER IX
TRANSCRIPT OF DISCUSSANT'S REMARKS
One third (1/3) is a rational number, but .33333 is not. And the reason that this got put into the system was that when we did the original testing, all we had were some very primitive examples where you didn't need anything but assignment statements. So you were multiplying and dividing expressions, and the coefficients for many of these systems are of the kind of things that you saw before--they had a pattern. They may have had something factorial as the coefficient, or they go up as 3 * 5 and then 5 * 7, and things of that kind. I did the hand calculations to check out what it was that the systems were generating, and nothing matched. So, finally it turned out that my arithmetic was wrong in most cases, but it also became perfectly clear that the output that we were getting was virtually useless because in expressions of this kind--and if we could go back for a minute to slide 14B--you will notice that the denominators are all factorial while the numerators are simply single digits. In many of these kinds of expressions, they turn out to be things where you are multiplying. As I say, one coefficient might be 4 * 5 and the next is 5 * 6 and so on. If you multiply that out, you lose all the pattern that is inherent in things of that kind. So we put the rational arithmetic in because we felt you couldn't see what was going on without it. The last factor (on Slide 15) that I think was significant that came out of the FORMAC effort--and you may be surprised that I list that--is ACM SIGSAM. That came about for the following reasons. IBM then, was very concerned about who its employees spoke to in a technical and professional sense. They were concerned about giving away secrets and this kind of thing. Unlike academia, and unlike some of the research-oriented organizations that existed, I couldn't really--legally--just pick up the phone and call someone at a university. That was too bad, but I also couldn't really just pick up the phone and call Stan Brown at Bell Labs and discuss something--that was sort of a "no no." I felt there needed to be an umbrella organization of some kind which would enable us to legally meet, discuss, have technical meetings, and so forth. So I eventually (through a series of other circumstances) wrote to George Forsythe, who was then the President of ACM, and said, "I don't know what a Special Interest Group is, but I think that maybe I'd like to see what has to be done to form one." He wrote back and said "you are now the Chairman." Things are a little more formal now! And so, I founded the ACM SICSAM, which is what it was called at that time. We started with a newsletter of which Peter Wegner was the first editor. We held a conference in 1966, which produced an entire issue of the ACM Communications; this was the first real major attempt in getting all these kinds of people together in one group to present what they were doing. Since then, the community has been fairly cohesive under the leadership of a number of people that came after me with regard to SIGSAM. There have been other organizations, other activities, and so forth. But I'd like to think that SIGSAM--which was certainly motivated by my desire to discuss FORMAC with other people in a legal sense--was one of the contributions that came out of the FORMAC effort. T R A N S C R I P T OF D l S C U S S A N T ' S R E M A R K S
SESSIONCHAIR,TIM BERGIN: Our discussant is Joel Moses, who was a graduate student in the AI group of Project MAC from 1963 to 1967. He worked on FORMAC in the summer of 1964 and did his Ph.D. research on symbolic integration, from both a theoretical and practical perspective. He is now the Dean of Engineering at MIT, having been department head of Electrical Engineering and Computer Science from '81 through '89, and associate head for Computer Science and Engineering from '78 to '81. He was also a Visiting Professor at the Harvard Business School in '89 and '90. Joel is a member of the National Academy of Engineering and a fellow of the American Academy of Arts and Sciences. He is an IEEE Fellow and the developer of the MACSYMA system. His cmTent interests are the architectures of large and complex systems.
FORMAC SESSION
465
JOEL MOSES
JOEL MOSES: I am pleased to be allowed to make comments on Jean's paper. Actually, having been here all morning, there are some other papers I would like to comment on too! Let me start off with the Lisp paper. Guy Steele made the point that we had unstable funding at MIT and that's the reason people left. Well, I don't know about that. I was responsible for funding for much of that time, and we had relatively stable funding, between '68 and '82. The only reason we stopped funding the MACSYMA project is because I became department head in '81 and I just couldn't hold the group together while fulfilling my administrative duties. MIT licensed it; unfortunately it was to Symbolics, but that is another story. But in the meantime we had very good funding and were able to maintain a lot of support of Lisp development. Of course, MIT is an educational institution and we do train people who are supposed to leave--most of them in any case. The major emphasis in Jean's paper is that FORMAC was different because it was a language rather than a collection of subroutines for formula manipulation. Anybody who has known Jean as long as I have, which is now about 30 years, is always concerned about Jean's interest in what's a language and what's not a language. In any case, I thought long and hard about why my colleagues in the early '60s who worked in formula manipulation, Tony Hearn, George Collins, and Start Brown, did things in terms of packages rather than as languages. I think it has something to do with who they thought the users would be. Tony was building REDUCE for his friends who were theoretical physicists. They needed to do Feynman diagrams; Feynman diagrams are this great discovery in the late '40s of how to do work in quantum electro-dynamics, essentially by doing integration of rational functions. And then you get logs and you integrate these logs, and things get very complicated very quickly. In any case, he had a very clear-cut user community. George Collins was building a system largely for himself. His Ph.D. thesis, in 1956, was essentially on a system which proved theorems in plane geometry by converting the theorems into systems of polynomial equations. I don't know who Stan Brown viewed as his community; probably his theoretical colleagues at Bell Labs. In any case, in each of those three situations one could conveniently make the assumptions that the user was relatively sophisticated, the problems were extremely time consuming and had a relatively simple formulaic structure such as polynomials and rational functions. I think FORMAC was interested in a different community. I think they were interested more in engineers than scientists, at least engineers as well as scientists and mathematicians. These are users whose problems were more diverse and possibly not quite so gigantic all the time. Mathematicians can generate problems which are unbelievably large. I once calculated the number of terms in a solution, if we could ever figure it out, of a particular problem to be 10 to the 120. This is not the assumption that I think could be made about the majority of users of FORMAC. To attract such users, a good front end was needed, in order to make the experience not too cumbersome. We can argue about whether the front end has to be an extension of a popular language, as Jean indicated just now, or whether it could be a special-purpose language. Nevertheless, I think it was very important to attract the variety of users, the small- or medium-size users as well as some large users, to have an attractive front end in the system. Remember that when FORMAC was implemented, computing was done in a batch environment, and, therefore, I think an extension of PL/I or FORTRAN makes a lot of sense in that context. Most of us who worked a little bit later, when we did have nice linguistic front ends, basically recognized that in a time-sharing environment you really want to have a different kind of a language. Since there wasn't a particularly appropriate language to extend, we built our own. Eventually, many of us gravitated to Jean's view about the user community and the need for front ends, especially so in the MACSYMA system. I'll talk a little bit about that later. I think Jean rightfully complains that IBM didn't give her and FORMAC sufficient support to continue to develop the 466
CHAPTER IX
TRANSCRIPTOF DISCUSSANT'SREMARKS
system. On the other hand, the imprimatur that IBM did give FORMAC helped the rest of us obtain support for our activities, because IBM was a monopoly and everybody then knew that if IBM said this was OK, then it must be so. Jean is correct in pointing out the precursors of MACSYMA were MATHLAB, Carl Engelman's package; the Symbolic Mathematical Laboratory, Bill Martin's work; and the program that I did on integration. The first talk I ever gave was titled "Moses on SIN." My program was called SIN for Symbolic Integrator, because my predecessor's program was called SAINT. Slagle is a Catholic and I am not. Anyway, it was clear to Martin, Engelman, and me in '68, that we were aiming at both a large number of potential users from engineering as well as education. We had as our goal, even then, that college students and even high school students would use these systems, as, of course, they do now. At the same time, we wanted a system which was as fast as the fastest of the existing packages, REDUCE and ALTRAN, and, therefore, could attract mathematicians and physicists with their gigantic problems. So we built a front-end language with an expression display by Bill Martin, which was the state of the art for many years, and we concentrated on very efficient formula representations. We also built an enormous amount of code for the various algorithms we felt were necessary in a universally useful algebraic system. We worked in Lisp as did Tony Hearn with REDUCE. His work was done at Stanford, and later at Utah. Jim Griesmer and Dick Jenks worked for IBM at Yorktown Heights on the SCRATCHPAD system in Lisp as well. This gave us great programming flexibility at an admitted cost of possible a factor of 2 in space, and a comparably large factor of time. We, as I think is noted in the Lisp paper, developed MacLisp to deal with the time issue. We couldn't live with the original cost of doing arithmetic in Lisp, which was, I think, a factor of 30 slower than FORTRAN when we started. We got it down to maybe a factor of 2 or so by making appropriate declarations. We were memory hogs, some of the largest memory hogs in the world. In fact, the big physical memories that were bought by MIT in the '70s, were bought for us. Although other people used them, the excuse was always the MACSYMA project. Memory prices were declining, and address spaces were growing, although not as fast as we liked. All of that allowed us to continue forefront research for a long time. Some of the more recent systems, such as Maple and Mathematica, are written in C, rather than Lisp, getting some greater efficiency than we got with Lisp. Mathematica initially had a nicer front end than any of the other systems. That attracted a very broad class of users, some of whom have very little interest in formula manipulation. The key advantage that these two systems have is that the algorithms stabilized over the last 30 years, and the programming flexibility in Lisp is not as critical today as it was for us. For example, in MACSYMA, we created three new algorithms for the greatest common divisor of two polynomials. We continually had to develop things, and we wanted to have a system which gave us the ease of programming that Lisp provides. Let me get back to FORMAC. Jean's memory of the summer of 1964 is that I spent it on this project, working for Jean, running comparisons between FORMAC and Lisp base code. My memory was of my attempts to convince Bob Tobey and others in the group to add more functionality to FORMAC. In particular, I wanted to have a pattern-matching facility so that users could program their own simplification rules in addition to the built-in ones. Alan Perlis was doing something like this at CMU in Formula ALGOL, but I didn't know this, since there was so little communication between groups at the time. And, as Jean pointed out, one of her achievements in the FORMAC period was to create a group called SICSAM--a Special Interest Committee, before the Special Interest Group---and to lead the ! 966 conference where the community met for the very first time. You can all see now how Jean accomplished all this. She doesn't take "no" for an answer. I recall that once she got a gift. I don't know what the name of it is, but it is a toy where you have four of these aluminum balls, which knock each other out of position. I thought this was a perfectly appropriate gift for Jean because she FORMAC SESSION
467
TRANSCRIPT OF QUESTION AND ANSWER SESSION
was always great at knocking heads together. And I believe FORMAC represents the best of the head knocking. Thank you.
TRANSCRIPT OF QUESTION AND ANSWER SESSION CHARLES LINDSEYmUNIVERSITYOF MANCHESTER: Was the M A T C H operation equivalent to what we now know as unification? SAMMIET: I ' m not sure what he means by unification so I can't answer the question.
MOSES: Robinson's paper on unification came out in '63 and by that time the FORMAC design was pretty much frozen. SAMMET: The M A T C H command was really very trivial. Remember that when you are generating expressions in this kind of thing, you have no idea what the expression is going to look like. It's the symbolic equivalent of an equals test in a numeric computation. You generate a number, you don't know what the number is, so you ask whether it is equal to 17, if that happens to be of interest to you. Well, we would generate two expressions and try and find out whether or not they were the same. And there are two different ways in which they could be the same. One is that they are physically identical, that is to say, bit matching, And the other is whether they are logically the same, for example, A * (B + C) is logically equivalent to AB + AC but is certainly not equivalent on a bit match. So the M A T C H is just really elementary conceptually. HERBERT KLAERENmUNIVERSITYOF TUBINGEN: During the FORMAC preprocessor development, was it ever discussed to make the translation process to FORTRAN user programmable, so people could extend or change the formula manipulation capabilities?
SAMMET: I can't honestly remember whether we discussed it, but if we did, we certainly would have said no. That is to say, we were not trying to make an extensible system in any meaning of that word whatsoever. The user was going to get what we thought the user ought to have--with a few exceptions. There was some flexibility in the automatic simplification and there were some things that the user could put in ofblock. I think, for example, the expansion of a factorial was one of them. So, for example, the user had the option of asking for 7 factorial to be displayed as 7!---or whether the user wanted that multiplied out. That was one of the options that the user had in the automatic simplification. But, no, we weren't going to give the user the chance to extend this. TOM MARLOW---SETON HALL: Does the move to make symbolic languages work in a standardized interface/environment such as Windows address your concerns about language extension in any way, at least as far as the issues of familiarity in front end? SAMMET: I ' m not sure. Either one has a standard language or one doesn't. Whether it runs under Windows or UNIX or DOS strikes me as being a separate issue. The whole issue of the portability of environments and whether a particular language or compiler (or anything else) runs under that environment, in my mind is a separate issue.
BIOGRAPHY OF JEAN E. SAMMET Miss Sammet has a B.A. (Mathematics) from Mount Holyoke College and an M.A. (Mathematics) from the University of Illinois. From 1955 to 1958, Miss Sammet was the first group leader for programmers in the engineering organization of the Sperry Gyroscope Company on Long Island. She taught what were among the 468
CHAPTER IX
BIOGRAPHY OF JEAN E. SAMMET
earliest computer courses given for academic credit. In 1956-1957, she organized and taught graduate courses entitled "Digital Computer Programming" and '~AdvancedDigital Computer Programming" in the Graduate Applied Mathematics Department at Adelphi College on Long Island. (By today's standards, those were very elementary courses in basic programming and coding, using UNIVAC and the IBM 704.) During the second year she taught those courses (1957-1958), she used FORTRAN, which had just been released. In 1958, she joined Sylvania Electric Products in Needham, Massachusetts, as Section Head for MOBIDIC Programming. The primary task of the section was the preparation of the basic programming package for MOBIDIC (a large-scale computer of that time frame) under a contract to the Signal Corps as part of the Army FIELDATAprogram. She held that position at the time the COBOL effort started in 1959. She was a key member of the COBOL (then called Short Range) Committee, and continued COBOL committee work until she joined IBM in 1961. Her mission in joining IBM was to organize and manage the Boston Advanced Programming Department in Cambridge, MA, to do advanced development work in programming. One of the key projects of that department was the development of FORMAC, the first programming language for symbolic mathematics. She later held various technical management and staff positions at IBM until the end of 1988 when she took early retirement. Most of the positions and activities involved programming languages, including originating and directing the development of the first FORMAC (FORmula MAnipulation Compiler), and organizing the strategy and activities for the use of Ada in the IBM Federal Systems Division. She has given numerous lectures and talks on the subjects of symbolic computation and programming languages, including the historical aspects of both. She has published over 50 papers on these subjects. In 1969, her 785-page book PROGRAMMING LANGUAGES: History and Fundamentals was published by Prentice Hall and has been described by others as "the standard work on programming languages" and an "instant computer classic." She has been very active in professional society activities, including serving as ACM SIGPLAN Chair (1971-1972), ACM Vice-President (1972-1974), and ACM President (1974---1976). From January 1979 to January 1987 she was Editor-in-Chief of ACM Computing Reviews and of the ACM Guide to Computing Literature. She served on several standards committees. She organized and chaired the first AFIPS History of Computing Committee (1977-1979). She conceived the idea, and served as General and Program Chair, for the very successful ACM SIGPLAN History of Programming Languages Conference in 1978, and was the Program Chair for the Second ACM SIGPLAN History of Programming Languages Conference (HOPL-II) in April 1993. From 1983 to 1993 she was a member of the Board of Directors of the Computer Museum and has been on its Collections Committee. She is on the Executive Committee of the Software Patent Institute and was the first Chair of its Education Committee. She received an honorary Sc.D. from Mount Holyoke in 1978. Some of her honors and awards include membership in the National Academy of Engineering (1977), the ACM Distinguished Service Award (1985), and the Augusta Ada Lovelace Award from the Association for Women in Computing (1989). She is currently a programming language consultant.
FORMAC SESSION
469
X CLU Session
Chair:
BarbaraRyder
A HISTORY OF CLU Barbara Liskov Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139
ABSTRACT The idea of a data abstraction has had a significant impact on the development of programming languages and on programming methodology. CLU was the first implemented programming language to provide direct linguistic support for data abstraction. This paper provides a history of data abstraction and CLU. CLU contains a number of other interesting and influential features, including its exception handling mechanism, its iterators, and its parametedzed types, l CONTENTS 10.1 Introduction 10.2 Data Abstraction 10.3 CLU 10.4 Evaluation References
10.1
INTRODUCTION
The idea of a data abstraction arose from work on programming methodology. It has had a significant impact on the way modern software systems are designed and organized and on the features that are provided in modern programming languages. In the early and mid-1970s, it led to the development of new programming languages, most notably CLU and Alphard. These language designs were undertaken to flesh out the idea and to provide direct support for new techniques for developing software. This paper provides a history of CLU and data abstraction. CLU provides linguistic support for data abstraction; it was the first implemented language to do so. In addition, it contains a number of This research was supported in part by the AdvancedResearchProjects Agencyof the Department of Defense, monitored by the Officeof Naval ResearchundercontractN00014-894-1988,in part by the National ScienceFoundationunder Grant CCR-8822158, and in part by the NEC Corporationof Tokyo,Japan. 471
BARBARA LISKOV
other interesting and influential features, including its exception handling mechanism, its iterators, and its parameterized types. The paper is organized as follows. Section 10.2 describes the work that led to the concept of data abstraction and how this concept came into existence. It also describes the beginning of the work on CLU, and discusses some of the later work on programming methodology that was based on data abstraction. Section 10.3 provides a history of the CLU development process, with emphasis on the design issues related to the technical features of CLU; the section contains material about related work in other languages as well. The paper concludes with an evaluation of CLU and a discussion of its influence on programming languages and methodology.
10.2 DATA ABSTRACTION In my early work on data abstraction, in the latter part of 1972 through the summer of 1973, I was concerned with figuring out what the concept was, rather than designing a programming language. This section traces the development of the concept and describes the environment in which the work occurred and the related work that was going on at that time. A data abstraction, or abstract data type, is a set of objects and operations. Programs that access the objects can do so only by calling the operations, which provide means to observe an object's state and to modify it. The objects contain within them a storage representation that is used to store their state, but this representation is encapsulated: it is not visible to programs that use the data abstraction. For example, a "set of integers" type might have operations to create an empty set, to insert and delete elements from a set, to determine the cardinality of a set, and to determine whether a particular integer is a member of a set. A set might be represented by an array or a linked list, but because users can interact with it only by calling operations, the particular representation is not visible. One important benefit of such encapsulation is that it allows decisions about implementation to be changed without any need to modify programs that use the data abstraction. The idea of a data abstraction developed in the early seventies. It grew out of work on programming methodology. At that time, there was a great deal of interest in methods for improving the efficiency of the programming process and also the quality of the product. There were two main approaches: structured programming and modularity. Structured programming [Dijkstra 1969] was concerned with program correctness (or reliability, as it was called in those days): The goal of structured programming is to produce program structures which are amenable to proofs of correctness. The proof of a structured program is broken down into proofs of the correctness of each of the components. Before a component is coded, a specification exists explaining its input and output and the function which it is supposed to perform [Liskov 1972a, p. 193]. Not using gotos [Dijkstra 1968a] was a part of structured programming because the resulting program structures were easier to reason about, but the idea of reasoning about the program at one level using specifications of lower-level components was much more fundamental. The notion of stepwise refinement as an approach to constructing programs was also a part of this movement [Wirth 1971]. The work on modularity [Liskov 1972a; Parnas 1971, 1972a; Randell 1969] was concerned with what program components should be like. For example, I proposed the idea of partitions: The system is divided into a hierarchy of partitions, where each partition represents one level of abstraction, and consists of one or more functions which share common resources . . . . The connections in data between partitions are limited to the explicit arguments passed from the functions of one partition to the (external)
472
CHAPTER X
PAPER: A HISTORY OF CLU
functions of another partition. Implicit interaction on common data may only occur among functions within a partition [Liskov 1972a, p. 195]. This notion of partitions was based on Dijkstra's ideas about levels of abstraction [Dijkstra 1968b] and my own work on the Venus operating system [Liskov 1972b]. Venus was organized as a collection of partitions, each with externally accessible functions and hidden state information, which communicated by calling one another's functions. The papers on programming methodology were concerned with system structure rather than with programming language mechanisms. They provided guidelines that programmers could use to organize programs but did not describe any programming language constructs that would help in the organization. The work on data abstraction arose from an effort to bridge this gap. Data abstraction merged the ideas of modularity and encapsulation with programming languages by relating encapsulated modules to data types. As a result, programming languages that provided direct support for modular programming came into existence, and a much clearer notion of what a module is emerged. By the fall of 1972, I had become dissatisfied with the papers on programming methodology, including my own, because I believed it was hard for readers to apply the notions to their own programs. The idea of a module was somewhat nebulous in these papers (some operations with hidden state information). Even less obvious was how to do modular design. The designer was supposed to identify modules, but it was not at all clear how this was to be done, and the papers provided relatively little guidance on this crucial point. I noticed that many of the modules discussed in the papers on modularity were defining data types. For example, I had suggested that designers look for abstractions that hid the details of interacting with various hardware resources, and that hid the storage details of data structures [Liskov 1972a]. This led me to think of linking modules to data types and eventually to the idea of abstract types with an encapsulated representation and operations that could be used to access and manipulate the objects. I thought that programmers would have an easier time doing modular design in terms of abstract types (instead of just looking for modules) because this was similar to deciding about data structures, and also because the notion of an abstract type could be defined precisely. I referred to the types as "abstract" because they are not provided directly by a programming language but instead must be implemented by the user. An abstract type is abstract in the same way that a procedure is an abstract operation. I gave a talk [Liskov 1973a] on abstract data types at a workshop on Programming Languages and Operating Systems held in Savannah on April 9-12, 1973. This talk merged the ideas of structured programming and modularity by relating the components of a structured program to either abstract operations (implemented by procedures) or abstract types. An abstract type provides a group of related functions whose joint actions completely define the abstraction as far as its users are concerned. The irrelevant details of how the abstraction is supported are completely hidden from the users [Liskov 1973a, p. 6]. Furthermore, the language should support a syntactic unit that can be used to implement abstract types, and "the language must be strongly typed so that it is not possible to make use of an object in any other way" [Liskov 1973a, p. 7] except by calling its operations. At about the time of the Savannah meeting, I began to work with Steve Zilles, who was also at MIT working on a similar idea. Steve published his ideas at Savannah [Zilles 1973], and there were a number of other related talks given there, including a talk on monitors by Mike McKeag [ 1973] and a talk on LIS by Jean Ichbiah [1973].
CLU SESSION
473
BARBARALISKOV Steve and I worked on refining the concept of abstract types over the spring and summer of 1973; Austin Henderson was involved to a lesser extent as an interested listener and critic. Our progress report for that year [Liskov 1973b] describes a slightly later status for the work than what was reported at the Savannah meeting. In the progress report, we state that an abstract type should be defined by a "function cluster" containing the operations of the type. By the end of the summer, our ideas about language support for data abstraction were quite well established, and Steve and I described them in a paper published in September [Liskov 1973c]; a slightly later version of this paper appeared in the conference on very high level languages held in April 1974 [Liskov 1974a]. The September paper states that an abstract data type is implemented by a "cluster" containing a description of the representation and implementations of all the operations. It defines structured programming: In structured programming, a problem is solved by means of a process of successive decomposition. The first step is to write a program which solves the problem but which runs on an abstract machine, i.e., one which provides just those data objects and operations which are suitable to solving the problem. Some or all of those data objects and operations are truly abstract, i.e., not present as primitives in the programming language being used [Liskov 1973c, p. 3]. CLU was chosen as the name of the language in the fall of 1973. The name was selected because it is the first three letters of "cluster."
10.2.1 Related Early Work Programming languages that existed when the concept of data abstraction arose did not support abstract data types, but some languages contained constructs that were precursors of this notion. (An analysis of language support for other languages was done by Jack Aiello, a student in the CLU group, in the fall of 1973 and the spring of 1974 [Aiello 1974].) The mechanism that matched the best was the class mechanism of Simula 67 [Dahl 1970]. A Simula class groups a set of procedures with some variables. A class can be instantiated to provide an object containing its own copies of the variables; the class contains code that initializes these variables at instantiation time. However, Simula classes did not enforce encapsulation (although Palme proposed a change to Simula that did [Palme 1973]), and Simula was lacking several other features needed to support data abstraction, as discussed further in section 10.3.2. Extensible languages contained a weak notion of data abstraction. This work arose from a notion of"uniform referents" [Balzer 1967; Earley 1971 ; Ross 1970]. The idea was that all data types ought to be referenced in the same way so that decisions about data representation could be delayed and changed. This led to a notion of a fixed set of operations that every type supported. For example, every type in EL1 [Wegbreit, 1972, 1973] was permitted to provide five operations (conversion, assignment, selection, printing, and generation). However, the new type was not abstract; instead it was just an abbreviation for the chosen representation, which could be accessed everywhere, so that there was no encapsulation. PL/I provides multi-entry procedures, which can be used to implement data abstractions, and in fact I have used PL/I in teaching how to program using abstract data types when languages with more direct support were not available. The PL/I mechanism allows the description of the representation chosen for objects of the new type to be grouped with the code for the operations; the representation is defined at the beginning of the multi-entry procedure, and the entry points serve as the operations. However, users of the type can access the representations of objects directly (without calling the operations), so again there is no enforcement of encapsulation. Furthermore, multi-entry procedures have other peculiarities; for example, if control falls off the end of one entry point, it does not return
474
CHAPTER X
PAPER:A HISTORYOF CLU to the caller but instead continues in the entry point that follows textually within the multi-entry procedure. Jim Morris' paper on protection in programming languages [Morris 1973a] appeared in early 1973. This paper contains an example of an abstract data type implemented by a lambda expression that returns a list of operations to be used to access and manipulate the new object. The paper also describes how encapsulation can be enforced dynamically by means of a key that is needed to access the representation and whose value is known only to the type's operations (this notion is elaborated in Morris [1973b]). In the early design of CLU, we thought that this kind of dynamic checking would be needed in some cases, but as the design progressed we came to realize that complete static type checking is possible. Bill Wulf and Mary Shaw published a paper concerning the misuse of global variables [Wulf 1973] in 1973. One point made in this paper is that there is no way in a block structured language to limit access to a group of variables to just the group of procedures that need such access. This paper represents some of the early thinking of the people who went on to develop Alphard [Shaw 1981; Wulf 1976]. Also in 1973 Tony Hoare published an important paper about how to reason about the correctness of a data type implementation [Hoare 1972]. This paper pointed the way to future work on specification and verification of programs built with data abstractions. A timely and useful meeting was organized by Jack Dennis and held at the Harvard Faculty Club on October 3-5, 1973 to discuss issues in programming language design; a list of attendees is contained in Appendix A. The topics discussed were: types, semantic bases, concurrency, error handling, symbol identification, sharing and assignment, and relation to systems. Most attendees at the meeting gave brief talks describing their research. I spoke about clusters and the current state of the CLU design, and Bill Wulfdiscussed the work on Alphard. (Neither of the language names existed at this point.) Ole-Johan Dahl discussed Simula classes and their relationship to clusters. Steve Zilles described his early work on specifying abstract data types. Carl Hewitt discussed his work on Actors, and Tony Hoare described monitors. Also, Jim Mitchell described his early work on error handling, which led to the exception handling mechanism in Mesa [Mitchell 1978]. 10.2.2
Programming Methodology
The identification of data abstractions as an organizing principle for programs spurred work in programming methodology. 'This work is discussed briefly in this section. As mentioned, the concept of data abstraction arose out of work on structured programming and modularity that was aimed at a new way of organizing programs. Traditionally, programs had been organized using procedures or subroutines. 'The new idea was to organize around modules that consisted of a number of related procedures, and, with the advent of data abstraction, these modules defined data types or objects. The hope was that this would lead to better organized programs that would be easier to implement and understand, and, as a result, easier to get right. The resulting programming methodology [Liskov 1979a, 1986] is object-oriented: programs are developed by thinking about the objects they manipulate and then inventing a modular structure based on these objects. Each type of object is implemented by its own program module. Although no studies have shown convincingly that this methodology is superior to others, the methodology has become widespread and people believe that it works. (! believe this; I also believe that it is impossible to run a controlled experiment that will produce a convincing result.) A keystone oftbe methodology is its focus on independence of modules. The goal is to be able to deal with each module separately: a module can be implemented independently of(the code of) others, CLU SESSION
475
BARBARALISKOV
it can be reasoned about independently, and it can be replaced by another module implementing the same abstraction, without requiring any changes in the other modules of the program. Thus, for example, if a data abstraction were implemented too inefficiently, it could be reimplemented and the result would be a program that ran better, but whose externally visible behavior was otherwise unchanged. What is really interesting is that client programs don't have to be changed, and yet will run better. Achieving independence requires two things: encapsulation and specification. Encapsulation is needed because if any other module depends on implementation details of the module being replaced, it will not be possible to do the replacement without changing that other module. Just having code in some other module that accesses (but does not modify) an object's representation is enough to make replacement impossible, because that code is dependent on implementation details. To keep programmers from writing such code, Dave Parnas advocated hiding code from programmers of other modules so that they would be unable to write code that depended on the details [Parnas 1971 ]. I believe this position is too extreme, because it conflicts with other desirable activities such as code reading. Encapsulation makes it safer for programmers to read code. Specifications are needed to describe what the module is supposed to do in an implementation-independent way so that many different implementations are allowed. (Code is not a satisfactory description because it does not distinguish what is required from ways of achieving it. One of the striking aspects of much of the work on object-oriented programming has been its lack of understanding of the importance of specifications; instead the code is taken as the definition of behavior.) Given a specification, one can develop an implementation without needing to consider any other part of the program. Furthermore, the program will continue to work properly when a new implementation is substituted for the old, providing the new implementation satisfies the specification (and assuming the old implementation did, too). Specifications also allow code that uses the abstraction to be written before code that implements the abstraction, and therefore are necessary if you want to do top-down implementation. Work on specifications of data abstractions and on the related area of reasoning about correctness in programs that use and implement data abstraction started in the early seventies [Hoare i 972; Parnas 1972b; Zilles, 1974a, 1975] and continued for many years (see, e.g., [Wulf 1976; Goguen i 975; Guttag 1975, 1977; Berzins 1979; Parnas 1972b; Spitzen 1975; Guttag 1980]). Verification methods work only when the type's implementation is encapsulated (actually, protection against modification of the representation from outside the module is sufficient), because otherwise it would not be possible to limit one's attention to just a single module's implementation. If a language enforces encapsulation, independent reasoning about modules is on a sound foundation. Otherwise, it is not and a complete proof requires a global analysis. In essence, having a language enforce encapsulation means that the compiler proves a global property of a program; given this proof, the rest of the reasoning can be localized. Languages that enforce encapsulation are based on a "less is more" kind of philosophy. The idea is that something can be gained by having a programmer give up some freedom. What is gained is global: increased ease in reasoning about an entire, multimodule program. What is lost is local: a programmer must live by the rules, which can sometimes be inconvenient. 10.3
CLU
Although I was not thinking about developing a complete, implemented programming language when I first worked on data abstraction, I took this next step quite soon, sometime in the spring or summer of 1973. By the time work began in earnest on the language design in the fall of 1973, many details 476
CHAPTER X
PAPER: A HISTORY OF CLU
of the language were already set. For example, we had already decided to implement abstract types with clusters, to keep objects in the heap, and to do complete type checking. However, there was lots of work left to do to design all the language features and their interactions. In this section I provide a history of the CLU development. I begin by describing our goals (section 10.3.1), the design process (section 10.3.2), and our design principles (section 10.3.3). The remaining sections discuss what I consider to be the important technical decisions made during the project. Details about project staffing and the phases of the project can be found in Appendices B and C, respectively. 10.3.1
L a n g u a g e Goals
The primary goal of the project was to do research on programming methodology: We believe the best approach to developing a methodology that will serve as a practical tool for program construction is through the design of a programming language such that problem solutions developed using the methodology are programs in the language. Several benefits accrue from this approach. First, since designs produced using the methodology are actual programs, the problems of mapping designs into programs do not require independent treatment. Secondly, completeness and precision of the language will be reflected in a methodology that is similarly complete and precise. Finally, the language provides a good vehicle for explaining the methodology to others [Liskov 1974b, p. 35]. We recognized early on that implementations are not the same as abstractions. An implementation is a piece of code; an abstraction is a desired behavior, which should be described independently from the code, by means of a specification. Thus, our original proposal to NSF says: "An abstract data type is a concept whose meaning is captured in a set of specifications, while a cluster provides an implementation of a data type" [Dennis 1974, p. 21 ]. An implementation is correct if it "satisfies" the abstraction's specification. There was a great deal of interest in the group in specification and verification techniques, especially for data abstractions. This started with Steve Zilles' early work on algebraic specifications, which was mentioned in the proposal and also in the progress report for 1973-1974 [Liskov 1974b]; work on specifications was discussed briefly in section 10.2.2. However, unlike the Alphard group, we chose to separate the work on specifications from the language definition. I believed that the language should contain only declarations that the compiler could make use of, and not statements that it would treat simply as comments. I think this decision was an important factor in our ability to make quick progress on the language design. The work on CLU occurred at MIT within the Laboratory for Computer Science with support from the National Science Foundation and DARPA. We believed that our main "product" was concepts rather than the language. We thought of our primary output as being publications, and that success would be measured by our influence on programming methodology and practice, and on future programming languages. We did not think of CLU as a language that would be exported widely. Instead, we were concerned primarily with the export of ideas. CLU was intended to be a general purpose programming language, although it was geared more toward symbolic than numerical computing. It was not oriented toward low-level system programming (for example, of operating systems), but it can be used for this purpose by the addition of a few data types implemented in assembler, and the introduction of some procedures that provide "unsafe features." This is the technique that we have used in our implementations. For example, we have a procedure in the library called " cvt" that can be used to change the type of an object. Such features are not described in the CLU reference manual; most users are not supposed to use them. I believe this is a better approach than providing a generally unsafe language like C, or a language with unsafe
CLU SESSION
477
BARBARALISKOV features, like Mesa [Mitchell 1978], because it discourages programmers from using the unsafe features casually. CLU was intended to be used by "experienced" programmers. Programmers would not have to be wizards, but they were not supposed to be novices either. Although CLU (unlike Pascal) was not designed to be a teaching language, we use it this way and it seems to be easy to learn (we teach it to MIT sophomores). CLU was geared toward developing production code. It was intended to be a tool for"programming in the large," for building big systems (for example, several hundred thousand lines) that require many programmers to work on them. (Such large systems have not been implemented in CLU, but systems containing 40-50 thousand lines of code have been.) As the work on CLU went on, I developed a programming methodology for such systems [Liskov 1979a, 1986]. CLU favors program readability and understandability over ease of writing, because we believed that these were more important for our intended users.
10.3.2 The Design Process There were four main language designers: myself, and three graduate students, Russ Atkinson, Craig Schaffert, and Alan Snyder. Steve Zilles was deeply involved in the early work on the language, but by 1974 Steve was concentrating primarily on his work on specifications of abstract types, and acted more as an interested onlooker and critic of the developing design. As time went by, other students joined the group including Bob Scheifler and Eliot Moss. (A list of those who participated in the design is given in Appendix B.) The design was a real group effort. Usually it is not possible to identify an individual with a feature (iterators are the exception here, as discussed in section 10.3.10). Instead, ideas were developed in meetings, worked up by individuals, evaluated in later meetings, and then reworked. I was the leader of the project and ultimately made all the decisions, although often we were able to arrive at a consensus. In our design meetings we sometimes voted on alternatives, but these votes were never binding. I made the actual decisions later. Russ, Craig, and Alan (and later Bob and Eliot) were implementers as well as designers. All of us acted as "users"; we evaluated every proposal from this perspective (considering its usability and expressive power), as well as from a designer's perspective (considering both implementability, and completeness and well-definedness of semantics). We worked on the implementation in parallel with the design. We did not allow the implementation to define the language, however. We delayed implementing features until we believed that we had completed their design, and if problems were discovered, they were resolved in design meetings. Usually, we did not introduce any new features into the language during the implementation, but there were a few exceptions (in particular, own data). We provided external documentation for the language through papers, reference manuals, and progress reports. We documented the design as it developed in a series of internal design notes [PMG 1979a]. There were 78 notes in all; the first was published on December 6, 1973 and the last on July 30, 1979. The notes concentrated on the utility and semantics of proposed language features. Typically, a note would describe the meaning of a feature (in English) and illustrate its use through examples. Syntax was introduced so that we could write code fragments, but was always considered to be of secondary importance. We tended to firm up syntax last, at the end of a design cycle. The group held weekly design meetings. In these meetings we evaluated proposed features as thoroughly as we could. The goal was to uncover any flaws, both with respect to usability and
478
CHAPTER X
PAPER: A HISTORY OF CLU
semantics. This process seemed to work well for us: we had very few surprises during implementation. We published (internal) design meeting minutes for most of our meetings [PMG 1979b]. The design notes use English to define the semantics of proposed constructs. We did not use formal semantics as a design tool because I believed that the effort required to write the formal definitions of all the many variations we were considering would greatly outweigh any benefit. We relied on our very explicit design notes and thorough analysis instead. I believe our approach was wise, and I would recommend it to designers today. During design what is needed is precision, which can be achieved by doing a careful and rigorous, but informal, analysis of semantics as you go along. It is the analysis process that is important; in its absence, a formal semantics is probably not much help. We provided a formal semantics (in several forms) when the design was complete [Schaffert 1978; Scheifler 1978]. It validated our design but did not uncover errors, which was gratifying. For us, the main virtue of the formal definition was as ex post facto documentation. The group as a whole was quite knowledgeable about languages that existed at the time. I had used Lisp extensively and had also programmed in FORTRAN and ALGOL 60, Steve Zilles and Craig Schaffert had worked on PL/I compilers, and Alan Snyder had done extensive programming in C. In addition, we were familiar with ALGOL 68, EL/I, Simula 67, Pascal, SETL, and various machine languages. Early in the design process we did a study of other languages to see whether we should use one of them as a basis for our work [Aiello 1974]. We ultimately decided that none would be suitable as a basis. None of them supported data abstraction, and we wanted to see where that idea would lead us without having to worry about how it might interact with pre-existing features. However, we did borrow from existing languages. Our semantic model is largely borrowed from Lisp; our syntax is ALGOL-like. We also had certain negative influences. We felt that Pascal had made too many compromises to simplify its implementation. We believed strongly in compile-time type checking but felt it was important for the language to support types in a way that provided adequate expressive power. We thought Pascal was deficient here, for example, in its inability (at the time) to support a procedure that could be passed different size arrays on different calls. We felt that ALGOL 68 had gone much too far in its support for overloading and coercions. We believed that a language must have very simple rules in this area or programs would be hard for readers to understand. This led us ultimately to our ideas about "syntactic sugar" (see section 10.3.8). Simula 67 was the existing language that was closest to what we wanted, but it was deficient in several ways, some of which seemed difficult to correct: 1. Simula did not support encapsulation, so its classes could be used as a data abstraction mechanism only if programmers obeyed rules not enforced by the language. 2. Simula did not provide support for user-defined type "generators." These are modules that define groups of related types, for example, a user-defined set module that defines set[int], set[real], etc. 3. It did not group operations and objects in the way we thought they should be grouped, as discussed in section 10.3.4. 4. It treated built-in and user-defined types nonuniformly. Objects of user-defined types had to reside in the heap, but objects of built-in type could be in either the stack or the heap. In addition, we felt that Simula's inheritance mechanism was a distraction from what we were trying to do. Of course, this very mechanism was the basis for another main language advance of the seventies, Smalltalk. The work on Smalltalk was concurrent with ours and was completely unknown to us until around 1976. CLU SESSION
479
BARBARALISKOV 10.3.3 Design Principles The design of CLU was guided by a number of design principles, which were applied quite consciously. The principles we used were the following: 1. Keep focused. The goal of the language design was to explore data abstraction and other mechanisms that supported our programming methodology. Language features that were not related to this goal were not investigated. For example, we did not look at extensible control structures. Also, although I originally intended CLU to support concurrency [Dennis 1974], we focused on sequential programs initially to limit the scope of the project, and eventually decided to ignore concurrency entirely. (We did treat concurrency in a successor language, Argus [Liskov 1983, 1988].) 2. Minimality. We included as few features as possible. We believed that we could learn more about the need for a feature we were unsure of by leaving it out: if it was there, users would use it without thinking about whether they needed it, but if it was missing, and they really needed it, they would complain. 3. Simplicity. Each feature was as simple as we could make it. We measured simplicity by ease of explanation; a construct was simple if we could explain it (and its interaction with other features) easily. 4. Expressive power. We wanted to make it easy for users to say the things we thought they needed to say. This was a major motivation, for example, for the exception mechanism. To a lesser extent, we wanted to make it hard to express things we thought should not be expressed, but we did not pay too much attention to this; we knew that users could write (what we thought were) bad programs in CLU if they really wanted to. 5. Uniformity. As much as possible, we wanted to treat built-in and user-defined types the same. For example, operations are called in the same way in both cases; user-defined types can make use of infix operators, and built-in types use our "type_nameSop name" syntax to name operations that do not correspond to operator symbols just like the user-defined types. 6. Safety. We wanted to help programmers by ruling out errors or making it possible to detect them automatically, This is why we have strong type checking, a garbage collected heap, and bounds checking. 7. Performance. We wanted CLU programs to run quickly, for example, close to comparable C programs. (Performance measurements indicate that CLU programs run at about half the speed of comparable C programs.) We also wanted fast compilation, but this was of secondary importance. As usual, several of these goals are in conflict. Expressive power conflicts with minimality; performance conflicts with safety and simplicity. When conflicts arose we resolved them as best we could, by trading off what was lost and what was gained in following a particular approach. For example, we based our semantics on a garbage collected heap---even though it may require more expense at runtime--because it improves program safety and simplifies our data abstraction mechanism. A second example is our iterator mechanism; we limited the expressive power of the mechanism so that we could implement it using a single stack. Concern for performance pervaded the design process. We always considered how proposed features could be implemented efficiently. In addition, we expected to make use of compiler optimizations to improve performance. Programming with abstractions means there are lots of
480
CHAPTER X
PAPER:A HISTORYOF CLU
procedure calls, for example, to invoke the operations of abstract types. In our September 1973 paper, Steve and I noted: The primary business of a programmer is to build a program with a good logical structure---one which is understandable and leads to ease in modification and maintenance . . . . We believe it is the business of the compiler to map good logical structure into good physical structure . . . . Each operator-use may be replaced either by a call upon the corresponding function in the cluster or by inline code for the corresponding function. ... Inline insertion of the code for a function allows that code to be subject to the optimization transformations available in the compiler [Liskov 1973c, p. 32-33]. Thus we had in mind inline substitution followed by other optimizations. Bob Scheifler did a study of how and when to do inline substitution for his BS thesis [Scheifler 1976, 1977], but we never included it in our compiler because of lack of manpower. 10.3.4
Implementing Abstract Types
In CLU an abstract data type is implemented by a cluster, which is a program module with three parts (see Figure l 0.1 ): (1) a header listing the operations that can be used to create and interact with objects of that type; (2) a definition of the storage representation, or rep, that is used to implement the objects of the type; (3) procedures (and iterators--see section 10.3.10) that implement the operations listed in the header (and possibly some additional internal procedures and iterators as well). Only procedures inside the cluster can access the representations of objects of the type. This restriction is enforced by type checking. There are two different ways to relate objects and operations: 1. One possibility is to consider the operations as belonging to the type. This is the view taken in both CLU and Alphard. (Alphard "forms" are similar to clusters.) In this case, a type can be thought of as defining both a set of objects and a set of operations. (The approach in Ada is a variation on this. A single module defines both the type and the operations. Operations have access to the representation of objects of their type because they are defined inside the module that defines the type. Several types can be defined in the same modules, and operations in the module can access the representations of objects of all these types.) 2. A second possibility is to consider the operations as belonging to the objects. This is the view taken in Simula, and also in Smalltalk and C++. These two approaches have different strengths and weaknesses. The "operations in type" approach works well for operations like "+" or "union" that need to access the representations of two or more FIGURE
10.1
The Structure of a Cluster int_set = c l u s t e r is create, member,
size,
insert,
delete,
elements
rep = array[int] % i m p l e m e n t a t i o n s of operations go here end int_set
CLU SESSION
481
BARBARALISKOV
objects at once, because with this approach, any operation of the type can access the representation of any object of the type. The "operations in object" approach does not work so well for such operations because an operation can only access the representation of a single object, the one to which it belongs. On the other hand, if there can be more than one implementation for a type in existence within a program, or if there is inheritance, the "operations in object" approach works better, because an operation knows the representation of its object, and cannot rely on possibly erroneous assumptions about the representation of other objects, as it is unable to access these representations. We believed that it was important to support multiple implementations but even more important to make binary operations like "+" work well. We did not see how to make the "operations in object" approach run efficiently for binary operations. For example, we wanted adding two integers to require a small number of machine instructions, but this is not possible unless the compiler knows the representation of integers. We could have solved this problem by treating integers specially (allowing just one implementation for them), but that seemed inelegant, and it conflicted with our uniformity goal. Therefore, a program in CLU can have only a single implementation for any given type (built-in or user-defined); this case is discussed further in section 10.3.11. People have been working for the last 15 years to make integers run fast in object-oriented languages (see, for example, the work of Dave Ungar and Craig Chambers [Chambers 1990]). So in retrospect, it was probably just as well that we avoided this problem. During the design of CLU, we hypothesized that it might be sufficient to limit different implementations to different regions of a program [Liskov 1975a]. This idea was incorporated into Argus [Liskov 1983, 1988], the language we developed after CLU. In Argus the regions are called "guardians" and the same type can have different implementations in different guardians within the same program. Guardians can communicate using objects of a type where the implementations differ because the representation can change as part of the communication [Herlihy 1982]. 10.3.5
Semantic Model
CLU looks like an ALGOL-like language, but its semantics is like that of Lisp: CLU objects reside in an object universe (or heap), and a variable just identifies (or refers to) an object. We decided early on to have objects in the heap, although we had numerous discussions about the cost of garbage collection. This decision greatly simplified the data abstraction mechanism (although I do not think we appreciated the full extent of the simplification until quite late in the project). A language that allocates objects only on the stack is not sufficiently expressive; the heap is needed for objects whose sizes must change and for objects whose lifetime exceeds that of the procedure that creates them. (Of course, it is possible for a program to do everything using a stack---or FORTRAN common--but only at the cost of doing violence to the program structure.) Therefore, the choice is: just heap, or both. Here are the reasons why we chose the heap approach (an expanded discussion of these issues can be found in [Moss 1978]): 1. Declarations are simple to process when objects are on the heap: the compiler just allocates space for a pointer. When objects are on the stack, the compiler must allocate enough space so that the new variable will be big enough to hold the object. The problem is that knowledge about object size ought to be encapsulated inside the code that implements the object's type. There are a number of ways to proceed. For example, in Alphard, the plan was to provide additional operations (not available to user code) that could be called to determine how much space to allocate; the compiler would insert calls to these operations when allocating space for variables. Ada requires that size information be made available to the compiler; this is why
482
CHAPTER X
PAPER: A HISTORY OF CLU
type definitions appear in the "public" part of a module. However, this means that the type's representation must be defined before any modules that use the type can be compiled, and also, if the representation changes, all using modules must be recompiled. The important point is that with the heap approach the entire problem is avoided. 2. The heap approach allows us to separate variable and object creation: variables are created by declarations, and objects are created explicitly by calling an operation. The operation can take arguments if necessary and can ensure that the new object is properly initialized so that it has a legitimate state. (In other words, the code can ensure that the new object satisfies the rep invariant [Hoare 1972; Guttag 1975].) In this way we can avoid a source of program errors. Proper initialization is more difficult with the stack approach because arguments are often needed to do it right. Also, the heap approach allows many creation operations, for example, to create an empty set, or a singleton set; having many creation operations is more difficult with the stack approach. 3. The heap approach allows variable and object lifetimes to be different. With the stack approach they must be the same; if the object is to live longer than the procedure that creates it, a global variable must be used. With the heap approach, a local variable is fine; later a variable with a longer lifetime can be used, for example, in the calling procedure. Avoiding global variables is good because they interfere with the modular structure of the program (as was pointed out by Wulf and Shaw [Wulf 1973]). 4. Assignment has a type-independent meaning with the heap approach; X
:=
e
causes x to refer to the object obtained by evaluating expression e. With the stack approach, evaluating an expression produces a value that must be copied into the assigned variable. To do this right requires a call on the object's assignment operation, so that the right information is copied. In particular, if the object being copied contains pointers, it is not clear whether to copy the objects pointed at; only the implementer of the type knows the right answer. The assignment operation needs access to the variable containing the object being copied; really call-by-reference is required. Alphard did copying right because it allowed the definers of abstract types to define the assignment operation using by-reference parameters. Ada did not allow user-defined operations to control the meaning of assignment; at least this is, in part, because of the desire to treat call-by-reference as an optimization of call-by-value/result, which simply will not work in this case. One unusual aspect of CLU is that our procedures have no free (global) variables (this is another early decision that is discussed in our September, 1973 paper [Liskov, 1973c]). The view of procedures in CLU is similar to that in Lisp: CLU procedures are not nested (except that procedures can be local to a cluster) but instead are defined at the "top" level, and can be called from any other module. In Lisp such procedures can have free variables that are scoped dynamically, a well-known source of confusion. We have found that free variables are rarely needed. This is probably attributable partly to data abstraction itself, because it encourages grouping related information into objects, which can then be passed as arguments. In fact, CLU procedures do not share variables at all. In addition to there being no free variables, there is no call-by-reference. Instead arguments are passed "by object"; the (pointer to the) object resulting from evaluating the actual argument expression is assigned to the formal. (Thus passing a parameter is just doing an assignment to the formal.) Similarly, a pointer to a result object is returned
CLU SESSION
483
BARBARALISKOV
to the caller. We have found that ruling out shared variables seems to make it easier to reason about programs. A CLU procedure can have side effects only if the argument objects can be modified (because it cannot access the caller's variables). This led us to the concept of "mutable" objects. Every CLU object has a state. The states of some objects, such as integers and strings, cannot change; these objects are "immutable." Mutable objects (e.g., records and arrays) can have a succession of states. We spent quite a bit of time discussing whether we should limit CLU to just immutable objects (as in pure Lisp) but we concluded that mutable objects are important when you need to model entities from the real world, such as storage. (Probably this discussion would not have been so lengthy if we had not had so many advocates of datafiow attending our meetings!) It is easy to define a pure subset of CLU by simply eliminating the built-in mutable types (leaving their immutable counterparts, e.g., sequences are immutable arrays). CLU assignment causes sharing: after executing "x := y," variables x and y both refer to the same object. If this object is immutable, programs cannot detect the sharing, but they can if the shared object is mutable, because a modification made via one variable will be visible via the other one. People sometimes argue that sharing of mutable objects makes reasoning about programs more difficult. This has not been our experience in using CLU. I believe this is true in large part because we do not manipulate pointers explicitly. Pointer manipulation is clearly both a nuisance and a source of errors in other languages. The cost of using the heap is greatly reduced by keeping small immutable objects of built-in types, such as integers and Booleans, directly in the variables that refer to them. These objects fit in the variables (they are no bigger than pointers) and storing them there is safe because they are immutable: Even though in this case, assignment does make a copy of the object, no program can detect it. 10.3.6
Issues Related to Safety
Our desire to make it easy to write correct programs led us to choose constructs that either ruled out
certain errors entirely or made it possible to detect them automatically. We chose to use garbage collection because certain subtle program errors are not possible under this semantics. Explicit deallocation is unattractive from a correctness point of view, because it can lead to both dangling references and storage leaks; garbage collection rules out these errors. The decision to base CLU on a garbage-collected heap was made during the fall of 1973 [Liskov 1974a]. Another important effect of the safety goal was our decision to have static type checking. We included here both checking within a module (e.g., a procedure or a cluster) and intermodule type checking; the interaction of type checking with separate compilation is discussed in section 10.3.11. Originally we thought we would need to do run-time checking [Liskov 1973c] and we planned to base our technique on that of Morris [Morris 1973a]. By early 1974, we realized that we could do compile-time checking [Liskov i 974a]; this issue is discussed further in section 10.3.7. We preferred compile-time checking to run-time checking because it enabled better runtime performance and allowed us to find errors early. We based our checking on declarations, which we felt were useful as a way of documenting the programmer's intentions. (This position differs from that of ML [Milner 1990], in which type information is inferred from the way variables are used. We were not aware of work on ML until the late seventies.) To make the checking as effective as possible, we ruled out coercions (automatic type conversions). We avoided all declarative information that could not be checked. For example, we discussed declaring within a cluster whether the type being implemented was immutable. We rejected this because the only way the compiler could ensure that
484
CHAPTER X
PAPER: A HISTORY OF CLU
this property held was to disallow mutable representations for immutable types. We wanted to allow an immutable type to have a mutable representation. One place where this is useful is in supporting "benevolent side effects" that modify the representation of an object to improve performance of future operation calls without affecting the visible value of the object. Type checking in CLU uses both structure and name equality. Name equality comes from clusters. If "foo" and "bar" are the names of two different clusters, the two types are not equal. (This is true even if they have the same representations; it is also true even if they have the same operations with the same signatures.) Structure equality comes from "equates." For example, if we have the two equates t
=
array[int]
s
=
array[int]
then t = s. We decided not to allow recursion in equates on the grounds that recursion can always be accomplished by using clusters. Although this reasoning is correct, the decision was probably a mistake; it makes certain programs awkward to write because extraneous clusters must be introduced just to get the desired recursion. Another decision made to enhance safety was not to require that variables be initialized by their declarations. CLU allows declarations to appear anywhere; they are not limited to just the start of a block. Nevertheless, sometimes when a variable is declared there is no meaningful object to assign to it. If the language requires such an assignment, it misses a chance to notice automatically if the variable is used before it is assigned. The definition of CLU states that this situation will be recognized. It is recognized when running under the debugger, but the necessary checking has never been implemented by the compiler. (This is the only thing in CLU that was not implemented.) Checking for proper variable initialization can usually be done by the compiler (using simple flow analysis), which would insert code to do run-time checks only for the few variables where the analysis is inconclusive. However, we never added the checking to the compiler (because of lack of manpower), and we did not want to do run-time checking at every variable use. By contrast, we require that all parts of an object be initialized when the object is created, thus avoiding errors arising from missing components. We believed that meaningful values for all components exist when an object is created; in part this is true because we do not create the object until we need to, in part because creation happens as the result of an explicit call with arguments, if necessary, and in part because of the way CLU arrays are defined (see the following). This belief has been borne out in practice. The differing positions on variable and object component initialization arose from an evaluation of performance effects as well as from concerns about safety. As mentioned, checking for variable initialization can usually be done by the compiler. Checking that components are initialized properly is much more likely to need to be done at run-time. Finally, we took care with the definitions of the built-in types both to rule out errors and to enable error detection. For example, we do bounds checking for ints and reals. Arrays are especially interesting in this regard. CLU arrays cannot have any uninitialized elements. When they are created, they contain some elements (usually none) provided as arguments to the creation operation. Thereafter they can grow and shrink on either end; each time an array grows, the new element is supplied. Furthermore, bounds checking is done on every array operation that needs it (for example, when the ith element is fetched, we check to be sure that the index i is legal). Finally, arrays provide an iterator (see section 10.3.10) that yields all elements and a second iterator that yields all legal indices, allowing a programmer to avoid indexing errors altogether.
CLU SESSION
485
BARBARA LISKOV
10.3.7 Parametric Polymorphism I mentioned earlier that we wanted to treat built-in and user-defined types alike. Because built-in types could make use of parameters, we wanted to allow them for user-defined types too. At the same time we wanted to provide complete type checking for them. For example, CLU arrays are parameterized. An "array" is not a type by itself. Instead it is a "type generator" that, given a type as a parameter, produces a type. Thus, given the parameter int, it produces the type array[intl. We say that providing the parameter causes the type to be "instantiated." It is clearly useful to have parameterized user-defined types; for example, using this mechanism we could define a set type generator that could be instantiated to provide set[int], set[char], set[set[char]l, and SO o n .
The problem with type generators is how to type-check the instantiations. We limit actual values of parameters to compile time constants such as "3," "int," and "set[intl." However, when the parameter is a type, the type generator may need to use some of its operations. For example, to test for set membership requires the ability to compare objects of the parameter type for equality. Doing this requires the use of the "equal" operation for the parameter type. Our original plan was to pass in a type-object (consisting of a group of operations) as an argument to a parameterized module, and have the code of the module check (at run-time) whether the type had the operations it needed with the proper signatures. Eventually we invented the "where" clause [Liskov 1977a], which describes the names and signatures of any operations the parameter type must have, for example, set = cluster [t: type] Is create, member, size, insert, delete, where t has equal: proctype (t, t) returns (bool)
elements
Inside the body of a parameterized module, the only operations of a type parameter that can be used are those listed in the where clause. Furthermore, when the type is instantiated, the compiler checks that the actual type parameter has the operations (and signatures) listed in the where clause. In this way, complete compile-time checking occurs. CLU was way ahead of its time in its solution for parameterized modules. Even today, most languages do not support parametric polymorphism, although there is growing recognition of the need for it (for example, [Cardelli 1988]).
10.3.8 Other Uniformity Issues In the previous section I discussed how user-defined types can be parameterized just like built-in ones. In this section I discuss two other uniformity issues, the syntax of operation calls and syntax for expressions. I also discuss the way CLU views the built-in types, and what built-in types it provides. A language such as CLU that associates operations with types has a naming problem: many types will have operations of the same name (e.g., "create," "equal," "size"), and when an operation is called we need some way of indicating which one is meant. One possibility is to do this with overloading, for example, "equal" denotes many procedures, each with a different signature, and the one intended is selected by considering the context of the call. This rule works fairly well (assuming no coercions) when the types of the arguments are sufficient to make the determination, for example, equal(s, 0 denotes the operation named "equal" whose first argument is of s's type and whose second argument is of t's type. It does not work so well if the calling context must be considered, which is the case for all creation operations. For example, we can tell that set create is meant in the following code: S: set[int]
486
:= create(
)
CHAPTER X
PAPER: A HISTORY OF CLU
but it is more difficult (and sometimes impossible) if the call occurs within an expression. We wanted a uniform rule that applied to all operations of a type, including creation operations. Also, we were vehemently opposed to using complicated rules to resolve overloading (e.g., as in ALGOL 68). This led us to require instead that every call indicate explicitly the exact operation being called, for example, S:
set[int]
:= s e t [ i n t ] $ c r e a t e (
)
In doing so, we eliminated overloading altogether: the name of an operation is always of the form t$o, where t is the name of its type, and o is its name within its type. This rule is applied uniformly to both built-in and user-defined types. We also allow certain short forms for calls. Most languages provide an expression syntax that allows symbols such as "+" to be used and allows the use of infix notation. We wanted to provide this too. To accomplish this we used Peter Landin's notion of"syntactic sugar" [Landin 1964]. We allow common operator symbols but these are only short forms for what is really happening, namely a call on an operation using its full t$o name. When the compiler encounters such a symbol, it "desugars" it by following a simple rule: it produces t$o where t is the type of the first argument, and o is the operation name associated with the symbol. Thus "x + y" is desugared to "t$add(x, y)" where t is the type of x. Once the desugaring has happened, the compiler continues processing using the desugared form (it even does type checking using this form). In essence the desugared form is the canonical form for the program. Not only is this approach simple and easy to understand, it applies to both built-in and user-defined types uniformly. To allow sugars to be used with a new type, the type definer need only choose the right names for the operations. For example, to allow the use of +, he or she names the addition operation "add." This notion of desugaring applies to all the arithmetic operations, to equality and related operations (e.g., ~Material: If the design and development of the hardware computer material is done as carefully and completely as Xerox's development of special light-sensitivealloys, then only one or two computer designs need to be built... Extra investment in development here will be vastly repaid by simplifying the manufacturing process and providing lower costs through increased volume.
SMALLTALK SESSION
551
ALAN C. KAY ~>Content: Aside from the wonderful generality of being able to continously shape new content from the same material, software has three important characteristics: •
the replication time and cost of a content-function is zero
t
the development time and cost of a content-function is high
* the change time and cost of a content-function can be low Xerox must take these several points seriously if it is to survive and prosper in its new business area of information media. If it does, the company has an excellent chance for several reasons: •
Xerox has the financial base to cover the large development costs of a small number of very powerful computer-types and a large number of software functions.
•
Xerox has the marketing base to sell these functions on a wide enough scale to garner back to itself an incredible profit.
•
Xerox has working for it an impressively large percentage of the best software designers in the world.
In 1976, Chuck Thacker designed the ALTO III that would use the new 16k chips and be able to fit on a desktop. It could be marketed for about what the large cumbersome special purpose "word-processors" cost, yet could do so much more. Nevertheless, in August of 1976, Xerox made a fateful decision: not to bring the ALTO III to market. This was a huge blow to many o f u s - - e v e n me, who had never really really thought of the ALTO as anything but a stepping stone to the "real thing." In 1992, the world market for personal computers and workstations was $90 m i l l i o n - - t w i c e as much as the mainframe and mini market, and many times Xerox's 1992 gross. The most successful company of this e r a m M i c r o s o f t is not a hardware company, but a software company. 11.5.2
The Srnalltalk User Interface
I have been asked by several of the reviewers to say more about the development of the "Smalltalkstyle" overlapping window user interface in as much as there are now more than 20 million computers in the world that use its descendents. A decent history would be as long as this chapter, and none has been written so far. There is a summary of some of the ideas in [Kay 1989]--1et me add a few more points. All of the elements eventually used in the Smalltalk user interface were already to be found in the s i x t i e s - - a s different ways to access and invoke the functionality provided by an interactive system. The two major centers of ideas were Lincoln Labs and R A N D Corporation--~oth ARPA funded. The big shift that consolidated these ideas into a powerful theory and long-lived examples came because the L R G focus was on children. Hence, we were thinking about learning as being one o f the main effects we wanted to have happen. Early on, this led to a 90-degree rotation of the purpose of the user interface from "access to functionality" to "environment in which users learn by doing." This new stance could now respond to the echos of Montessori and Dewey, particularly the former, and got me, on rereading Jerome Bruner, to think beyond the children's curriculum to a "curriculum of the user interface." The particular aim of L R G was to find the equivalent of writingmthat is, learning and thinking by doing in a medium---our new "pocket universe." For various reasons I had settled on "iconic programming" as the way to achieve this, drawing on the iconic representations used by many A R P A projects in the sixties. M y friend Nicholas Negroponte, an architect, was extremely interested in how environments affected people's work and creativity. He was interested in embedding the new computer 552
CHAPTER Xl
PAPER: THE EARLY HISTORY OF SMALLTALK
FIGURE 11.50 PaulRovnershowingthe iconic "Lincoln Wand"ca. 1968
magic in familar surroundings. I had quite a bit of theatrical experience in a past life, and remembered Coleridge's adage that "people attend 'bad theatre' hoping to forget, people attend 'good theatre' aching to remember." In other words, it is the ability to evoke the audience's own intelligence and experiences that makes theatre work. Putting all this together, we want an apparently free environment in which exploration causes desired sequences to happen (Montessori); one that allows kinesthetic, iconic, and symbolic iearning~"doing with images makes symbols" (Piaget and Bruner); the user is never trappod in a mode (GRAIL); the magic is embedded in the familiar (Negroponte); and which acts as a magnifying mirror for the user's own intelligence (Coleridge). It would be a great finish to this story to say that having articulated this we were able to move straightforwardly to the design as we know it today. In fact, the UI design work happened in fits and starts in between feeding Smalltalk itself, designing children's experiments, trying to understand iconic construction, and just playing around. In spite of this meandering, the context almost forced a good design to turn out anyway. Just about everyone at PARC at this time had opinions about the UI, ours and theirs. It is impossible to SMALLTALK SESSION
FIGURE 11.51 The last Smalltalk-72 interface
r 553
ALAN C. KAY
give detailed credit for the hundreds of ideas and discussions. However, the consolidation can certainly be attributed to Dan Ingalls, for listening to everyone, contributing original ideas, and constantly building a design for user testing. I had a fair amount to do with setting the context, inventing overlapping windows, and so on, and Adele and I designed most of the experiments. Beyond that, Ted Kaehler and visitor, Ron Baecker, made highly valuable contributions. Dave Smith designed SmallStar, the prototype iconic interface for the Xerox Star product. Meanwhile, I had gotten Doug Fairbaim interested in the Notetaker. He designed a wonderful "smart bus" that could efficiently handle slow multiple processors and the system looked very promising, even though most of the rest of PARC thought I was nuts to abandon the fast bipolar hw of the ALTO. But 1 could not see that bipolar was ever going to make it into a iaptop or Dynabook. On the other hand, I hated the 8-bit micros that were just starting to appear, because of the silliness and naivete of their designs--there was no hint that anyone who had ever designed software was involved.
FIGURE 11.52 Ted Kaehler's iconic painting interface
FIGURE 11.53 Smalltalk-76 User Interface with a variety of applications, including a clock, font editor, painting and illustration editor with iconic menus and programmable radio buttons, a word processor document editor, and a class editor showing window interface code.
11.5.3 Smalltalk-76 Dan finished the Smalltalk-76 design in November, and he, Dave Robson, Ted Kaehler, and Diana Merry successfully implemented the system from scratch (which included rewriting all the existing class definitions) in just seven months. This was such a wonderful achievement that I was bowled over in spite of my wanting to start over. It was fast, lively, could handle "big" problems, and was great fun. The system consisted of about 50 classes described in about 180 pages of source code. This included all of the OS functions, files, printing, and other Ethernet services, the window interface, editors, graphics and painting systems, and two new contributions by Larry Tesler, the famous browsers for static methods in the inheritance hierarchy, and dynamic contexts tor debugging in the run-ume environment. In every way it was the consolidation of all our 554
CHAPTER Xl
PAPER: THE EARLY HISTORY OF SMALLTALK
Class new title: 'Window'; fields= 'frame'; asFollows!
This is a superclass for presenting windows on the display. It holds control until the stylus is depressed outside. While it holds control, it distributes messages to itself based on user actions. Scheduling gtartup [ [frame contains: stylus => self enter. repeat: [frame contains: stylus loc => [keybard active => [self keyboard] stylus down => [self pendown]] self outside => [] stylus down => [^self leave]]] ^false] I t Default Event Responses 1 enter [self show] leave outside [^false] pendown keyboard [keyboard next. frame flash] Image show [frame outline: 2. titleframe put: self title at: frame origin + titleframe complement] . . . etc.
: means keyword whose following
expression will be sent =by value" : means keyword whose following
expression will be sent =by name"
^ means Usend back" => means "then"
title loc.
FIGURE 11.54 Smalltalk-76 Metaphysics
Class new title= 'DocWindow'; subclassof: Window; flelds= 'document scrollbar edit Menu'; asFollows!
j/.,...-..,%
User events are passed on to the document while the window is active. If the stylus goes out of the window, scrollbar and the editMenu are each given a chance to gain control.
/.~S,2;.NUMBER
Event R e s p o n s e s enter [self show.editMenu show.scrollbar show] leave [document hideselection.editMenu hide.scrollbar hide]
outside [editMenu startup => [] scrollbar startup => [self showDoc] ^flase] pendown [document pendown] keyboard [document keyboard]
--
- - i
°
Image I supermeansdelegate message show [super show.self showDoc] ~ ne~highersupemlass showDoc [doucument showin: frame at: scrollbar position] title [^document title]
SMALLTALK SESSION
555
ALAN C. KAY FIGURE
11.55 Dan Ingalls,the mainimplementerof Smalitalk,creatorof Smalltalk-76,and his implementationplan(fight) PI~OTECT ~ISTO~Y
I
I
I
I
r
I I fl
t
ideas and yearnings about Smalltalk in one integrated package. All Smalltalks since have resembled this conception very closely. In many ways, as Tony Hoare once remarked about ALGOL, Dan's Smalltalk-76 was a great improvement on its successors! Here are two stylish ST-76 classes written by Dan. Notice, particularly in class Window, how the code is expressed as goals for other objects (or itself) to achieve. The superclass Window's main job is to notice events and distribute them as messages to its subclasses. In the example, a document window (a subclass of DocWindow) is going to deal with the effects of user interactions. The Window class will notice that the keyboard is active and send a message to itself that will be intercepted by the subclass method. If there is no method the character will be thrown away and the window will flash. In this case, it finds DocWindow method: keyboard, which tells the held document to check it out. In January of 1978 Smalltaik-76 had its first real test. CSL had invited the top ten executives of Xerox to PARC for a two-day seminar on software, with a special emphasis on complexity and what could be done about it. LRG got asked to give them a hands-on experience in end-user programming so "they could do 'something real' over two 1 1/2 hour sessions." We immediately decided not to teach them Smalltalk-76 (my "burn our disk packs" point in spades), but to create in two months in Smalltalk-76 a rich system especially tailored for adult nonexpert users (Dan's point in trumps). We took our "Simpula" job shop simulation model as a starting point and decided to build a user interface for a generalized job shop simulation tool that the executives could make into specific dynamic simulations that would act out their changing states by animating graphics on the screen. We called it the Smalltalk SimKit. This was a maximum effort and everyone pitched in. Adele became the design leader in spite of the very recent appearance of a new baby. I have a priceless memory of her debugging away on the SimKit while simultaneously nursing Rachel! There were many interesting problems to be solved. The system itself was straightforward but it had to be completely sealed off from Smailtalk proper, particularly with regard to error messages. Dave Robson came up with a nice scheme (almost an expert system) to capture complaints from the bowels of Smalltalk and translated them into meaningful SimKit terms. There were many user interface details--some workaday, such as making new browsers that could only look at the four SimKit classes (Station, Worker, Job, Report), and some more surprising as when we tried it on ten PARC nontechnical adults of about the same age and found that they could not read the screen very well. The small fonts our thirtysomething year-old eyes were used to did not work for those in their 5556
CHAPTER Xl
PAPER: THF EARLY HISTORY OF SMALLTALK FIGURE 11.56 Jack Goldman finally uses the system he paid for all those years (with Alan Borning helping)
FIGURE 11.57 An end-ttser simulation by a Xerox executive, in SimKit. Total time including training: 3 hours ....
i,=arl,l*.
w~ I I
pm~t~w
i
pf~Ic
I
¢nvlkmi
Iiltltfi lulling
dolt
fifties. This led to a nice introduction to the system in which the executives were encouraged to customize me screen by choosing among different fonts and sizes with the side effect that they learned how to use the mouse unselfconsciously. On the morning of the "big day" Ted Kaehler decided to make a change in the virtual memory system OOZE to speed it up a little. We all held our breaths, but such was the clarity of the design and the confidence of the implementers that it did work, and the executive hands-on was a howling success. About an hour into the first session one of the VPs (who had written a few programs in FORTRAN 15 years before) finally realized he was programming and mused "so it's finally come to this." Nine out of the ten executives were able to finish a simulation problem that related to their specific interests. One of the most interesting and sophisticated was a PC board production line done by the head of a Xerox-owned company using actual figures (that he carried around in his head) to prime a model that could not be solved easily by closed form mathematics--ht revealed a serious flaw in the disposition of workers, given the line's average probability of manufacturing defects. FIGURE 11.58 Alan Borning's Thinglab, a constraintbased iconic problem solver ~n~!41ftbll¢I~ll
' ~ i
l*,t~r=r' h i',l .... mitiit',."oilt,¢i ~~l.i ~},ll l ~' l(th l "~. . . . . . . . l. I¢~ llllll'll"
'"
' ,h let{ ,thtll',l."I~rtn~'r l lI nilllt,k"l l l~ l i l Il~ ~,
' ..............
'. , Because most HW today does a virtual address translation of some kind to find the real addressba trap---it is quite possible to hide the overhead of the OOP dispatch in the MMU overhead that has already been rationalized. Again, the whole point of OOP is not to have to worry about what is inside an object. Objects made on different machines and with different languages should be able to talk to each other--and will have to in the future. Late-binding here involves trapping incompatibilities into recompatibility methods--a good discussion of some of the issues is found in [Popek 1984]. Staying with the metaphor of late-binding, what further late-binding schemes might we expect to see? One of the nicest late-binding schemes that is being experimented with is the rnetaobjectprotocol work at Xerox PARC [Kiczales 1991 ]. The notion is that the language designer's choice for the internal representation of instances, variables, and the like, may not cover what the implementer needs. So within afixed semantics they allow the implementer to give the system strategies for example, using a hashed lookup for slots in an instance instead of direct indexing. These are then efficiently compiled and extend the base implementation of the system. This is a direct descendant of similar directions from the past of Simula, FLEX, CDL, Smalltalk, and Actors. Another late-binding scheme that is already necessary is to get away from direct protocol matching when a new object shows up in a system of objects. In other words, if someone sends you an object from halfway around the world it will be unusual if it conforms to your local protocols. At some point it will be easier to have it carry even more information about itself--enough so its specifications can be "understood" and its configuration into your mix done by the more subtle matching of inference. A look beyond OOP as we know it today can also be done by thinking about late-binding. Prolog's great idea is that it does not need bindings to values in order to carry out computations. The variable is an object, and a web of partial results can be built to be filled in when a binding is finally found. Eurisko constructs its methods--and modifies its basic strategies--as it tries to solve a problem, Instead of a problem looking for methods, the methods look for problemsband Eurisko looks for the methods of the methods. This has been called "opportunistic programming"--4 think of it as a drive for more enlightenment, in which problems get resolved as part of the process. This higher computational finesse will be needed as the next paradigm shift--that of pervasive networking--takes place over the next five years. Objects will gradually become active agents and will travel the networks in search of useful information and tools for their managers. Objects brought back into a computational environment from halfway around the world will not be able to confugure themselves by direct protocol matching as do objects today. Instead, the objects will carry much more information about themselves in a form that permits inferential docking. Some of the ongoing work in specification can be turned to this task. Tongue i n cheek, I once characterized progress in programming languages as a kind of "sunspot" theory, in which major advances took place about every 11 years. We started with machine code in 1950, then in 1956 FORTRAN came along as a "better old thing" which, if looked at as "almost a new thing," became the precursor of ALGOL-60 in 1961. In 1966, SIMULA was the "better old thing," which if looked at as "almost a new thing" became the precursor of Smalltalk in 1972.
562
CHAPTER Xl
PAPER: THE EARLY HISTORY OF SMALLTALK
Everything seemed set up to confirm the "theory" once more: In 1978, Eurisko was in place as the "better old thing" that was "almost a new thing." But 1983--and the whole decade---came and went without the "new thing." Of course, such a theory is silly anyway--and yet, I think the enormous commercialization of personal computing has smothered much of the kind of work that used to go on in universities and research labs, by sucking the talented kids towards practical applications. With companies so risk-adverse towards doing their own HW, and the HW companies betraying no real understanding of sw, the result has been a great step backwards in most repects. A twentieth century problem is that technology has become too "easy." When it was hard to do anything, whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. This is inverse vandalism: the making of things because you can. Couple this to even less sophisticated buyers and you have generated an exploitation marketplace similar to that set up for teenagers, A counter to this is to generate enormous dissatisfaction with one's designs, using the entire history of human art as a standard and goad. Then the trick is to decouple the dissatisfaction from self-worth--otherwise it is either too depressing or one stops too soon with trivial results. I will leave the story of early Smalltalk in 1981 when an extensive series of articles on Smalltalk-80 was published in Byte magazine [Byte 1981], followed by Adele's and Dave Robson's books [Goidberg 1983] and the official release of the system in 1983. Now programmers could easily implement the virtual machine without having to reinvent it, and, in several cases, groups were able to roll their own image of basic classes. In spite of having to run almost everywhere on moribund hw architectures, Smalitalk has proliferated amazingly well (in part because of tremendous optimization efforts on these machines) [Deutsch 1989]. As far as I can tell, it still seems to be the most widely used system that claims to be object-oriented. It is incredible to me that no one since has come up with a qualitatively better idea that is as simple, elegant, easy to program, practical, and comprehensive. (It is a pity that we did not know about PROLOG then or vice versa; the combinations of the two languages done subsequently are quite intriguing.) While justly applauding Dan, Adele, and the others who made Smalltalk possible, we must wonder at the same time: where are the Dans and Adeles of the '80s and '90s who will take us to the next stage?
SMALLTALK SESSION
563
ALAN C. KAY
APPENDIX h PERSONAL COMPUTER MEMO Smalltalk Program Evolution From a Memo on me " K i d ~ K o m p u ~ ' :
To: Butler Lampson, George Pake Subject:
Chuck Thacker,
Bill English,
Jerry Elkind,
"KiddiKomputer"
Date: May 15, 1972
4. January 1972 The Reading Machine. Another attempt to work on the actual problem of a personal computer. Every part of this gadget (except display) is buildable now but requires some custom chip design and fabrication. This is discussed more completely later on. A meeting was held with all three labs to try to stimulate invention of the display. B. Utility i. I think the uses for a personal gadget as an editor, reader, take-home-context, intelligent terminal, etc. are fairly obvious and greatly needed by adults. The idea of having kids use it implies (possibly) a few more constraints having to do with size, weight, cost, and capacity. I have been begging this question under the assumptions that a size and weight that are good for kids will be super acceptable to adults, and that the gadget will almost inescapably have CPU power to burn (more than PDP-10): implies larger scale use by adults can be gotten by buying more memory and maybe a cache. 2. Although there are many ~educational" things that can be done once the device is built, I have had four basic projects in mind from the start. a. Teaching "thinking" (& la Papert) through giving the kids a franchise for the strategies, tactics, and model visualization that are the fun (and important) part of the design and debugging of programs. Fringe benefits include usage as a medium for symbols allowing editing of text and pictures. b. Teaching "models" through "simulation" of systems with similar semantics and different syntax. This could be grouped with (a) although the emphasis is a bit different. The initial two systems would be music and programming and would be an extension of some stuff I did at Utah in 1969-1970 with the organ/computer there. c. Teaching "interface" skills such as "seeing" and "hearing." The initial "seeing" project would be an investigation into how reading might be taught via combining iconic and audible representation of works in a manner reminiscent of Bloomfield and Moore. This would
564
CHAPTER Xl
PAPER: THE EARLY HISTORY OF SMALLTALK require a c o r o l l a r y inquiry into why good readers do so m u c h b e t t e r than average readers. A farther off project in the domain of sight w o u l d be an i n v e s t i g a t i o n into the nature and t o p o l o g y of kids' internal models for objects and an effort to p e r s e r v e iconic imagery from b e i n g totally r e p l a c e d by a relational model. d. Finding out what children w o u l d do (if anything) "unofficially" during non-school hours w i t h such a gadget through invisible 'demons", w h i c h are little p r o c e s s e s that w a t c h surreptitiously. 3. Second Level Projects a. The notion of e v a l u a t i o n (partly an extension of 2.a.) an important p l a t e a u in "algorithmic thinking."
represents
b. Iconic programming. If we believe Piaget and Bruner, kids deal m o s t l y w i t h icons before the age of 8 rather than symbolic references. Most p e o p l e who teach p r o g r a m m i n g say there is a r e m a r k a b l e d i f f e r e n c e b e t w e e n 3rd and 4th grades. W h a t e v e r an iconic p r o g r a m m i n g language is, it had better be c o n s i d e r a b l y more stylish and viable than GRAIL and AMBIT/G. I feel that this is a way to reach very y o u n g kids and is t r e m e n d o u s l y important.
C. The V i a b i l i t y Of m i n i C O M It was n o t e d earlier that m i n i C O M is only barely p o r t a b l e for a child. Does it have a future for adults and/or as a functional testbed for kids? If only one is needed, the answer seems to be no since -$15k will simulate its function in a n o n - p o r t a b l e fashion. If more than one is n e c e s s a r y (say I0 or more), then the cheapest way to get functions of this kind is to design and build it. Rationalizations
for b u i l d i n g a bunch of them:
i. It will a l l o w us to find out some things not' p r e d i c t a b l e or d i s c o v e r a b l e by any other path. A perfect case in point is our character g e n e r a t o r through w h i c h we have found some a b s o l u t e l y a s t o u n d i n g and u n s u s p e c t e d things about human p e r c e p t i o n and raster scan television w h i c h will greatly further d i s p l a y design. It has p a i d its way already. 2. The learning experiments not involving p o r t a b i l i t y can be done for a r e a s o n a b l e cost and will allow us to get into the real w o r l d w h i c h is a b s o l u t e l y n e c e s s a r y for the future of learning r e s e a r c h at PARC. 3. It will
foster some new thoughts in small c o m p u t e r s y s t e m design.
It has already sparked the original "jaggies" investigation. The minimal nice serifed c h a r a c t e r fonts were done because of cost and space limitations. There are some details w h i c h have been h a n d w a v e d into the w o o d w o r k w h i c h really neeed to be solved seriously: p h i l o s o p h y of i n s t r u c t i o n set, compile or interpret, mapping, and I/O control.
SMALLTALK SESSION
565
ALAN C. KAY 4. It will be a useful "take home" editor and terminal for PARC people. It is a b s u r d to think of u s i n g a m u l t i d i m e n s i o n a l m e d i u m d u r i n g the day (NLS, etc.), then at night going home to a i D AJ or worse: d u m p i n g s t r u c t u r e d ideas on paper. 5. It is not u n r e a s o n a b l e to think of the gadget as an attempt at a c o s t - e f f e c t i v e node for a future office system. As such, it s h o u l d be d e v e l o p e d in p a r a l l e l w i t h the more exotic and greatly more e x p e n s i v e luxury system. 6. It is not clear that the more ideal device (A.4.), requiring custom chip design, can be done well without us knowing quite a bit more about this kind of system.
A P P E N D I X I1: S M A L L T A L K I N T E R P R E T E R D E S I G N When ! set out to win the bet, 1 realized that many of the details that have to be stated explicitly in McCarthy's elegant scheme can be finessed. For example, if there were objects that could handle various kinds of partial message receipt, such as evaluated, unevaluated, literal, and the like, then there would be no need to put any of those details in the eval. This is analogous to not having cond as a "special form," but instead to finding a basic building block in which COND can be defined like any other subpart. One way to do this was to use the approach of Dave Fisher, in which the no-man's land of control structures is made accessable by providing a protected way to access and change the relationships of the static and dynamic environment [Fisher 1970]. In an object-based scheme, the protection can be provided by the objects themselves and many of Fisher's techniques are even easier to use. The effect of all this is to extend the eval by distributing it: both to the individual objects that participate in it and dynamically as the language is extended. I also decided to ignore the metaphysics of objects even though it was clear that, unlike Simula, in a full blown OOPL classes had to exist at run-time as "first-class" objects--indeed, there should be nothing but first-class objects. So there had to be a "class-class" whose instances were classes, class-class had to be an instance of itself, there had to be a "class-object" that would terminate any subclassing that might be done, and so forth. All of this could be part of the argument concerning what I didn't have to show to win the bet. The biggest problem remaining was that I wanted to have a much nicer syntax than LISP and I did not want to use any of my precious "half-page" to write even a simple translator. Somehow the eval had to be designed so that syntax got specified as part of the use of the system, not in its basic definition. 1 wanted the interpretation to go from left to right. In an OOP, we can choose to interpret the syntax rule for expressions as meaning: the first element will be evaluated into the instance that will receive the message, and everything that follows will be the message. What should expressions like a+b and ci UNTIL
...
Indefinite loop terminating when < f > iB 'true'
BEGIN . . .
< f > WHILE . . .
BEGIN
AGAIN
...
IF
...
ELSE
IF
...
THEN
REPEAT
Indefinite loop terminating when < f > :Ls 'false' Infinite loop
...
THEN
Two-branch conditional; performs words following IF if < f > J.s 'true' and words following ELSE if it is 'false'. THEN marks the point at which the paths merge. Like the two-branch conditional, but with only a 'true' clause.
FORTH-79 and FORTH-83 provided syntactic specifications for the common structures listed in Table 13.4, as well as an "experimental" collection of structure primitives. The latter were not widely adopted, however, and few implementations perform the kind of syntax checking the standards anticipated. F83 offers a limited form of syntax checking, in that it requires the stack, which is used at compile-time for compiling structures, to have the same size before and after compiling a definition, the theory being that a stack imbalance would indicate an incomplete structure. Unfortunately, this technique prevents the very common practice of leaving a value on the compile-time stack which is to be compiled as a literal inside a definition. Common practice often took advantage of knowledge about how the structure words worked at compile-time to manipulate them in creative ways. The ANS Forth Technical Committee sanctioned this by providing specifications of both the compile-time and run-time behaviors of the structure words, so that they may be combined in arbitrary order. A set of structure primitives is provided in a "programming tools" wordset, and the word POSTPONE is provided to enable programmers to write new structure words that reference existing compiler directives, in order to provide a portion of the desired new behavior. 13.5.2
Implementation Strategies
The original Forth systems, developed by Moore in the 1970s, compiled source from disk into an executable form in memory. This avoided the separate compile-link-load sequences characteristic of most compiled languages, and led to a very interactive programming style in which the programmer could use the resident Forth editor to modify source and recompile it, having it available for testing in seconds. "['he internal structure of a definition was as shown in Fig. 13.2, with all fields contiguous in memory. The FIG model and its derivatives modified the details of this structure somewhat, but preserved its essential character. Forth systems implemented according to this model built a high-level definition by compiling pointers to previously defined words into its parameter field; the address interpreter, that executed such definitions, proceeded through these routines, executing the referenced definitions in turn by performing indirect jumps through the register used to keep its place. This is generally referred to as indirect-threaded code.
650
CHAPTER Xlll
PAPER:THE EVOLUTIONOF FORTH FIGURE 13.2 Diagram showing the logical componentsof a Forth definition. In classical implementations,these fields are contiguous in memory.The data field will hold values for data objects,addresses,or tokens for procedures,and the actual code for CODE definitions.
Address of next definition in search order NAME
I
LINK
I
CODE
DATA
Address of code to J execute this class of word The need to optimize, for different conditions, has led to a number of variants in this basic implementation strategy, however. Some of the most interesting are: 1. Direct threaded code. In this model, the code field contains machine code instead of a pointer-to-machine code. This is somewhat faster, but typically costs extra bytes for some classes of words. It is most prevalent on 32-bit systems. 2. Subroutine-threaded code. In this model, the compiler places a jump-to-subroutine instruction with the destination address in-line. This technique costs extra bytes for each compiled reference on a 16-bit system. It is often slower than direct-threaded code, but it is an enabling technique to allow the progression to native code generation. 3. Native code generation. Going one step beyond subroutine-threaded code, this technique generates in-line machine instructions for simple primitives such as + and jumps to other high-level routines. The result can run much faster, at some cost in size and compiler complexity. Native code can be more difficult to debug than threaded code. This technique is characteristic of optimized systems for the Forth chips such as the RTX, and on 32-bit systems where code compactness is often less critical than speed. 4. Optimizing compilers. A variant of native code generation, these were invented for the Forth processors that can execute several Forth primitives in a single cycle. They looked for the patterns that could be handled in this way and automatically generated the appropriate instruction. The range of optimization was governed by the capabilities of the processor; for example, the polyFORTH compiler for the Novix and RTX processors had a four-element peephole window. 5. Token threading. This technique compiles references to other words using a token, such as an index into a table, which is more compact than an absolute address. Token threading was used in a version of Forth for a Panasonic hand-held computer developed in the early 1980s, for example, and is a key element in MacForth. 6. Segmented architectures. The 80x86 family supports segmented address spaces. Some Forths take advantage of this to enable a 16-bit system to support programs larger than 64K. Similarly, implementations for Harvard-architecture processors such as the 8051 and TI TMS320 series manage separate code and data spaces. Although the early standards assumed the classical structure, ANS Forth makes a special effort to avoid assumptions about implementation techniques, resulting in prohibitions against assuming a
FORTH SESSION
651
E. RATHER, D.R.COLBURN, & C.H. MOORE
relationship between the head and data space of a definition or accessing the body of a data structure other than by predefined operators. This has generated some controversy among programmers who prefer the freedom to make such assumptions over the optimizations that are possible with alternative implementation strategies. 13.5.3
Object-Oriented Extensions
Forth's support for custom data types with user-defined structure, as well as compile-time and run-time behaviors, has, over the years, led programmers to develop object-based systems such as Moore's approach to image processing described in Section 13.2.2.2, item 2. Pountain [1987] described one approach to object-oriented programming in Forth, which has been tried by a number of implementors. Several Forth vendors have taken other approaches to implementing object-based systems, and this is currently one of the most fertile areas of exploration in Forth. In 1984, Charles Duff introduced an object-oriented system written in Forth called Neon [Duff 1984 a & b]. When Duff discontinued supporting it in the late '80s, it was taken over by Bob Lowenstein, of the University of Chicago's Yerkes Observatory, where it is available as a public-domain system under the name Yerk. More recently, Michael Hore re-implemented Neon using a subroutine-threaded code; the result is available (also in the public domain) under the name MOPS. Both Yerk and MOPS are available as down-loadable files on a number of Forth-oriented electronic bulletin boards listed at the end of this paper.
13.6
A POSTERIORI EVALUATION
The early development of FORTH was, in many ways, quite different from that of most other programming languages. Whereas they generally emerged full featured, with unambiguous formal specifications for language syntax and semantics, Forth enjoyed a lengthy, dynamic adolescence, in which each fundamental presupposition of the language was tested on the anvil of actual applications experience. During this period, Moore, unencumbered by a large following of users, often made revolutionary changes to the language on a daily basis, to suit his current view of what the language should be. He had complete control and responsibility for the machine at hand, from the first bootstrap loader to the completed application. The language converged toward the actual needs of one man solving a broad class of technically challenging problems in resource-constrained environments. The resulting method of problem solving, expressed by the resulting de facto language specification, has proven useful to others. Given the complete flexibility to add syntax checking, data typing, and other more formal structures often considered essential to programming languages, most of the several hundred people who have independently implemented versions of Forth for their own use have not done so. The results of their efforts, as surveyed by the ANS Forth Technical Committee, represent a startlingly democratic ratification of Moore's personal vision.
13.6.1
Meeting Objectives
Without a formal language design specification citing clearly defined objectives, we can only evaluate the stated objectives of the inventor of the language and those who have used it. Personal productivity and intellectual portability were Moore's primary stated objectives. Forth has been ported across the vast majority of programmable computers and has been embodied in several different dedicated Forth computer architectures.
652
CHAPTER Xlll
PAPER: THE EVOLUTION OF FORTH
In 1979, Chuck Moore looked back on ten years' experience with Forth and observed [Moore 1979]: My original goal was to write more than 40 programs in my life. 1 think 1 have increased my throughput by a factor of 10. I don't think that throughput is program-language limited any longer, so I have accomplished what I set out to do. I have a tool that is very effective in my hands--it seems that it is very effective in others' hands as well. I am happy and proud that this is true. Today he sees no reason to change this assessment. The developers of FIG Forth saw their systems spread all over the world, along with chapters of their organization, and influence Forth programmers everywhere. Their goal of instantiating additional commercial vendors of Forth products was also achieved. Of the many entrepreneurs who committed their careers and fortunes to Forth-based enterprises, few have become rich and famous for their efforts. But most have had the satisfaction of seeing their own productivity increased just as Moore did, and of having seen seemingly impossible project objectives met because of the power and flexibility of the language. They have also enjoyed prosperity in making this capability available to their clients and customers. Given Moore's criteria of productivity and portability, perhaps the best measure of achieving these objectives is the very large quantity and range of application programs that have been written in Forth by a small number of programmers across a very broad variety of computers. 13.6.2
Major Contributions of Forth
In 1984, Leo Brodie wrote a book on designing Forth applications called Thinking Forth [Brodie 1984]. In it, he quoted a number of Forth programmers on their design and coding practices. In an Epilogue, several of them commented that Forth had significantly influenced their programming style in other languages, and indeed their approaches to problem solving in general. Here are two examples, which are typical of observations of Forth users in general: [The] essence of good Forth programming is the art of factoring procedures into useful free-standing words. The idea of the Forth word had unexpected implications for laboratory hardware design. Instead of building a big, monolithic, all-purpose Interface, 1 found myself building piles of simple little boxes which worked a lot like Forth words: they had a fixed set of standard inputs and outputs, they performed just one function, they were designed to connect up to each other without much effort, and they were simple enough that you could tell what a box did just by looking at its label . . . . Because Forth is small, and because Forth gives its users control over their machines, Forth lets humans control their applications. It's just silly to expect scientists to sit in front of a lab computer playing "twenty questions" with packaged software. Forth... lets a scientist instruct the computer instead of letting the computer instruct the scientist. -
-
Mark Bernstein, president of Eastgate Systems, Inc., Cambridge, MA
Forth has changed my thinking in many ways. Since learning Forth I've coded in other languages, including assembler, BASIC and FORTRAN. I've found that I used the same kind of decomposition we do in Forth, in the sense of creating words and grouping them together. More fundamentally, Forth has reaffirmed my faith in simplicity. Most people go out and attack problems with complicated tools. But simpler tools are available and more useful. m Jerry Boutelle, owner of Nautilus Systems, Santa Cruz, CA
FORTH SESSION
653
E. RATHER, D.R.COLBURN, & C.H. MOORE
Mitch Bradley reports [Bradley 1991] that the design of the Forth-based Open Boot has significantly influenced the thinking of the people at Sun Microsystems who are responsible for the low-level interfaces in the Unix kernel. Open Boot design philosophy is influencing driver interfaces, the device naming system, and the early startup and configuration mechanisms. There is even talk of unifying the syntax of several disparate kernel configuration files by using Forth syntax and including a subset Forth interpreter in the Unix kernel. People at Sun, who have worked with Open Boot, are impressed by the fact that the simple postfix syntax never "runs out of steam" or "paints you into a corner." 13.6.3
Mistakes or Desired Changes
Forth has a chameleon-like capacity to adapt to any particular application need. Indeed, the process of programming in Forth is to add to it application-oriented words at increasingly high levels until all the desired functionality is implemented. So, for any project, or even any particular programming group, any perceived needs will be promptly addressed. When looking for "mistakes" then, the most useful questions to ask are, "What were the things that a significant number of implementors have chosen to change or add?" and, "What are the characteristics of the language that may have prevented its wider acceptance?" One of the first actions taken by the ANS Forth Technical Committee, when it formed in 1987, was to poll several hundred Forth implementors and users to determine their views on problems in the language that needed to be addressed. The issues cited fell into three categories: "mistakes" in one or both of the existing standards (e.g., incompatibilities introduced by FORTH-83 and anomalies such as an awkward specification for arguments to DO); obsolete restrictions in FORTH-83 (mainly the reliance on a 16-bit architecture); and a need for standards for such things as host file access, floating point arithmetic, and so forth. Features in the latter group were, by then, offered by most commercial and many public-domain systems, but as they had been developed independently, there was variance in usage and practice. ANS Forth has attempted to address all these concerns. In retrospect, however, the lack of standard facilities for such things as floating-point arithmetic, which are covered by other languages, has probably impeded widespread acceptance of Forth. It's insufficient to point out that most commercial systems offer them, if the public perception of the language is formed by a standard that omits any mention of such features! From this perspective, the ANS Forth effort has come almost too late. Another difficulty is that Forth's very identity is unclear: it is not only unconventional in appearance with its reliance on an overt stack architecture and postfix notation, but it broadly straddles territory conventionally occupied by not only languages, but also operating systems, editors, utilities, and the like, that most people are accustomed to viewing as independent entities. As a result, it's difficult to give a simple answer to the question of what it is. The integrated character of Forth is viewed by its practitioners as its greatest asset. As Bradley [ 1991 ] expresses it, Forth has taught me that the 'firewalls' between different components of a programming environment (i.e., the different syntax used by compilers, linkers, command interpreters, etc.) are very annoying, and it is much more pleasant to have a uniform environment where you can do any thing at any level at any time, using the same syntax. Duncan [1991], however, believes that this seamless integration of Forth the language, Forth the virtual machine, and Forth the programming environment is a significant barrier to mainstream acceptance. He notes that the same has been observed regarding Smalltalk versus C++:
654
CHAPTER Xlll
PAPER:THE EVOLUTIONOF FORTH I have been using C++ for some months now, and the very things about C++ that frustrate me--the language is not written in itself (thus there is no way to use the building blocks for the programming environment as part of the application), the language is not truly extensible (e.g., the operators for the native data types cannot be overridden), and there is no programming environment that is smart about the language and class hierarchies--are the things that traditional language experts see as assets for C++ compared to Smalltalk! As long as Forth users are convinced that its integrated, intrinsically interactive character is the key to their productivity as programmers, however, it is unlikely to change.
13.6.4
Problems
Some languages tend to be "levelers:" that is, a program written by an expert is unlikely to be significantly better (smaller, faster, and so forth) than one written by a novice. Chuck Moore once observed [Moore 19?9], "...FORT[-] is an amplifier. A good programmer can do a fantastic job with FORTH; a bad programmer can do a disastrous one." Although never quantified, this observation has been repeated on many Forth projects across a broad programmer population, and has achieved the status of "folk wisdom" within the Forth community. This tendency has given Forth the reputation of being "unmanageable," and there have been some highly publicized "Forth disasters" (notably Epson's YALDOCS project in the early 1980s). On close examination, however, the root causes of this, and other failed Forth projects, are the same problems that doom projects using other languages: inadequate definition, poor management, and unrealistic expectations. There have also been a number of Forth successes, such as the facility management system for the Saudi Arabian airport mentioned before, in which a project that was estimated to contain 300,000 lines of executable FORTRAN, PLM, and assembly language software was totally redesigned, recoded in Forth, and tested to the satisfaction of the customer in only eighteen months [Rather 1985]. The result ran more than a factor of ten faster. Jack Woehr, a senior project manager for Vesta Technologies, observes [Woehr 1991] that successful management of Forth projects demands nothing more than generally good management practices, plus, an appreciation of the special pride that Forth programmers take in their unusual productivity. Forth rewards a management style that believes a small team of highly skilled professionals can do a better job, in a shorter time, at less overall cost, than a large group of more junior programmers.
13.6.5
Implications for Current and Future Languages
What can be learned from 20 years experience with Forth? Forth stands as a living challenge to many of the assumptions guiding language developers. Its lack of rigid syntax and strong data typing, for example, are characteristically listed as major advantages by Forth programmers. The informal, interactive relationship between a Forth system and its programmer has been shown through many projects to shorten development times, in comparison with more conventional tools such as C. Despite the tremendous increases in the size and power of modern computers, Forth's combination of easy programming, compact size, and fast performance (characteristics often thought to be mutually exclusive) continues to earn a loyal following among software developers, especially for embedded systems.
FORTH SESSION
655
E. RATHER, D.R.COLBURN, & C.H. MOORE
REFERENCES [ANS 1991] Draft ProposedANS Forth, document number X3.215-199x, available from Global Engineering Documents, 2805 McGaw Ave., lrvine, CA, 92714. [Baden, 1986] Baden, W., Hacking Forth, Proceedings of the Eighth FORML Conference, pub. by the Forth Interest Group, P. O. Box 8231, San Jose, CA 95155, 1986. [Ballard, 1991] Ballard, B., and Hayes, J., Forth and space at the applied physics laboratory, in Proceedings of the 1991 Rochester Forth Conference, Rochester, NY: Forth Institute, 1991. [Bradley, 1991] Bradley, M., private communication, 7/8/91. [Brodie, 1981] Brodie, L., Starting FORTH, Englewood Cliffs, NJ: Prentice Hall, 1981. [Brodie, 1984] Brodie, L., Thinking FORTH, Englewood Cliffs, NJ: Prentice Hall, 1984. [Cox, 1987] Cox, William C., A case for NPOSs in real-time applications, I&CS Magazine (pub. by Chiiton), Oct. 1987. [Derick, 1982] Derick, M., and Baker, L., The Forth Encyclopedia. Mountain View, CA: The Mountain View Press, 1982. [Dewar, 1970] Dewar, R., Indirect threaded code, Communications of the A CM, Vol. 18, No. 6, 1975. [Dijkstrn, 1970] Dijkstra, E. W., Structured programming, Software Engineering Techniques, Buxton, J. N., and Randell, B., eds. Brussels, Belgium, NATO Science Committee, 1969. [Duff, 1984a] Duff, C., and Iverson, N., Forth meets Smalltalk, Journal t~fForth Application and Research, Vol. 2, No. i, 1984. [Duff, 1984b] Duff, C., Neon--Extending Forth in new directions, Proceedings of the 1984 Asilomar FORML Conference pub. by the Forth Interest Group, P. O. Box 8231, San Jose, CA 95155, 1984. [Dumse, 1984] Dumse, R., The R65FI 1 and F68K single chip FORTH computers, Journal t~t'ForthApplication and Research, Vol. 2, No. 1, 1984. [Duncan, 1988] Duncan, R., (Gen'l Ed.). The MS-DOS Encyclopedia. Redmond, WA: Microsoft Press, 1988. [Duncan, 1991] Duncan, R., private communication, 7/5/91. [Electronics, 1976] RCA may offer memory-saving processor language. Electronics, Feb. 19, 1976, p. 26. [FIG, 1978] Forth Dimensions, Vol. 1, No. i, June/July 1978, pub. by the Forth Interest Group, P. O. Box 8231, San Jose, CA 95155. [FIG, 1983] Forth Dimensions, Vol. 5, No. 3, Sept./Oct., 1983, pub. by the Forth Interest Group, P. O. Box 8231, San Jose, CA 95155. [Gehrz, 1978] Gehrz, R. D., and Hackwell, J. A., Explonng the infrared universe from Wyoming. Sky and Telescope (June 1978). [Golden, 1985] Golden, J., Moore, C. H., and Brodie, L., Fast processor chip takes its instructions directly from Forth, Electronic Design, Mar. 21, 1985. [Hart, 1968] Hart, J. E etal., Computer Approximations. Malabar, FL: Krieger, 1968; (Second Edition), 1978. [Hayes, 1987] Hayes, J. R., Fraeman, M. E., Williams, R. L , and Zaremba, T., A 32-bit Forth microprocessor, Journal c~fForth Application and Research, Vol. 5, No. 1, 1987. [Knuth, ! 974] Knuth, D. E., Structured programming with go to statements. Computing Reviews, #4, ! 974. [Moore, 1958] Moore, C. H., and Lantman, D. A., Predictions for photographic tracking stations--APO Ephemeris 4 in SAO Special Report #11, G. E Schilling, Ed., Cambridge, MA: Smithsonian Astrophysical Observatory, 1958. [Moore, 1970a] Moore, C. H., and Leach, G. C., FORTH--A Language for Interactive Computing, Amsterdam, NY: Mohasco Industries Inc. (internal pub.) 1970. [Moore, 1970b] Moore, C. H., Programming a Problem-orientedLanguage, Amsterdam, NY: Mohasco Industries Inc. (internal pub.) 1970. [Moore, ! 974a] Moore, C. H., FORTH: A new way to program a computer, Astronomy & Astrophysics Supplement Series, Vol. 15, No. 3, Jun. 1974. Pn~'eedings of the Symposium on CoUection and Analysis t~f Astrophysical Data at NRAO, Charlottesville, VA, Nov. 13-15, 1972. [Moore, 1974b] Moore, C. H., and Rather, E. D., The FORTH program for spectral line observing on NRAO's 36 ft telescope, Astronomy & Astrophysics Supplement Series, Vol. 15, No. 3, June 1974, Proceedings t~t"the Symposium on the Collection and Analysis of Astrophysical Data, Charlottesville, VA, Nov. 13-15, 1972. [Moore, 1979] Moore, C. H., FORTH, The Last Ten Years and the Next Two Weeks..., Address at the first FORTH Convention, San Francisco, CA, October 1979, reprinted in l~rth Dimensions, Vol. 1, No. 6, 1980. [Moore, 1983] Moore, C. H., Letter to the Editor of Forth Dimensions, Vol. 3, No. l, i 983. [Paioski, 1986] Paloski, W. H., Odette, L., and Krever, A. J., Use of a Forth-based Prolog for real-time expert system, Journal of Forth Application and Research, Vol. 4, No. 2, 1986. [Fountain, 1987] Pountain, R., Object Oriented Forth. New York: Academic Press, 1987. [Parn&% 1971] Parnas, D. L., Information distribution aspects of design methodology, Proceedings oflFIP 1971 Congress. Ljubljana, Yugoslavia.
656
CHAPTER Xlll
PAPER: THE EVOLUTION OF FORTH [Phys. Sci. 1975] Graphics in Kitt form, Physical Science, Nov. 1975, p. 10. [Rather, 1972] Rather, E. D., and Moore, C. H., FORTH programmer's guide, NRAO Computer Division Internal Report #11, 1972. A later version, with J. M. Hollis added as a coauthor, was Internal Report #17, 1974. [Rather, 1976a] Rather, E. D., and Moore, C. H., The FORTH approach to operating systems, Proceedings ttfthe ACM, Oct. 1976, pp. 233-240. [Rather, 1976b] Rather, E. D., and Moore, C. H., High-level programming for microprocessors, Proceedings of Electro 76. [Rather, 1985] Rather, E. D., Fifteen programmers, 400 computers, 36,000 sensors and Forth, Journal rtfForth Application and Research, Vol. 3, No. 2, 1985. Available from the Forth Institute, P.~O. Box 27686, Rochester, NY, 14627. [Sperry, 1991] Sperry, T., An enemy of the people. Embedded Systems Programming, Vol. 4, No. 12, Dec. 1991. [Taylor, 1980] Taylor, A., Alternative software making great strides. ComputerworM, 12/.9/80. [TRS-80, ! 979] Press release published in "Software and Peripherals" section of Minicomputer News, 8/30/79. [Veis, 1960] Veis, G., and Moore, C. H., SAO differential orbit improvement program, Tracking Programs and Orbit Determination Seminar Proceedings, Pasadena, CA: Jet Propulsion Laboratories, 1960. [Woehr, 1991] Woehr, J. J., Managing Forth projects, Embedded Systems Programming, May 1991. [Wood, 1986] Wood, R. J., Developing real-time process control in space. Journal of Forth Application and Research, Vol. 4, No. 2, 1986.
BIBLIOGRAPHY Brodie, L., Starting FORTH, Englewood Cliffs, NJ: Prentice Hall, 1981. Brodie, L., Thinking FORTH, Englewood Cliffs, N J: Prentice Hall, 1984. Feierbach, G., and Thomas, P., Forth lbols & Applications, Reston, VA: Reston Computer Books, 1985. Haydon, G. B., All about Forth: An Annotated Glossary, La Honda CA: Mountain View Press, 1990. Kelly, M. G., and Spies, N., FORTH: A Text and Reference, Englewood Cliffs, N J: Prentice Hall, 1986. Knecht, K., Introduction to Forth, Howard Sams & Co., Indiana, 1982. Kogge, P. M., An architectural trail to threaded code systems, IEEE Computer, Mar. 1982. Koopman, P., Stack Computers, The New Wave, Chichester, West Sussex, England: Ellis Horwood Ltd. 1989 Martin, T., A Bibliography ofh~rth References, (Third Edition), Rochester, NY: Institute for Applied Forth Research, 1987. McCabe, C. K., Forth Fundamentals (2 volumes), Oregon: Dilithium Press, 1983. Moore, C. H., The evolution of FORTH--An unusual language, Byte, Aug. 1980. Ouverson, M. (Ed)., Dr. Dobbs Toolbook of Forth, Redwood City, CA: M&T Press, Vol. i, 1986; Vol. 2, i 987. Pountain, R., Object Oriented Forth, New York: Academic Press, 1987. Rather, E. D., Forth programming language, Encyclopedia ttfPhysical Science & Technology (Vol. 5), New York: Academic Press, 1987. Rather, E. D., FORTH, Computer Programming Management, Anerbach Publishers, Inc., 1985. Terry, J. D., Library of Forth Routines and Utilities, New York: Shadow Lawn Press, 1986. Tracy, M., and Anderson, A., Mastering Forth (Second Edition), New York: Brady Books, 1989. Winfield, A., The Complete Forth, New York: Wiley Books, 1983.
Forth Organizations ACM/SIGForth, Association for Computing Machinery, 1515 Broadway, New York, NY 10036. Publishers of the quarterly SIGForth newsletter, sponsor of annual conference (usually in March). The Forth Institute, 70 Elmwood Dr., Rochester, NY 1461 I. Publishers of the Journal (tfForth Application and Research and sponsors of the annual Rochester Forth Conference (usually in June). Proceedings of these Conferences are also published. The Forth Interest Group, P. O. Box 8231, San Jose, CA 95155. Publishers of Forth Dimensions (newsletter), source of various books on Forth and public-domain Forth systems; also coordinator for worldwide chapters and sponsor of annual FORML conference (usually in November).
On-line Resources BIX (ByteNet) (for information call 800-227-2983) Forth Conference. Access BIX via TymNet, then type j Forth. Type FORTH at the : prompt.
FORTH SESSION
657
ELIZABETH RATHER
CompuServe(forinformationcall 800-848-8990)ForthForumsponsoredby CreativeSolutions,Inc.TypeGO FORTHat the ! prompt. GEnie (for information call 800-638-9636) Forth Round Table. Call GEnie local node,then type FORTH. Sponsoredby the Forth InterestGroup. Also connectedvia cross-postingswith lnternet (comp.lang.fortb) and other Forth conferences.
AUTHORS' NOTE (7/95) The purpose of this addendum is to present a few significant events that have occurred since its original presentation: 1. Concerning Table 13.3 (Section 13.3.2), the systems listed for Bradley Forthware are now available from FirmWorks, of Mountain View, CA, and Palo Alto Shipping is no longer in business. 2. The Forth-based underlying technology in Sun Microsystems' "Open Boot" (Section 13.3.3.1 ) was standardized as IEEE Std 1275-1994, IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices, and is available from IEEE, 345 E. 47th St., New York, NY 10017, USA. 3. ANS Forth (Section 13.5.1) received final approval March 24, 1994, and is now available as
American National Standard for Information Systems--Programming Languages--Forth, Document X3.215-1994, from American National Standards Institute, 11 W. 42nd St., 13th Floor, New York, NY 10036. 4. The BIX and GEnie bulletin boards are now replaced by the Internet newsgroup comp.lang.forth.
TRANSCRIPT OF PRESENTATION SESSION CHAIR HELEN GIGLEY: Elizabeth Rather holds A.B. and M.A. degrees from the University of California, Berkeley, and an M.B.A. from Pepperdine University. Her programming experiences span FORTRAN, COBOL, BASIC, APL, NELIAC, over a dozen different assemblers, and of course, Forth. She met her first computer in 1962, the ORACLE, at Oak Ridge National Laboratory. It had vacuum tubes and reels of tape for memory. She managed data analysis for a physics group there, and went on to computing jobs in the Astronomy Department at UC, Berkeley. Later jobs included processing student records for the College of Letters and Science at Berkeley and the University of Arizona. Her first minicomputer experience was in 1971, at the National Radio Astronomy Observatory's, Tucson, Arizona, Division. Here she met Chuck Moore, the inventor of Forth, who was sitting on a high stool in front of the machine. This encounter, and the language called Forth, changed her career. Ms. Rather has been president of Forth Inc. since 1988, where she has managed the development of products and services for scientific and industrial computer applications. Currently, Forth Inc. is introducing a software development system for process control and automated manufacturing. ELIZABETHRATHER: (SLIDE 1) I want to start out by introducing ourselves briefly. I'm sorry my two coauthors couldn't make it. They consist of Chuck Moore, who was the inventor of Forth--and with the discussion of"designed," with respect to languages and whatever, I will stick to "invention" as being the correct word in this case. He certainly never "designed" it in the sense of thinking it through. I'm not sure that if he had, he would have ever gotten started. He conceived of it, from the outset, as a personal productivity tool that, in the long run, got out of control, as some of them tend
658
CHAPTER Xlll
TRANSCRIPT OF FORTH PRESENTATION
i•i•iiii•ii!iiiii•i•iiiii!iiiiiiii•iii•!iiiiiiiiiiiiiiiiiiiii•iiiiiiiii•iiiiiiiiiiiiiiiiiiiiiii!ii!i•i••iii•History iii•!iiiiiiiii•i!ofiii the Forth Language iiiiii.iiii!iliiiiiiiiliiiliiilii ii!il:fi e ;;i u i i0 n Oii
tlq:: :iii:iiiiiii!iiliiiii:iiii
liiiiiiiiiiiiiiiiiii!:i!iiiii:!!:i!:l
• 1969 - - F a ¢ ~ saline Iliven to C k u c l t M ~ ' s MahaJco ladmtoi~ • 1971 - -
~ ~taad.mlolte F m ' t h (~m-wtm-y
N y
Forth F ] ) R T H , Inc. frmnded ~ b ~ t aIT4Jte-~belf praduct frmn F()RTH, Inc. Fm-Ut I ~ (:t~mp founded
1972 - -
~
1973 - 1977 - 197a - -
197'9 - -
iiiiiiiiiiiii!iiiiiiiiiiiiiiiiii~iiiiiiiiiiiiiii iii iii~lo~i!a~iii
p ¢ ~ r a m m l l g g ionlluUge mt
at NmamudRadio A
n t ~ r
f'lrst l x t M i d N d mlandard {FOllfl'H79) qpecld lame on F o r t h
19~9 - - B Y T E
iiiiiiiiiiiiiiiiiiiiiii iiiii iiiii iiiiiiii iii!i!ii iii!iii!iii!iiiiiiiiiiii
1St1 - - Starthqf F O R T H
IM3 --
I.anst
punished; has t~dd 125,000teplts
puMisbed st,mdard ( F O R T H a 3 ) of Fortk Applicationsand R ~ c a r c k
km~ of Jt~rr~l • IM7 --
ANS Fectb TC mpprevcdand ~ work first ~onferc~ dpANS Forth published fro"puldlc review
• IM9 -- SIGFm'tk kt~s • 1991 - -
~dv~
SLIDE 2
SLIDE 1
to do. For the last ten years, he has been involved in doing hardware implementations of various Forth based processors for general and specific applications, none of which have been commercially successful. Don Colburn, my other coauthor, was one of the founders of The Forth Interest Group, and one of the earliest independent developers of commercial Forth systems. He currently is the proprietor of a company that sells the most successful version of Forth for Macintoshes and also Nubus boards. He also works as a teacher's aide in an elementary school in Maryland one day a week. (SLIDE 2) The history of Forth goes back, actually, a long way, as you can see in the paper--which I am not going to entirely summarize. Forth had precedents way back in the early '60s, in work that Chuck did at the Smithsonian Astrophysical Observatory and other places. It first acquired the name "Forth" in 1969. It was supposed to suggest a "fourth generation" computer. At the time, the "third generation" was big, and he saw the fourth generation as being distributed small computers--which in many respects was accurate. Just as "Schemer" became "Scheme," his compiler would only handle five. So the "u" went away. There has been a lot of history, much of which is covered in the paper. My talk, like others, is going to be in the form of footnotes. On the other hand, you can say that by seeing this slide, you can go home now or get ready for dinner. But, I do have a few more remarks. (SLIDE 3) Chuck is an unusual person, and it's been a great treat knowing him. But I could not talk about Forth without talking a little bit about his philosophy and what some of his attitudes were. I have summarized it there, but just to give you a little flavor, I will read a couple of excerpts from a
Chuck's Philosophy & Goals GOAL: Replace "vast hierarchy" of languages, compilers,/assemblers, OSs, editors ... with a single layer having 2 elements:
Everything vs. Anything
CONVENTIONAL
APPROACH:
• progcammer-to-Forth interface
Yon can't change your tools, so they most be able to handle everything you might do.
• Forth-to-machine interface
(big, slow, complex, hard to learn & maintain) FORTH'S
PRINCIPLES: • Keep it simple! • Do not speculate! • Do it yourselP.
SLIDE 3 FORTH SESSION
APPROACH:
Make the tool easily adaptable to do anything you need. (small, fast, simple, flexible; application-oriented tool sets)
SLIDE 4 659
ELIZABETH RATHER
book he wrote in about 1970, which was never published. He said, "In connection with these principles, do not put code in your program that might be used." He was very much opposed to the notion of "hooks"--people putting hooks in and making provisions for something that might come up in the future he thinks that simply leads to unsanitary code. He says: Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each has 0 probability of realization. If you need an extension later, you can code it later--and probably do a better job than if you did it now. And if someone else adds the extension, will he notice the hooks you left? Will you document this aspect of your program? Well, certainly not. And even more "Chuckish" was his notion of writing everything himself. In the entire time I've known him, which is well over 20 years, he has yet to use any code that actually came from a manufacturer with their computer, including their assembler or their math (multiply and divide) routines. (In the '70s, you had to have software multiply, divide, and so on.) He said: The conventional approach, enforced to a greater or lesser extent, is that you should use a standard subroutine. I say you should write your own subroutines. Before you can write your own subroutines, you have to know how. This means, to be practical, that you've written it before; which makes it difficult to get started. But give it a try. After writing the same subroutine a dozen times on as many computers and languages you'll be pretty good at it. (SLIDE 4) More particularly, his view was that the application programmer, who was the target of his effort, is an intelligent, responsible, creative person, who deserves and needs empowering tools. It was his perception, based on a number of years of experience, that the software tools that were provided, were generally designed with the view of the programmer as being simple minded, at best, and irresponsible in most cases (and possibly even with criminal intent), who needed externally imposed discipline, in order to stay out of trouble. He had quite the opposite approach. (SLIDE 5) The language that he built over the years had some unique features. This is a summary of some of them. They were unique for Chuck in that, although he spent a good part of his career around academic science, it was not computer science, and he really has never been involved in the reading and writing of papers, where these kinds of ideas are disseminated. Nonetheless, he came up with a lot of them entirely on his own. I remember distinctly when I was giving papers on Forth in the early '70s, somebody said, "What you are talking about sounds an awful lot like structured programming;" and I said, "What's that?" And they directed me to the appropriate papers, which I read with great interest and passed along to Chuck. He said, "Well I don't see what all the fuss is about; it just looks like good programming to me." And I think that is fairly representative of his ideas. He was working empirically, trying to make the kinds of tools that he saw being necessary. (SLIDE 6) The first running, full stand-alone Forth system at NRAO (National Radio Astronomy Observatory) that I worked on, which was really the first stand-alone Forth system, was controlling a radio telescope. I found out, much to my astonishment, last Fall, that system is still in use. Unfortunately, they are about to tear down the telescope. So for all I know, the program is going to outlive the telescope--which is kind of unusual. (SLIDE 7) Relevant to Chuck's remark about writing the same program a number of times, he actually implemented Forth personally on over 17 computers. I tried to research this list as best I could; there may be some that aren't on it. But he wrote the entire system for this many computers, and other people have written many more since. In doing one of these implementations, you had to start off by designing the assembler and writing an assembler--and then coding about a hundred assembly language primitives using that assembler, then getting it all to work. Forth was written in Forth. You used a friendly Forth computer to generate Forth for the new computer that you were
660
CHAPTER Xlll
T R A N S C R I P T O F FORTH PRESENTATION
Early Uses, Independent Discoveries and Heresies • "Structured
Programming"
• Two computers, connected b y a l - b i t link (1971-2).
-- 196%72
• "Type-free" data structures -- 196%70
• Postfix notation & dual stack operation - - 1 9 6 8 • Indirect threaded c o d e ~ 1 9 7 0 • Improved integer math operators ( * / , / M O D ,
First Forths at NRAO
etc.)
- - 197/I) • Completely self-contained environment ~ 1971
• Concurlamt command & control of 36' radio t d c s c o p e , p l u s d a t a a c q u i s i t i o n & g r a p h i c a l analysis. • Upgraded
to single PDP-U
terminals in 1 9 7 3 .
w/4
(T.'T"-'~
• Non-preemptive real-time multitasklng/multluser executive-- 1 9 7 2 • Object-oriented teclmlques ~ 1976-8
~
~lm eeq ~n~wm S e~w mmml
Stnal
SLIDE 5
SLIDE 6
working on. But nonetheless, that's a lot of work to do. What's really astonishing is that he did this in approximately two weeks for each one--including writing the software multiply and divide routines--which were invariably faster that the ones than came from the manufacturer, which is a great source of pride to him. I would also like to point out that on several of these computers: the Honeywell 316, the (Honeywell) DDP 116, the Varian 620, the Honeywell Level 6, the Intel 8086, and the Raytheon PTS-10(Owhich is a pretty obscure computer--on all of these, Forth was the first high-level language running on that processor. We were working on the 8086, while it was still in prototype, and in fact, helped Intel find a couple of bugs in the part. (SLIDE 8) This is a list of some of the early projects so that you will see what kinds of applications influenced the early growth of Forth. Unlike Icon, we very definitely had applications in mind. Forth has, from day one, been designed for use in applications, and the applications in which it was used in the early days had a lot of influence. So it's been very well integrated with the real world. We traveled a lot to do these systems. Chuck built a personal portable computer in the mid-70s out of one of the first LSI-1 Is, which he packaged in a suitcase, and put a floppy disk in another suitcase. We carried that with us to go and install the systems on these various computers. (SLIDE 9) As a result of those applications, and the influences of those kinds of applications, the critical factors in Forth became: operating in a resource-constrained environment; placing a high degree of emphasis on size and compactness of code; operating with very high performance
Chuck's Forths Yemr Model
ForthAppltmtlom
1970-71 Htlneyw¢ll H316 I)ala m.:quishkya,on-line analysis w/graphics Icrnlinal 1971 I loncywcll DDPII6 Radio t¢lc~opc cootrol 1971-2 IBM 370¢30 I)ata analysis 1972 Varlan 620 Optical tck~ope cootrol alld Instrulx~enlalk~ 1972 liP2100 In.ttnlmclltalion 1972-3 Modcomp I~dta anidysis 1973 PDP- I 1 Radio tclel~-'opectrl., data aequi~ltl~l, analysis, graphics 1973 DG Nova Dataacquisition mid anidy~ls 1974 S]~L'-16 Gruond etmtrol of balloon- I~tw~ telest.~pe 1975 SDS-920 AolCntla¢otdl~ 1975 I~lr¢ Enviroqlmentaltyontrols 1976 P.tlr-IqlaSe I)ala entry and tiara base rlr,magemenl 1977 Intcrdata Series 32 Data hast m~agement 1977 CA I.~1-4 Businesssysten~t 1978 I k:¢lcyw¢llLevel 6 Data entry arid data b~z~cmanagemenl 1978 lntcl StY6 Ca'al~lcs and Image Prt~csalu s 1980 Raylhetm IVl'S-I(!O Airlioe display and woekstalams
SLIDE 7 FORTH SESSION
Early, Influential Projects • B u s i n e s s D a t a Base: Cybek C o r p . , 1 9 7 4 D G / N o v a . 32 t e r m i n a l s ( u p g r a d e d t(~ 6 4 ) , 3IX) M b disk
>I(X).000 t r a n s a c t i o n ~ d a y . ;
behavior>
DOES>
,run.
• The bold words in the following definition are
Example: : 2ARRAY DOES>
• Designated by the word I M M E D I A T E . IMMZDIATE:
(n) ( i a
CREATE - a')
DUP , 2* CELLS SWAP 2* CELLS +
: SHOW DATA
ALLOT ;
N 2@
0 DO i0 D . R
I 5 M O D 0= LOOP ;
IF
CR THENI
Use: 1000
CONSTANT
: SHOW DATA
N
N 2ARRAY
N 0 DO I 5 MOD 2@ i0 D.R LOOP
0= ;
SLIDE 15
Example of new compiler directive:
DATA IF
CR
THEN
I
:
-IF POSTPONE IMMEDIATE
NOT
POSTPONE
IF
;
SLIDE 16
at the beginning of the array that is supplied internally, and returns the address of the item. And it does it by multiplying the index by two, converting that to cells, and adding it the address. So these things are very simple and it shows how that's used in the definition. But some of these can be very complex. You can make datatypes that live as bits on an I/O interface or very elaborate things that are application dependent. It's very easy to define such structures. (SLIDE 16) Another interesting feature is that it's easy to add compiler directives; compiler directives are structure words. And here, for example, we have DO and LOOP, and I F and THEN. If you wanted to make a negative I F , you could do that very simply by defining POSTPONE NOT POSTPONE I F . In these two cases, POSTPONE makes a definition which is going to compile a reference to NOT and a reference to IF. When the word containing NOT I F is executed, which is executed at compile-time to create the structure. So it is very easy for a programmer to add extensions, even to the compiler. (SLIDE 17) Here is a somewhat more complex example. This shows a number of the different logical structures in it. It also has a number of application-dependent words in it. Without telling you all those words are, I think you can probably get the sense of the definition. But we have here, an indefinite BEGIN UNTIL loop; this will work until FULL returns t r u e . The next loop is going to run from 0 to 24; it's a DO LOOP that begins here, and ends there. This is a !("Store") operator; it's going to store the value BLACKBIRD in the location P I E , and then do BAKE. Here is a c o n d i tional-when it is opened, then BIRDS WILL SING. After P I E is a @ ("fetch") operation. You fetch a value, compare it against the value DAINTY; if the result of the comparison is t r u e , then you execute KING and SERVE, and so on. (SLIDE 18) Many Forths have operating system capabilities. All of the Forths that I have personally ever worked on have been multi-tasking, multi-user systems, although not all Forths are that way. Many Forths are completely native, that is, they run with no host operating system. Many others run concurrently with another operating system, and there are versions available right now for most processors and most of the popular operating systems. (SLIDE 19) These are some of the recent contemporary uses of Forth. The big areas where it is useful are, not surprisingly, those for which it was developed, that is, embedded systems and high performance control systems. Every Federal Express Courier carries one in his hand, when he picks up his package. Every Sun workstation has a Forth system on its mother-board. The "Open Boot" is currently the subject of an IEEE standard (1275) that's in development, and a number of VME system people are picking that up. There have been a lot of space applications; the control systems, just as
664
CHAPTER XlII
TRANSCRIPT OF FORTH PRESENTATION
OS Issues
Is Forth Readable?
SONG 6 PENCE SING BEGIN RYX POCKZT I FULL UNTIL 24 0 D O BLACKBIRD PIE I LOOP O P E N IF BIRDS SING THEN P I E • D A I N T Y ffi I F KING SERVE THEN I
SLIDE 17
• Native vs. co-resident operation Native systems extremely fast Market pressures often demand OS compatibility Use of blocks provides transportability •
Multitasking Non-preemptive task scheduling Multitasking can run within a co-resident Forth
SLIDE 18
an example, the King Khaled International Airport in Riyadh, Saudi Arabia, is a system that involves approximately 500 computers. That project was done actually here in the Boston area, in the mid 1980s. There was a program that was about 300,000 lines of FORTRAN and Assembly language, that did not work fast enough or well enough. That program was replaced with an all Forth system. The 300,000 line program was, in fact, replaced by a Forth system which was written from scratch, tested, and installed in about an 18-month period, and consisted of about 30,000 lines of code. The leverage I was speaking of earlier results in considerable compactness of code, even to do a very complex application. It supports rapid prototyping very easily and works out very well in those kinds of applications. (SLIDE 20) Quantitatively, it is very hard to measure how many people are using Forth. Our best estimates are perhaps a few tens of thousands of people. But, it is very difficult to track them all. There have been two surveys. These two magazines do surveys every even numbered year. So, I assume they did it in 1992, but I haven't seen the results yet. I just wanted to give you some measure of where it is, and the answer is, it is a minority, but it is hanging in there. (SLIDE 21) The purpose of listing some suppliers of Forth systems is really, as much as anything, to give you a feeling for some of the diversity of some of the implementations available. There is a very definite family tree here. I was admiring the work in the Lisp paper--which I heard about--sketching out a family tree. I would love to do this for Forth. There are several major sources
Contemporary Uses of Forth • Embedded Systems Federal Express' "SupcrTracker" Sun Microsystems' "Open B(mt" Issues: efficiency in resource-constrained environments, easy debugging of custom hardware • Space >30 known successful shuttle & satellite applications by N A S A , Johns Hopkins APL, others Issues: flexibility, modularity (thorough testing) • Control systems King Khaled International Airlx)rt GM/Saturn's HVAC system Issues: security, flexibility, quick development time
SLIDE FORTH SESSION
19
Extent of Use Source: Dr. Dobbs Journal Survey, 1990 • 12% of readers use Forth • Forth places 15th of 20 languages, ahead of Mt~iula 2, Smalltalk, APL, Actor, Eiffel Source: EDN (Cahners Research) Report, 1990 • 1 I % of readers use F o r t h • Forth places IOth o f 15 languages, ahead of Prolog, Modula 2, PI_I1, APL, Smalltalk
SLIDE 20 665
ELIZABETH RATHER
Success Factors
Selected Forth Vendors Company
Prhlmry IJroduct~ & M*ttt¢~ Brldlt7 Forlhwam Forth written in C; Forth for AI~'L Macinlosh. Sun; aetvices fro Sun Mtcrosysten~ Open Boot. C ~ f l v e ~dul~,w., I ~ . Ftnth for Macintosh.Nultus boards Forth for the Amiga D d ~ R~,*rtqll Industrial systems on IICSand others; interaz,'tivecross-compilers; F( )RTH. Inc. programmingscrvtec~ Forth for the IBM-PC family Harvard Softwo¢~ Forth f ~ PCs w/DOS. OS2 and Windows;cross compilers for I,almrmm'y Microvat'. ClqJs I ~ (LMI) |hlblic,~omtlthsystem for PC, porl~l by olh~s Io other plalftwms l,axm mid Pesrt-y Miller Mkt'~:e~la~ tint IBM-PC family; bushl¢"~~d commercialapl~icaflons Scrvk~ M kl'~" Eng. PC~and embctkledsystems M ~an4ala Vlew I ~ I*ublic.-(Jomalnsyslem on a variety of platforms opto-~ Forth ftw II IWOl~etaryembetkledconlmller SMkea CempmeJ.s Software and hardware relined to Forth-ba.uxlprt.,cemlt,s Sun M k-re,Rylnm **OpenBe,ol" oil SPARCwofkltthlJon~ T. Z i l ~ * ~ sL Extensivepebllc.-domalnsystem for I1",¢IBM-PC family
SLIDE
21
• Right place, right time: advent of laps in late '71Is • Enthusiastic disciples to spread the word • There's a market for simple, emclent
systems • Good programmers thrive with respect & control
SLIDE
22
of things, ranging from some of the early commercial implementations to some of the public domain systems. There has been actually a considerable "war" in the Forth community between the vendors and suppliers of public domain systems. Remember, the early work on Forth was at a government laboratory so, therefore, the concept is public domain, but there have been a number of commercial applications. The fans of the public domain systems believe that it is in fact immoral to make money off it. Those of us who do make money off it, think that tends to contribute to language improvement and growth over time. So, it's sort of a "communist" versus "capitalist" issue that can be debated at length. (SLIDE 22) Looking at a few success factors. Why has Forth survived now for over 20 years? It came along, in terms of its real promulgation, at the right time. In the late '70s, it was beginning to mature--and that was a time when microprocessors were there and available. They were more or less mother-naked as far as software was considered, and a lot of people became interested. A lot of very enthusiastic Forth users have spread the word, in spite of the fact that there has never been any major deep-pocket corporate or academic sponsorship at all--worse luck. And, I think, as much as anything else, the fact that it survived, means that there is a market for this kind of thing. And to look at what kind of market that is, I think it's fair to ask what kind of problem it's trying to solve. In the Ada talk, there was the issue of 2,500 line programs versus, say, 25 million line programs. And as I think I've said, these things in the world of Forth are not linear. Something that might be a 300,000 line FORTRAN and assembler program translates into 30,000 lines of Forth. It's very nonlinear there, and Forth does tend to shrink the problem. Nonetheless, it is probably true that for very, very large programs, Forth is not the best approach. I think there is the question of whether your programming philosophy, or the philosophy of your shop, really, is the theory that "a million monkeys with word processors can produce Shakespeare"--and that's going to lead to one kind of view of what software tools you need--versus the "Marine Corps" philosophy--"we need a few good programmers"--kind of thing. And that's really the philosophy that Forth is attempting to enable and support. (SLIDE 23) So, why hasn't it taken over the world? Well, it's very different. You can write the language that looks a lot like all the other languages, and people say, "Oh yeah, I understand that." And Forth is really quite different. There are a lot of heresies, such as the lack of data typing--regardless of how well they work in practice. People are sometimes uncomfortable looking at it from the outside; it's hard to visualize how well it can work. As I said, there have never been any major corporate or academic sponsors of it, although it's used, you know we conduct guerilla warfare whenever we can; it's used in virtually all the major corporations and educational institutions. It's hanging in there!
666
CHAPTER Xlll
TRANSCRIPT OF FORTH PRESENTATION
Constraining Factors • Too different, too many heresies
• No major corporate or academic sponsors • Successful u s e r s r e g a r d e d it as a "secret weapon" • Unsuccessful users found it an easy scapegeat • Diverse dialects prevented development of widely used l i b r a r i e s
Prognosis • A d o p t i o n Of A N S F o r t h will help several ways: - Standard interface will promote development o f libraries - Management fears of"non-standard languages" defused - Opportunity fi)r new t e x t ~ m k s and other support aids - More c o m m o n culture for Forth programmers
M i x e d blessing: • P u b l i c domain versions were widely circulated In the '80s, but created a " h o b b y i s t " i m a g e of F o r t h
SLIDE
23
• F o r t h will persist as a m i n o r i t y language, able to
create "miracles" for those who need them.
SLIDE
24
But a lot of our users have, in fact, been reluctant to give away to the competition the secret to their success--why they can do so much more with so much less. There have also been a few projects that have not worked out, and it's been awfully easy in that case, when you have a failed project that was done in a minority language, to say, "Well of course it failed, you used that funny language." There has been some amount of publicity about a small number of"Forth disasters." I doubt that there have been any languages that haven't had their share of project disasters. If you are using the language that 99 percent of people use, however, and you have a disaster, it's a lot harder to blame it on the language, isn't it? In fact, I have looked at some of the publicized, so-called Forth disasters. I know a number of people that were involved in at least one of them, and the problems there were the same problems in just about all disaster projects, having to do with management problems, design problems, things like that. Then, finally, there has been the problem of diverse dialects. There have been several industry standards. There was one in 1979 called FORTH-79, that was picked up by several implementers, a much better one in 1983 called FORTH-83. For the last six years, there has been an ANS Forth committee (at) work. I do want to extend my condolences to the new Smalltalk [ANS] committee. People shook their heads and clucked pityingly at me when we got started [on ANS Forth], and I ' m going to do the same thing for you--and you'll find out why. We do have a draft standard out for public review--for the third time, right now--and most of us on the committee feel like "this is it!" I think that's going to help. In the early '80s, there were a lot of public domain versions that were circulated, and that was, as I say, a mixed blessing. That got a lot of people familiar with Forth who might not have otherwise been. However, the Forth they became familiar with was of very limited functionality, sometimes poorly implemented, and certainly not a well-supported system. And if people have the notion that, "When you've seen one Forth, you've seen them all," they can hardly be blamed for getting a poor impression. However, there have been quite a number of very good implementations, both commercial systems and some of the public domain systems. I think that some people should have perhaps looked a little harder. It has been a factor in the history of the language. (SLIDE 24) Finally, the prognosis. Adoption of ANS Forth is going to help a lot, I think, making up for some of the deficiencies. I think it's a very good standard--of course, being the chair of the committee--we've had a very, very diverse membership on the committee, from all of the dialects and so on. We have made some compromises in a number of places, but I think overall the standard is very clean and very strong. It's unfortunately about 250 pages long. FORTH-79 was about 30 pages.
FORTH SESSION
66'7
TRANSCRIPT OF QUESTION AND ANSWER SESSION
FORTH-83 was about 50 pages. At 250 (pages), this is becoming hefty. But we have done one thing that I think was very successful, and that I would recommend to some of you involved in this effort: that is, we've made it a layered standard; we have a number of optional word-sets. Since Forth was originally designed for resource-constrained environments; there's still strong feeling among Forth users that it should be possible to run Forth in a very small system. And in fact, there are Forths available that run on 8-bit single-chip micro-controllers. That is, the Forth runs on it. The whole thing, the compiler, the assembler, the whole nine yards, can run on an 8-bit single-chip micro-controller, in maybe 8 or 10K. Now, this is not one of the more full functioned Forths, but all the essentials are there. The core required word set in the ANSI standard can run in that kind of environment. Yet, you can put on optional word sets, for floating point, for host OS file access, for memory allocation, whatever you want. There are a number of these things available. I think that has been a very successful concept. If you talked to a Forth programmer and asked him why he's s o . . . people have accused Forth programmers of being sort of wild-eyed fanatics and there is some measure of accuracy in that. If you ask them why, the major reason is that they feel empowered. Your typical Forth programmer (and I ' m not o n e - - I have been, but I ' m a mere manager now) feels that they are suddenly "superman": they've been in the phone booth and they've put on the cape. And all of a sudden, they have the power of ten. I was talking, just last night, to the local Boston Forth Interest Group, and I raised this question--and they all said that they keep getting this from customers and prospective customers, clients, whatever. A lot of them are consultants in corporations trying to persuade their bosses that they ought to be able to use Forth: that they could do in a few weeks what in C is going to take them months. There is a huge wealth of anecdotal evidence, to the effect that this is true. Certainly, as a business, we (Forth, Inc.) have succeeded by doing projects in weeks or months that were projected to take months or years. That has kept us economically viable over the years. We feel very strongly it is because of the tool, that the tool itself creates a productive environment. It's easy to point to a lot of the reasons why. But, with this amount of anecdotal evidence, we nonetheless have a credibility issue. We tell these stories and people say, "We don't believe you; all programming languages are pretty much the same, aren't they?" I would like to close by urging somebody here, who has a sufficiently objective, respectable academic background and knows how to measure these things, and how to apply the metrics, to really take a look at this question. I know that proponents of functional programming make some of the same claims--of orders of magnitude improvement in productivity. Improvements this big deserve to be looked at. They deserve to be looked at honestly by somebody to see if there is something real there. And if so, what is it? What is the factor that makes it work? I'll be happy to supply the data if somebody wants to undertake that. TRANSCRIPT OF QUESTION AND ANSWER SESSION HERBERT KLAEREN (University of Tubingen): The first is, are there any significant differences between Forth and PostScript, apart from PostScript printer-specific dictionaries? ELIZABETH RATHER: It is a very similar concept, and I'm not sure whether the developers of PostScript had seen Forth before or not. One could certainly believe that they might have. It is very similar concept; a lot of differences in detail, but I know of people who are strong in Forth or PostScript can go back and forth, so to speak, quite easily.
HERBERT KLAEREN (University of Tubingen): Can you remember how you came to base your language on the stack paradigm? Were you aware of stack-based code generation methods? 668
CHAPTER XlII
BIOGRAPHIES OF ELIZABETH RATHER & DONALD R. COLBURN
RATHER: I'm not sure. Certainly, Chuck had encountered stack somewhere along the line. I think what is really interesting about Forth, is not that it uses stacks, but in the way in which it uses stacks. The dual stack architecture has proved to be successful, probably not for any formal logical reason, but sort of the same reason the two party system in the United States works better than the 400 party system in some countries. It's a very useful number. People have experimented with different numbers of stacks and the dual stack architecture has persisted, using one stack for parameter passing and another stack for everything else--principally return information, but also a great deal else. I think, really, it's the way that it's used, as much as anything else that's been powerful.
B I O G R A P H Y OF ELIZABETH RATHER
Ms. Rather was a cofounder of FORTH, Inc. and has been President since 1980. She was previously Chief Programmer for the Tucson Division of the National Radio Astronomy Observatory (NRAO), and has programmed and managed computer systems since 1962 at the University of Arizona, the University of California, and the Oak Ridge (Tennessee) National Laboratory. She first worked with Chuck Moore, the inventor of the Forth programming language, at NRAO in 1971. Recognizing the potential capabilities of Forth, she began a campaign of talks and papers on the language that ultimately resulted in its being adopted as a standard in 1978, by the International Astronomical Union (IAU). She has authored, or coauthored, more than a dozen books and papers on Forth. At FORTH, Inc., Ms. Rather has managed projects in a wide variety of fields, including scientific data acquisition and analysis, image processing, database management, networking, embedded systems, and industrial controls, in addition to Forth-based software development systems for over 20 platforms. In 1987 Ms. Rather was instrumental in organizing a Technical Committee commissioned to develop an ANSI Standard for Forth. She was elected Chair of the TC, which in 1993 submitted a completed Standard (X3.215/1994) for final processing by ANSI. Ms. Rather holds BA and MA degrees from the University of California, Berkeley, and an MBA from Pepperdine University. BIOGRAPHY OF DONALD R. COLBURN
Don Colburn has been writing Forth Operating Systems since the late 1970s. He is the author of Multi-Forth TM and MacForth TM, two popular Forth implementations for 68000 based computers. He has been active in the drafting of all Forth Standards-1979, 1983 and recent ANSI effort. Don is a well-known developer for the Apple Macintosh family of computers. He has used the MacForth tools to write drivers for his company, Creative Solutions' popular hardware products, HurdlerTM and HustlerTM. These peripherals add serial, parallel, and prototyping interfaces to the Macintosh. Don is the father of two sons and enjoys volunteering at their schools--making them "well ahead of their time" in computerization. When he is not volunteering at the school, another very important organization he supports is the National Multiple Sclerosis Society. Don has MS and is an active source of encouragement for other MS patients.
FORTH SESSION
669
BIOGRAPHY OF CHARLES H. MOORE
BIOGRAPHY OF CHARLES H. MOORE Chuck Moore was born Charles Havice Moore, II on September 9, 1938 in McKeesport, Pennsylvania. He grew up in Flint, Michigan and was Valedictorian of Central High School in 1956. He received a BS in Physics from MIT in 1960 and is a member of Kappa Sigma. While at MIT he learned FORTRAN and Lisp and programmed data reduction for Moonwatch satellite tracking and the Explorer-I 1 Gamma-ray Satellite. He studied mathematics at Stanford for several years, learned ALGOL and programmed electron-beam transport at SLAC. After freelance programming on minicomputers, he learned COBOL and business programming and became an operating-system guru. In 1968, he invented Forth and used it at NRAO to program radio-telescopes. He, Elizabeth Rather, and Ned Conklin formed Forth, Inc. in 1973, to exploit the opportunities it provides. For 10 years he programmed applications in real-time control and database management. Today Forth, Inc. is a $3M firm selling software products and custom applications. Forth is particularly popular in China and Eastern Europe, where computer resources are still limited. John Peers formed Novix in 1983, with funding from Sysorex. Its plan was to develop hardware implementations of Forth. With Bob Murphy of ICE, Moore designed a microprocessor with Forth primitives as its instruction set. Mostek produced a 4,000 gate array in 31.tCMOS that was an 8 Mips, 16-bit Forth engine. This NC4016 led to a modified NC6016 which was licensed to Harris Semiconductor in 1987. They marketed it as the RTX2000. Harris was granted two patents, with Moore and Murphy as inventors. Computer Cowboys sold several hundred $400 Forth-Kits that incorporated the NC4016. In 1988, Russell Fish proposed a new microprocessor called ShBoom. Moore designed it and Oki Semiconductor produced prototypes on an 8,000 gate array in 1.2l.t CMOS. This constituted a 50 Mips, 32-bit Forth engine. With two technically successful gate-arrays, Moore wanted to produce a custom design. He was by now convinced that existing tools were inadequate. So in 1990 he started developing unique layout and simulation software. Layout is based Upon five layers of square tiles that produce correct-by-design chips. A simple transistor model simulates the entire part and its connections. This was first implemented on ShBoom, and later ported to a 386. He then designed MuP21 with a 20-bit bus and four 5-bit instructions/word as a way to minimize memory cost (only five 4-bit DRAMs). The internal buses are 21 bits to provide a 1M-word addresses for both DRAM and SRAM. MuP stands for Multi-uProcessor. The intent is to achieve parallelism with several independent microprocessors sharing memory. ShBoom had a DMA controller. MuP21 has a video generator--NTSC output with 16 colors--and a memory manager with DRAM, SRAM, and cache timing. Specialized processors can be very simple and effective. Prototypes have been made by Orbit Technologies on their mosaic wafers, and by HP, through the MOSIS prototyping service where 12 to 25 chips cost $3,000 to $6,000 with two-month turn-around. This low cost makes possible iterative development, though project time can be long. After several tries, the design tools and architecture converged to a 100 Mips, 21-bit Forth engine. It is now being upgraded to 300 Mips.
670
CHAPTER XlII
XlV C Session
Chair:
Brent Hailpern
THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE Dennis M. Ritchie AT&T Bell Laboratories Murray Hill, NJ 07974 USA
ABSTRACT The C programming language was devised in the early 1970s as a system implementation language for the nascent Unix operating system. Derived from the typeless language BCPL, it evolved a type structure; created on a tiny machine as a tool to improve a meager programming environment, it has become one of the dominant languages of today. This paper studies its evolution. CONTENTS 14.1 Introduction 14.2 History: The Setting 14.3 Origins: The Languages 14.4 More History 14.5 TbeProblems of B 14.6 Embryonic C 14.7 Neonatal C 14.8 Portability 14.9 Growth in Usage 14.10 Standardization 14.11 Successors 14.12 Critique 14.13 Whence Success7 Acknowledgments References
14.1
INTRODUCTION
This paper is about the development of the C programming language, the influences on it, and the conditions under which it was created. For the sake of brevity, I omit full descriptions of C itself, its parent B [Johnson 1973], and its grandparent BCPL [Richards 1979], and instead concentrate on characteristic elements of each language and how they evolved.
671
DENNIS M. RITCHIE
C came into being in the years 1969-1973, in parallel with the early development of the Unix operating system; the most creative period occurred during 1972. Another spate of changes peaked between 1977 and 1979, when portability of the Unix system was being demonstrated. In the middle of this second period, the first widely available description of the language appeared: The C Programming Language, often called the "white book" or "K&R" [Kernighan 1978], Finally, in the middle 1980s, the language was officially standardized by the ANSI X3J11 committee, which made further changes. Until the early 1980s, although compilers existed for a variety of machine architectures and operating systems, the language was almost exclusively associated with Unix; more recently, its use has spread much more widely, and today it is among the languages most commonly used throughout the computer industry.
14.2
HISTORY:THE SETTING
The late 1960s were a turbulent era for computer systems research at Bell Telephone Laboratories [Ritchie 1978, 1984]. The company was pulling out of the Multics project [Organick 1975], which had started as a joint venture of MIT, General Electric, and Bell Labs; by 1969, Bell Labs management, and even the researchers, came to believe that the promises of Multics could be fulfilled only too late and too expensively. Even before the GE-645 Multics machine was removed from the premises, an informal group, led primarily by Ken Thompson, had begun investigating alternatives. Thompson wanted to create a comfortable computing environment constructed according to his own design, using whatever means were available. His plans, it is evident in retrospect, incorporated many of the innovative aspects of Multics, including an explicit notion of a process as a locus of control, a tree-structured file system, a command interpreter as a user-level program, simple representation of text files, and generalized access to devices. They excluded others, such as unified access to memory and to files. At the start, moreover, he and the rest of us deferred to another pioneering (though not original) element of Multics, namely, writing almost exclusively in a higher-level language. PL/I, the implementation language of Multics, was not much to our tastes, but we were also using other languages, including BCPL, and we regretted losing the advantages of writing programs in a language above the level of assembler, such as ease of writing and clarity of understanding. At the time we did not put much weight on portability; interest in this arose later. Thompson was faced with a hardware environment cramped and spartan even for the time: the DEC PDP-7 on which he started in 1968 was a machine with 8K (18-bit) words of memory and no software useful to him. While wanting to use a higher-level language, he wrote the original Unix system in PDP-7 assembler. At the start, he did not even program on the PDP-7 itself, but instead used a set of macros for the GEMAP assembler on a GE-635 machine. A postprocessor generated a paper tape readable by the PDP-7. These tapes were carried from the GE machine to the PDP-7 for testing until a primitive Unix kernel, an editor, an assembler, a simple shell (command interpreter), and a few utilities (like the Unix rm, cat, cp commands) were completed. After this point, the operating system was self-supporting: programs could be written and tested without resorting to paper tape, and development continued on the PDP-7 itself. Thompson's PDP-7 assembler outdid even DEC's in simplicity; it evaluated expressions and emitted the corresponding bits. There were no libraries, no loader or link editor: the entire source of a program was presented to the assembler, and the output file--with a fixed name--that emerged was directly executable. (This name, a.out, explains a bit of Unix etymology; it is the output of the assembler. Even after the system gained a linker and a means of specifying another name explicitly, it was retained as the default executable result of a compilation.) 672
CHAPTER XIV
PAPER:THE DEVELOPMENTOF THE C PROGRAMMINGLANGUAGE
Not long after Unix first ran on the PDP-7, in 1969, Doug Mcllroy created the new system's first higher-level language: an implementation of McClure's TMG [McClure 1965]. TMG is a language for writing compilers (more generally, TransMoGrifiers) in a top-down, recursive-descent style that combines context-free syntax notation with procedural elements. MclIroy and Bob Morris had used TMG to write the early PL/I compiler for Multics. Challenged by MclIroy's feat in reproducing TMG, Thompson decided that Unix--possibly it had not even been named yet--needed a system programming language. After a rapidly scuttled attempt at FORTRAN, he created, instead, a language of his own that he called B. B can be thought of as C without types; more accurately, it is BCPL squeezed into 8K bytes of memory and filtered through Thompson's brain. Its name most probably represents a contraction of BCPL, though an alternate theory holds that it derives from Bon [Thompson 1969], an unrelated language created by Thompson during the Muitics days. B on in turn was named either after his wife Bonnie, or (according to an encyclopedia quotation in its manual), after a religion whose rituals involve the murmuring of magic formulas. 14.3
ORIGINS: THE LANGUAGES
BCPL was designed by Martin Richards in the mid-1960s while he was visiting MIT, and was used during the early 1970s for several interesting projects, among them the OS6 operating system at Oxford [Stoy 1972], and parts of the seminal Alto work at Xerox PARC [Thacker 1979]. We became familiar with it because the MIT CTSS system [Corbato 1962], on which Richards worked, was used for Multics development. The original BCPL compiler was transported both to Multics and to the GE-635 GECOS system by Rudd Canaday and others at Bell Labs [Canaday 1969]; during the final throes of Multics's life at Bell Labs and immediately after, it was the language of choice among the group of people who would later become involved with Unix. BCPL, B, and C all fit firmly in the traditional procedural family typified by FORTRAN and ALGOL 60. They are particularly oriented towards system programming, are small and compactly described, and are amenable to translation by simple compilers. They are 'close to the machine' in that the abstractions they introduce are readily grounded in the concrete data types and operations supplied by conventional computers, and they rely on library routines for input/output and other interactions with an operating system. With less success, they also use library procedures to specify interesting control constructs such as coroutines and procedure closures. At the same time, their abstractions lie at a sufficiently high level that, with care, portability between machines can be achieved. BCPL, B, and C differ syntactically in many details, but broadly they are similar. Programs consist of a sequence of global declarations and function (procedure) declarations. Procedures can be nested in BCPL, but may not refer to nonstatic objects defined in containing procedures. B and C avoid this restriction by imposing a more severe one: no nested procedures at all. Each of the languages (except for earliest versions of B) recognizes separate compilation, and provides a means for including text from named files. Several syntactic and lexical mechanisms of BCPL are more elegant and regular than those of B and C. For example, BCPL's procedure and data declarations have a more uniform structure, and it supplies a more complete set of looping constructs. Although BCPL programs are notionally supplied from an undelimited stream of characters, clever rules allow most semicolons to be elided after statements that end on a line boundary. B and C omit this convenience, and end most statements with semicolons. In spite of the differences, most of the statements and operators of BCPL map directly into corresponding B and C. C SESSION
673
DENNIS M. RITCHIE
Some of the structural differences between BCPL and B stemmed from limitations on intermediate memory. For example, BCPL declarations may take the form let P1 b e a n d P2 b e a n d P3 b e
command command command
where the program text represented by the commands contains whole procedures. The subdeclarations connected by and occur simultaneously, so the name P3 is known inside procedure P1. Similarly, BCPL can package a group of declarations and statements into an expression that yields a value, for example E1
:= v a l o r
$( d e c l a r a t i o n s
; commands
; resultis
E2
$)
+ 1
The BCPL compiler readily handled such constructs by storing and analyzing a parsed representation of the entire program in memory before producing output. Storage limitations on the B compiler demanded a one-pass technique in which output was generated as soon as possible, and the syntactic redesign that made this possible was carried forward into C. Certain less pleasant aspects of BCPL owed to its own technological problems and were consciously avoided in the design of B. For example, BCPL uses a 'global vector' mechanism for communicating between separately compiled programs. In this scheme, the programmer explicitly associates the name of each externally visible procedure and data object with a numeric offset in the global vector; the linkage is accomplished in the compiled code by using these numeric offsets. B evaded this inconvenience initially by insisting that the entire program be presented all at once to the compiler. Later implementations of B, and all those of C, use a conventional linker to resolve external names occurring in files compiled separately, instead of placing the burden of assigning offsets on the programmer. Other fiddles in the transition from BCPL to B were introduced as a matter of taste, and some remain controversial, for example the decision to use the single character = for assignment instead of :=. Similarly, B uses / ** / to enclose comments, where BCPL uses / / , to ignore text up to the end of the line. The legacy of PL/I is evident here. (C++ has resurrected the BCPL comment convention.) FORTRAN influenced the syntax of declarations: B declarations begin with a specifier like a u t o or s t a t i c , followed by a list of names, and C not only followed this style but ornamented it by placing its type keywords at the start of declarations. Not every difference between the BCPL language documented in Richards's book [Richards 1979] and B was deliberate; we started from an earlier version of BCPL [Richards 1967]. For example, the e n d c a s e that escapes from a BCPL s w i t c h o n statement was not present in the language when we learned it in the 1960s, and so the overloading of the b r e a k keyword to escape from the B and C s w i t c h statement owes to divergent evolution rather than conscious change. In contrast to the pervasive syntax variation that occurred during the creation of B, the core semantic content of BCPL--its type structure and expression evaluation rules--remained intact. Both languages are typeless, or rather have a single data type, the 'word,' or 'cell,' a fixed-length bit pattern. Memory in these languages consists of a linear array of such cells, and the meaning of the contents of a cell depends on the operation applied. The ÷ operator, for example, simply adds its operands using the machine's integer add instruction, and the other arithmetic operations are equally unconscious of the actual meaning of their operands. Because memory is a linear array, it is possible to interpret the value in a cell as an index in this array, and BCPL supplies an operator for this purpose. In the original language it was spelled rv, and later :, whereas B uses the unary *. Thus, i f p is a cell
674
CHAPTER XIV
PAPER: THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE
containing the index of (or address of, or pointer to) another cell, *p refers to the contents of the pointed-to cell, either as a value in an expression or as the target of an assignment. Because pointers in BCPL and B are merely integer indices in the memory array, arithmetic on them is meaningful: ifp is the address of a ceil, then p+ 1 is the address of the next cell. This convention is the basis for the semantics of arrays in both languages. When in BCPL one writes let V = v e c
i0
or in B, a u t o V[lO] ;
the effect is the same: a cell named v is allocated, then another group of 10 contiguous cells is set aside, and the memory index of the first of these is placed into v. By a general rule, in B, the expression * (V+i)
adds v and i, and refers to the i-th location after v. Both BCPL and B each add special notation to sweeten such array accesses; in B, an equivalent expression is V[i] and in B C P L v:i
This approach to arrays was unusual even at the time; C would later assimilate it in an even less conventional way. None of BCPL, B, or C supports character data strongly in the language; each treats strings much like vectors of integers and supplements general rules by a few conventions. In both BCPL and B, a string literal denotes the address of a static area initialized with the characters of the string, packed into cells. In BCPL, the first packed byte contains the number of characters in the string; in B, there is no count and strings are terminated by a special character, which B spelled ' * e ' . This change was made partially to avoid the limitation on the length of a string caused by holding the count in an 8- or 9-bit slot, and partly because maintaining the count seemed, in our experience, less convenient than using a terminator. Individual characters in a BCPL string were usually manipulated by spreading the string out into another array, one character per cell, and then repacking it later; B provided corresponding routines, but people more often used other library functions that accessed or replaced individual characters in a string. 14.4
MORE HISTORY
After the TMG version of B was working, Thompson rewrote B in itself(a bootstrapping step). During development, he continually struggled against memory limitations: each language addition inflated the compiler so it could barely fit, but each rewrite, taking advantage of the feature, reduced its size. For example, B introduced generalized assignment operators, using x=+y to add y to x. The notation came from ALGOL 68 [Wijngaarden 1975] via Mcllroy, who had incorporated it into his version of TMG. (In B and early C, the operator was spelled =+ instead of += ; this mistake, repaired in 1976, was induced by a seductively easy way of handling the first form in B's lexical analyzer.) Thompson went a step further by inventing the + + and - - operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the
C SESSION
675
DENNIS M. RITCHIE
value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11, on which C and Unix first became popular. This is historically impossible, inasmuch as there was no PDP-11 when B was developed. The PDP-7, however, did have a few "auto-increment" memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+l. The B compiler on the PDP-7 did not generate machine instructions, but instead "threaded code" [Bell 1972], an interpretive scheme in which the compiler's output consists of a sequence of addresses of code fragments that perform the elementary operations. The operations typically--in particular for B - - a c t on a simple stack machine, On the PDP-7 Unix system, only a few things were written in B except B itself, because the machine was too small and too slow to do more than experiment; rewriting the operating system and the utilities wholly into B was too expensive a step to seem feasible. At some point, Thompson relieved the address-space crunch by offering a "virtual B" compiler that allowed the interpreted program to occupy more than 8K bytes by paging the code and data within the interpreter, but it was too slow to be practical for the common utilities. Still, some utilities written in B appeared, including an early version of the variable-precision calculator dc familiar to Unix users [MclIroy 1979]. The most ambitious enterprise I undertook was a genuine cross-compiler that translated B to GE-635 machine instructions, not threaded code. It was a small tour de force: a full B compiler, written in its own language and generating code for a 36-bit mainframe, that ran on an 18-bit machine with 4K words of user address space. This project was possible only because of the simplicity of the B language and its run-time system. Although we entertained occasional thoughts about implementing one of the major languages of the time such as FORTRAN, PL/I, or ALGOL 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own. By 1970, the Unix project had shown enough promise that we were able to acquire the new DEC PDP-11. The processor was among the first of its line delivered by DEC, and three months passed before its disk arrived. Making B programs run on it using the threaded technique required only writing the code fragments for the operators, and a simple assembler that I coded in B. Soon, dc became the first interesting program to be tested, before any operating system, on our PDP-11. Almost as rapidly, still waiting for the disk, Thompson recoded the Unix kernel and some basic commands in PDP-11 assembly language. Of the 24K bytes of memory on the machine, the earliest PDP-11 Unix system used 12K bytes for the operating system, a tiny space for user programs, and the remainder as a RAM disk. This version was only for testing, not for real work; the machine marked time by enumerating closed knight's tours on chess boards of various sizes. Once its disk appeared, we quickly migrated to it after transliterating assembly language commands to the PDP-11 dialect, and porting those already in B. By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson's first version of the yacc parser-generator [Johnson 1979a].
676
CHAPTER XlV
PAPER: THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE
14.5 THE PROBLEMS OF B The machines on which we first used BCPL and then B were word-addressed, and these languages' single data type, the "cell," comfortably equated with the hardware machine word. The advent of the PDP-11 exposed several inadequacies of B's semantic model. First, its character-handling mechanisms, inherited with few changes from BCPL, were clumsy: using library procedures to spread packed strings into individual cells and then repack, or to access and replace individual characters, began to feel awkward, even silly, on a byte-oriented machine. Second, although the original PDP-11 did not provide for floating-point arithmetic, the manufacturer promised that it would soon be available. Floating-point operations had been added to BCPL in our Muitics and GCOS compilers by defining special operators, but the mechanism was possible only because on the relevant machines, a single word was large enough to contain a floating-point number; this was not true on the 16-bit PDP-11. Finally, the B and BCPL model implied overhead in dealing with pointers: the language rules, by defining a pointer as an index in an array of words, forced pointers to be represented as word indices. Each pointer reference generated a run-time scale conversion from the pointer to the byte address expected by the hardware. For all these reasons, it seemed that a typing scheme was necessary to cope with characters and byte addressing, and to prepare for the coming floating-point hardware. Other issues, particularly type safety and interface checking, did not seem as important then as they became later. Aside from the problems with the language itself, the B compiler's threaded-code technique yielded programs so much slower than their assembly-language counterparts that we discounted the possibility of recoding the operating system or its central utilities in B. In 1971, I began to extend the B language by adding a character type and also rewrote its compiler to generate PDP-11 machine instructions instead of threaded code. Thus the transition from B to C was contemporaneous with the creation of a compiler capable of producing programs fast and small enough to compete with assembly language. I called the slightly extended language NB, for "new B."
14.6
EMBRYONIC C
NB existed so briefly that no full description of it was written. It supplied the types int and char, arrays of them, and pointers to them, declared in a style typified by int i, j ; c h a r c, d; int i a r r a y [ l O ] ; int i p o i n t e r [] ; char carray[lO] ; char cpointer[] ;
The semantics of arrays remained exactly as in B and BCPL: the declarations of i a r r a y and c a r r a y create cells dynamically initialized with a value pointing to the first of a sequence of 10 integers and characters, respectively. The declarations for i p o i n t e r and c p o i n t e r omit the size, to assert that no storage should be allocated automatically. Within procedures, the language's interpretation of the pointers was identical to that of the array variables: a pointer declaration created a cell differing from an array declaration only in that the programmer was expected to assign a referent, instead of letting the compiler allocate the space and initialize the cell.
C SESSION
677
DENNIS M. RITCHIE
Values stored in the cells bound to array and pointer names were the machine addresses, measured in bytes, of the corresponding storage area. Therefore, indirection through a pointer implied no run-time overhead to scale the pointer from word to byte offset. On the other hand, the machine code for array subscripting and pointer arithmetic now depended on the type of the array or the pointer: to compute iarray [i ] or ipointer+ i implied scaling the addend i by the size of the object referred to. These semantics represented an easy transition from B, and I experimented with them for some months. Problems became evident when I tried to extend the type notation, especially to add structured (record) types. Structures, it seemed, should map in an intuitive way onto memory in the machine, but in a structure containing an array, there was no good place to stash the pointer containing the base of the array, nor any convenient way to arrange that it be initialized. For example, the directory entries of early Unix systems might be described in C as struct
{ int inumber; char name [14] ;
};
I wanted the structure not merely to characterize an abstract object but also to describe a collection of bits that might be read from a directory. Where could the compiler hide the pointer-to-name that the semantics demanded? Even if structures were thought of more abstractly, and the space for pointers could be hidden somehow, how could I handle the technical problem of properly initializing these pointers when allocating a complicated object, perhaps one that specified structures containing arrays containing structures to arbitrary depth? The solution constituted the crucial jump in the evolutionary chain between typeless BCPL and typed C. It eliminated the materialization of the pointer in storage, and instead caused the creation of the pointer when the array name is mentioned in an expression. The rule, which survives in today's C, is that values of array type are converted, when they appear in expressions, into pointers to the first of the objects making up the array. This invention enabled most existing B code to continue to work, despite the underlying shift in the language's semantics. The few programs that assigned new values to an array name to adjust its origin--possible in B and BCPL, meaningless in C--were easily repaired. More important, the new language retained a coherent and workable (if unusual) explanation of the semantics of arrays, while opening the way to a more comprehensive type structure. The second innovation that most clearly distinguishes C from its predecessors, is this fuller type structure and especially its expression in the syntax of declarations. NB offered the basic types i n t and char, together with arrays of them, and pointers to them, but no further ways of composition. Generalization was required: given an object of any type, it should be possible to describe a new object that gathers several into an array, yields it from a function, or is a pointer to it. For each object of such a composed type, there was already a way to mention the underlying object: index the array, call the function, use the indirection operator on the pointer. Analogical reasoning led to a declaration syntax for names mirroring that of the expression syntax in which the names typically appear. Thus, int i, *pi,
**ppi;
declare an integer, a pointer to an integer, a pointer to a pointer to an integer. The syntax of these declarations reflects the observation that i, *pi, and **ppi all yield an i n t type when used in an expression. Similarly, int 678
f(),
*f(),
(*f) (); CHAPTER XlV
PAPER: THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE
declare a function returning an integer, a function returning a pointer to an integer, a pointer to a function returning an integer; int
*api[lO],
( * p a i ) [i0] ;
declare an array of pointers to integers, and a pointer to an mTay of integers. In all these cases the declaration of a variable resembles its usage in an expression whose type is the one named at the head of the declaration. The scheme of type composition adopted by C owes considerable debt to ALGOL 68, although it did not, perhaps, emerge in a form of which ALGOUs adherents would approve. The central notion I captured from ALGOL was a type structure based on atomic types (including structures), composed into mTays, pointers (references), and functions (procedures). ALGOL 68's concept of unions and casts also had an influence that appeared later. After creating the type system, the associated syntax, and the compiler for the new language, I felt that it deserved a new name; NB seemed insufficiently distinctive. I decided to follow the single-letter style and called it C, leaving open the question whether the name represented a progression through the alphabet or through the letters in BCPL.
14.7 NEONATAL C Rapid changes continued after the language had been named, for example the introduction of the && and I I operators. In BCPL and B, the evaluation of expressions depends on context: within if and other conditional statements that compare an expression's value with zero, these languages place a special interpretation on the and (&) and o r ( I ) operators. In ordinary contexts, they operate bitwise, but in the B statement if
(el
&
e2)
...
the compiler must evaluate el and if it is nonzero, evaluate e2, and if it too is nonzero, elaborate the statement dependent on the i f. The requirement descends recursively on & and I operators within e l and e2. The short-circuit semantics of the Boolean operators in such "truth-value" context seemed desirable, but the overloading of the operators was difficult to explain and use. At the suggestion of Alan Snyder, I introduced the &&and I I operators to make the mechanism more explicit. Their tardy introduction explains an infelicity of C's precedence rules. In B one writes if
(a==b
&
c)
...
to check whether a equals b and c is nonzero; in such a conditional expression it is better that & have lower precedence than ==. In converting from B to C, one wants to replace &by &&in such a statement; to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and = =, and thereby simplify a common C idiom: to test a masked value against another value, one must write if
((a&mask)
==
b)
...
where the inner parentheses are required but easily forgotten. Many other changes occurred around 1972-1973, but the most important was the introduction of the preprocessor, partly at the urging of Alan Snyder [Snyder 1974], but also in recognition of the utility of the file-inclusion mechanisms available in BCPL and PL/I. Its original version was exceedingly simple, and provided only included files and simple string replacements: # i n c l u d e and
C SESSION
679
DENNIS M. RITCHIE
#de f i n e of parameterless macros. Soon thereafter, it was extended, mostly by Mike Lesk and then by John Reiser, to incorporate macros with arguments and conditional compilation. The preprocessor was originally considered an optional adjunct to the language itself. Indeed, for some years, it was not even invoked unless the source program contained a special signal at its beginning. This attitude persisted, and explains both the incomplete integration of the syntax of the preprocessor with the rest of the language and the imprecision of its description in early reference manuals.
14,8 PORTABILITY By early 1973, the essentials of modern C were complete. The language and compiler were strong enough to permit us to rewrite the Unix kernel for the PDP-11 in C during the summer of that year. (Thompson had made a brief attempt to produce a system coded in an early version of C--before structures--in 1972, but gave up the effort.) Also during this period, the compiler was retargeted to other nearby machines, particularly the Honeywell 635 and IBM 360/370; because the language could not live in isolation, the prototypes for the modern libraries were developed. In particular, Lesk wrote a "portable I/O package" [Lesk 1972] that was later reworked to become the C "standard I/O" routine. In 1978, Brian Kernighan and I published The C Programming Language [Kernighan 19 78]. Although it did not describe some additions that soon became common, this book served as the language reference until a formal standard was adopted more than ten years later. Although we worked closely together on this book, there was a clear division of labor: Kernighan wrote almost all the expository material, while I was responsible for the appendix containing the reference manual and the chapter on interfacing with the Unix system. During 1973-1980, the language grew a bit: the type structure gained unsigned, long, union, and enumeration types, and structures became nearly first-class objects (lacking only a notation for literals). Equally important developments appeared in its environment and the accompanying technology. Writing the Unix kernel in C had given us enough confidence in the language's usefulness and efficiency that we began to recode the system's utilities and tools as well, and then to move the most interesting among them to the other platforms. As described in Portability of C Programs ond the UNIX System [Johnson 1978a], we discovered that the hardest problems in propagating Unix tools lay not in the interaction of the C language with new hardware, but in adapting to the existing software of other operating systems. Thus, Steve Johnson began to work on pcc, a C compiler intended to be easy to retarget to new machines [Johnson 1978b], while he, Thompson, and I began to move the Unix system itself to the Interdata 8/32 computer. The language changes during this period, especially around 1977, were largely focused on considerations of portability and type safety, in an effort to cope with the problems we foresaw and observed in moving a considerable body of code to the new Interdata platform. C, at that time, still manifested strong signs of its typeless origins. Pointers, for example, were barely distinguished from integral memory indices in early language manuals or extant code; the similarity of the arithmetic properties of character pointers and unsigned integers made it hard to resist the temptation to identify them. The u n s i g n e d types were added to make unsigned arithmetic available without confusing it with pointer manipulation. Similarly, the early language condoned assignments between integers and pointers, but this practice began to be discouraged; a notation for type conversions (called "casts" from the example of ALGOL 68) was invented to specify type conversions more explicitly. Beguiled by the example of PL/I, early C did not tie structure pointers firmly to the structures they pointed to, and permitted programmers to write p o i n t e r - > m e m b e r almost without regard to the type of p o i n t e r ; such an expression was taken uncritically as a reference to a region of memory designated by the pointer, whereas the member name specified only an offset and a type. 680
CHAPTER XlV
PAPER: THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE
Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 1979b], which scanned a set of files and remarked on dubious constructions.
14.9 GROWTH IN USAGE The success of our portability experiment on the Interdata 8/32 soon led tO another by Tom London and John Reiser on the DEC VAX 11/780. This machine became much more popular than the Interdata, and Unix and the C language began to spread rapidly, both within AT&T and outside. Although by the middle 1970s Unix was in use by a variety of projects within the Bell System, as well as a small group of research-oriented industrial, academic, and government organizations outside our company, its real growth began only after portability had been achieved. Of particular note were the System III and System V versions of the system from the emerging Computer Systems division of AT&T, based on work by the company's development and research groups, and the BSD series of releases by the University of California at Berkeley that derived from research organizations in Bell Laboratories. During the 1980s the use of the C language spread widely, and compilers became available on nearly every machine architecture and operating system; in particular it became popular as a programming tool for personal computers, both for manufacturers of commercial software for these machines, and for end-users interested in programming. At the start of the decade, nearly every compiler was based on Johnson's pcc; by 1985 there were many independently produced compiler products.
14.10 STANDARDIZATION By 1982 it was clear that C needed formal standardization. The best approximation to a standard, the first edition of K&R, no longer described the language in actual use; in particular, it mentioned neither the v o i d or churn types. It foreshadowed the newer approach to structures, but only after it was published did the language support assigning them, passing them to and from functions, and associating the names of members firmly with the structure or union containing them. Although compilers distributed by AT&T incorporated these changes, and most of the purveyors of compilers not based on pcc quickly picked them up, there remained no complete, authoritative description of the language. The first edition of K&R was also insufficiently precise on many details of the language, and it became increasingly impractical to regard pcc as a "reference compiler"; it did not perfectly embody even the language described by K&R, let alone subsequent extensions. Finally, the incipient use of C in projects subject to commercial and government contract meant that the imprimatur of an official standard was important. Thus (at the urging ofM. D. MclIroy), ANSI established the X3J11 committee under the direction of CBEMA in the summer of 1983, with the goal of producing a C standard. X3J11 produced its report [ANSI 1989] at the end of 1989, and subsequently this standard was accepted by ISO as ISO/IEC 9899-1990. From the beginning, the X3Jil committee took a cautious, conservative view of language extensions. Much to my satisfaction, they took seriously their goal: "to develop a clear, consistent, and unambiguous Standard for the C programming language which codifies the common, existing definition of C and which promotes the portability of user programs across C language environments," C SESSION
681
DENNIS M. RITCHIE
[ANSI 1989]. The committee realized that mere promulgation of a standard does not make the world change. X3J11 introduced only one genuinely important change to the language itself: it incorporated the types of formal arguments in the type signature of a function, using syntax borrowed from C++ [Stroustrup 1986]. In the old style, external functions were declared in this way: double
sin() ;
which says only that sin is a function returning a double (that is, double-precision floating-point) value. In the new style, this is better rendered double
sin(double)
;
to make the argument type explicit and thus encourage better type checking and appropriate conversion. Even this addition, though it produced a noticeably better language, caused difficulties. The committee justifiably felt that simply outlawing "old-style" function definitions and declarations was not feasible, yet also agreed that the new forms were better. The inevitable compromise was as good as it could have been, though the language definition is complicated by permitting both forms, and writers of portable software must contend with compilers not yet brought up to standard. X3J11 also introduced a host of smaller additions and adjustments, for example, the type qualifiers cons t and vo 1 a t i 1 e, and slightly different type promotion rules. Nevertheless, the standardization process did not change the character of the language. In particular, the C standard did not attempt to specify formally the language semantics, and so there can be dispute over fine points; nevertheless, it successfully accounted for changes in usage since the original description, and is sufficiently precise as a base for implementations. Thus, the core C language escaped nearly unscathed from the standardization process, and the Standard emerged more as a better, careful codification than a new invention. More important changes took place in the language's surroundings: the preprocessor and the library. The preprocessor performs macro substitution, using conventions distinct from the rest of the language. Its interaction with the compiler had never been well-described, and X3J11 attempted to remedy the situation. The result is noticeably better than the explanation in the first edition of K&R; besides being more comprehensive, it provides operations, like token concatenation, previously available only by accidents of implementation. X3J 11 correctly believed that a full and careful description of a standard C library was as important as its work on the language itself. The C language itself does not provide for input/output or any other interaction with the outside world, and thus depends on a set of standard procedures. At the time of publication of K&R, C was thought of mainly as the system programming language of Unix; although we provided examples of library routines intended to be readily transportable to other operating systems, underlying support from Unix was implicitly understood. Thus the X3J11 committee spent much of its time designing and documenting a set of library routines required to be available in all conforming implementations. By the rules of the standards process, the current activity of the X3J11 committee is confined to issuing interpretations on the existing standard. However, an informal group originally convened by Rex Jaeschke as NCEG (Numerical C Extensions Group) has been officially accepted as subgroup X3J 11.1, and they continue to consider extensions to C, As the name implies, many of these possible extensions are intended to make the language more suitable for numerical use: for example, multidimensional arrays whose bounds are dynamically determined, incorporation of facilities for dealing with IEEE arithmetic, and making the language more effective on machines with vector or
682
CHAPTER XIV
PAPER: THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE
other advanced architectural features. Not all the possible extensions are specifically numerical; they include a notation for structure literals. 14.11
SUCCESSORS
C and even B have several direct descendants, though they do not rival Pascal in generating progeny. One side branch developed early. When Steve Johnson visited the University of Waterloo on sabbatical in 1972, he brought B with him. It became popular on the Honeywell machines there, and later spawned Eh and 7Zed (the Canadian answers to "what follows B?"). When Johnson returned to Bell Labs in 1973, he was disconcerted to find that the language whose seeds he had brought to Canada had evolved back home; even his own yacc program had been rewritten in C, by Alan Snyder. More recent descendants of C proper include Concurrent C [Gehani 1989], Objective C [Cox 1986], C* [Thinking 1990], and especially C++ [Stroustrup 1986]. The language is also widely used as an intermediate representation (essentially, as a portable assembly language) for a wide variety of compilers, both for direct descendents such as C++, and independent languages such as Modula 3 [Nelson 1991 ] and Eiffel [Meyer 1988]. 14.12
CRITIQUE
Two ideas are most characteristic of C among languages of its class: the relationship between arrays and pointers, and the way in which declaration syntax mimics expression syntax. They are also among its most frequently criticized features, and often serve as stumbling blocks to the beginner. In both cases, historical accidents or mistakes have exacerbated their difficulty. The most important of these has been the tolerance of C compilers to errors in type. As should be clear from the preceding history, C evolved from typeless languages. It did not suddenly appear to its earliest users and developers as an entirely new language with its own rules; instead we continually had to adapt existing programs as the language developed, and make allowance for an existing body of code. (Later, the ANSI X3J11 committee standardizing C would face the same problem.) Compilers in 1977, and even well after, did not complain about usages such as assigning between integers and pointers, or using objects of the wrong type to refer to structure members. Although the language definition presented in the first edition of K&R was reasonably (though not completely) coherent in its treatment of type rules, that book admitted that existing compilers didn't enforce them. Moreover, some rules designed to ease early transitions contributed to later confusion. For example, the empty square brackets in the function declaration int
f(a)
int
a[];
( ...
}
are a living fossil, a remnant of NB's way of declaring a pointer: a is, in this special case only, interpreted in C as a pointer. The notation survived in part for the sake of compatibility, in part under the rationalization that it would allow programmers to communicate to their readers an intent to pass f a pointer generated from an array, rather than a reference to a single integer. Unfortunately, it serves as much to confuse the learner as to alert the reader. In K&R, C, supplying arguments of the proper type to a function call, was the responsibility of the programmer, and the extant compilers did not check for type agreement. The failure of the original language to include argument types in the type signature of a function was a significant weakness, indeed the one that required the X3J11 committee's boldest and most painful innovation to repair. The early design is explained (if not justified) by my avoidance of technological problems, especially
C SESSION
683
DENNIS M. RITCHIE
cross-checking between separately compiled source files, and my incomplete assimilation of the implications of moving between an untyped and a typed language. The lint program, mentioned previously, tried to alleviate the problem: among its other functions, lint checks the consistency and coherency of a whole program by scanning a set of source files, comparing the types of function arguments used in calls with those in their definitions. An accident of syntax contributed to the perceived complexity of the language. The indirection operator, spelled * in C, is syntactically a unary prefix operator, just as in BCPL and B. This works well in simple expressions, but in more complex cases, parentheses are required to direct the parsing. For example, to distinguish indirection through the value returned by a function from calling a function designated by a pointer, one writes * fp ( ) and ( *pf ) (), respectively. The style used in expressions carries through to declarations, so the names might be declared int *fp() ; int (*pf) () ;
In more ornate but still realistic cases, things become worse: int *(*pfp) ();
is a pointer to a function returning a pointer to an integer. There are two effects occurring. Most important, C has a relatively rich set of ways of describing types (compared, say, with Pascal). Declarations in languages as expressive as C--ALGOL 68, for example---describe objects equally hard to understand, simply because the objects themselves are complex. A second effect owes to details of the syntax. Declarations in C must be read in an "inside-out" style that many find difficult to grasp [Anderson 1980]. Sethi [Sethi 1981] observed that many of the nested declarations and expressions would become simpler if the indirection operator had been taken as a postfix operator instead of prefix, but by then it was too late to change. In spite of its difficulties, I believe that C's approach to declarations remains plausible, and am comfortable with it; it is a useful unifying principle. The other characteristic feature of C, its treatment of arrays, is more suspect on practical grounds, though it also has real virtues. Although the relationship between pointers and arrays is unusual, it can be learned. Moreover, the language shows considerable power to describe important concepts, for example, vectors whose length varies at run-time, with only a few basic rules and conventions. In particular, character strings are handled by the same mechanisms as any other array, plus the convention that a null character terminates a string. It is interesting to compare C's approach with that of two nearly contemporaneous languages, ALGOL 68 and Pascal [Jensen 1974]. Arrays in ALGOL 68 either have fixed bounds, or are "flexible": considerable mechanism is required both in the language definition, and in compilers, to accommodate flexible arrays (and not all compilers fully implement them). Original Pascal had only fixed-sized arrays and strings, and this proved confining [Kernighan 1981 ]. Later, this was partially fixed, though the resulting language is not yet universally available. C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type. Some costs accrue from its approach: certain string operations are more expensive than in other designs, because application code or a library routine must occasionally search for the end of a string, because few built-in operations are available, and because the burden of storage management for strings falls more heavily on the user. Nevertheless, C's approach to strings works well. 684
CHAPTER XlV
PAPER: THE DEVELOPMENT OF THE C PROGRAMMING LANGUAGE
On the other hand, C's treatment of arrays in general (not just strings) has unfortunate implications both for optimization and for future extensions. The prevalence of pointers in C programs, whether those declared explicitly or arising from arrays, means that optimizers must be cautious, and must use careful dataflow techniques to achieve good results. Sophisticated compilers can understand what most pointers can possibly change, but some important usages remain difficult to analyze. For example, functions with pointer arguments derived from arrays are hard to compile into efficient code on vector machines, because it is seldom possible to determine that one argument pointer does not overlap data also referred to by another argument, or accessible externally. More fundamentally, the definition of C so specifically describes the semantics of arrays that changes or extensions treating arrays as more primitive objects, and permitting operations on them as wholes, become hard to fit into the existing language. Even extensions to permit the declaration and use of multidimensional arrays whose size is determined dynamically are not entirely straightforward [MacDonald 1989; Ritchie 1990], although they would make it much easier to write numerical libraries in C. Thus C covers the most important uses of strings and arrays arising in practice by a uniform and simple mechanism, but leaves problems for highly efficient implementations and for extensions. Many smaller infelicities exist in the language and its description besides those discussed, of course. There are also general criticisms to be lodged that transcend detailed points. Chief among these is that the language and its generally expected environment provide little help for writing very large systems. The naming structure provides only two main levels, "external" (visible everywhere) and "internal" (within a single procedure). An intermediate level of visibility (within a single file of data and procedures) is weakly tied to the language definition. Thus there is little direct support for modularization, and project designers are forced to create their own conventions. Similarly, C itself provides two durations of storage: "automatic" objects that exist while control resides in, or below, a procedure, and "static," existing throughout execution of a program. Off-stack, dynamically allocated storage is provided only by a library routine and the burden of managing it is placed on the programmer: C is hostile to automatic garbage collection. 14.13
WHENCE SUCCESS?
C has become successful to an extent far surpassing any early expectations. What qualities contributed to its widespread use? Doubtless the success of Unix itself was the most important factor; it made the language available to hundreds of thousands of people. Conversely, of course, Unix's use of C and its consequent portability to a wide variety of machines was important in the system's success. But the language's invasion of other environments suggests more fundamental merits. Despite some aspects mysterious to the beginner and occasionally even to the adept, C remains a simple and small language, translatable with simple and small compilers. Its types and operations are well-grounded in those provided by real machines, and for people used to computers and how they work, learning the idioms for generating time- and space-efficient programs is not difficult. At the same time the language is sufficiently abstracted from machine details that program portability can be achieved. Equally important, C and its central library support always remained in touch with a real environment. It was not designed in isolation to prove a point, or to serve as an example, but as a tool to write programs that did useful things; it was always meant to interact with a larger operating system, and was regarded as a tool to build larger tools. A parsimonious, pragmatic approach influenced the things that went into C: it covers the essential needs of many programmers, but does not try to supply too much. C SESSION
685
DENNIS M. RITCHIE
Finally, despite the changes that it has undergone since its first published description, which was admittedly informal and incomplete, the actual C language as seen by millions of users using many different compilers has remained remarkably stable and unified compared to those of similarly widespread currency, for example, Pascal and FORTRAN. There are differing dialects of C - - m o s t noticeably, those described by the older K & R and the newer Standard C - - b u t on the whole, C has remained freer of proprietary extensions than other languages. Perhaps the most significant extensions are the "far" and "near" pointer qualifications intended to deal with peculiarities of some Intel processors. Although C was not originally designed with portability as a prime goal, it succeeded in expressing programs, even including operating systems, on machines ranging from the smallest personal computers through the mightiest supercomputers. C is quirky, flawed, and an enormous success. Although accidents o f history surely helped, it evidently satisfied a need for a system implementation language efficient enough to displace assembly language, yet sufficiently abstract and fluent to describe algorithms and interactions in a wide variety o f environments.
ACKNOWLEDGMENTS It is worth summarizing compactly the roles of the direct contributors to today's C language. Ken Thompson created the B language in 1969-1970; it was derived directly from Martin Richards's BCPL. Dennis Ritchie turned B into C during 1971-1973, keeping most of B's syntax, while adding types and many other changes, and writing the first compiler. Ritchie, Alan Snyder, Steven C. Johnson, Michael Lesk, and Thompson contributed language ideas during 1972-1977, and Johnson's portable compiler remains widely used. During this period, the collection of library routines grew considerably, thanks to these people and many others at Bell Laboratories. In 1978, Bran Kernighan and Ritchie wrote the book that became the language definition for several years. Beginning in 1983, the ANSI X3JI 1 committee standardized the language. Especially notable in keeping its efforts on track were its officers Jim Brodie, Tom Plum, and P. J. Plauger, and the successive draft redactors, Larry Rosier and Dave Prosser. I thank Brian Kernighan, Doug Mcllroy, Dave Prosser, Peter Nelson, Rob Pike, Ken Thompson, and HOPL's referees for advice in the preparation of this paper.
REFERENCES [ANSI, 1989] American National Standards Institute, American National StandardJbr lnt~Jrmation Systems-Programming Language C, X3.159-1989. [Anderson, 1980] B. Anderson, Type syntax in the language C: an object lesson in syntactic innovation, SIGPLAN Notices, Vol. 15, No. 3, Mar. 1980, pp. 21-27. [Bell, 1972] J. R. Bell, Threaded Code, C. ACM, Vol. 16, No. 6, pp. 370--372. [Canaday, 19 69] R. H. Canaday and D. M. Ritchie, Bell LaboratoriesBCPL, AT&TBell Laboratories internal memorandum, May 1969. [Corbato, 1962] E J. Corbato, M. Merwin-Dagget,and R. C. Daley,An ExperimentalTime-sharingSystem,AFIPS Conference Proceedings SJCC, 1962, pp. 335-344. [Cox, 1986] B. J. Cox and A. J. Novobilski, Object-Oriented Programming: An Evolutionary Approach, Addison-Wesley: Reading, MA, 1986, Second edition, 1991. [Gehani, 1989] N. H. Gehani and W. D. Roome, Concurrent C, Silicon Press: Summit, NJ, 1989. [Jensen, 1974] K. Jensen and N. Wirth,Pascal User Manual and Report,Spfinger-Verlag:New York,Heidelberg,Berlin. Second Edition, 1974. [Johnson, 1973] S. C. Johnson and B. W. Kernighan,The programminglanguage B, Computer Science Technical Report No. 8, AT&T Bell Laboratories,Jan. 1973. [Johnson, 1978a] S. C. Johnson and D. M. Ritchie, Portabilityof C programs and the UNIX system, Bell Systems Technical J. 57, Vol. 6, (part 2), July-Aug. 1978.
686
CHAPTER XIV
TRANSCRIPT OF C PRESENTATION [Johnson, 1978b] S. C. Johnson, A portable compiler: Theory and practice, Proceedings ¢9rthe 5th ACM POPL Symposium, Jan. 1978. [Johnson, 1979a] S. C, Johnson, Yet another compiler-compiler, Unix Programmer's Manual, Seventh Edition, Vol. 2A, M. D. Mcllroy and B. W. Kemighan, Eds. AT&T Bell Laboratories: Murray Hill, N J, 1979. [Johnson, 1979b] S. C. Johnson, Lint, a program checker, Unix Programmer's Manual, Seventh Edition, Vol. 2B, M. D. Mcllroy and B. W. Kernighan, Eds. AT&T Bell Laboratories: Murray Hill, NJ, 1979. [Kernighnn, 1978] B. W. Kernighan and D. M. Ritchie, The C Programming Language, Prentice-Hall: Englewood Cliffs, NJ, 1978. Second edition, 1988. [Kernighan, 1981lB. W. Keroighan, Why Pascal is not my favorite programming language, Computer Science Technical Report No. 100, AT&T Bell Laboratories, 1981. [Lesk, 1973] M. E. Lesk, A portable I/O package, AT&T Bell Laboratories internal memorandum c. 1973. [MacDonald, 1989]T. MacDonald, Arrays of variable length, Journal :~fC Language Translation, Vol. 1, No. 3, Dec. 1989, pp. 215-233. [McClure, 1965] R. M. McClure, TMG--A syntax directed compiler, Proceedings of the 20th ACM National Conference, 1965, pp. 262-274. [Mcllroy, 1960] M. D. Mcllroy, Macro instruction extensions of compiler languages, C. ACM, Vol. 3, No. 4, pp. 214-220. [Mcllroy, 1979] M. D. Mcllroy and B. W. Kernighan, Eds., Unix Programmer's Manual, Seventh Edition, Vol. I, AT&T Bell Laboratories: Murray Hill, NJ, 1979. [Meyer, 1988] B. Meyer, Object-Oriented Software Construction, Prentice-Hall: Englewood Cliffs, N J, 1988. [Nelson, 1991] G. Nelson, Systems Programming with Modula-3, Prentice-Hall: Englewood Cliffs, NJ, 1991. [Organick, 1975] E. 1. Organick, The Multics System: An Examination :~fits Structure, MIT Press: Cambridge, Mass., 1975. [Richards, 1967] M. Richards, The BCPL Reference manual, MIT Project MAC Memorandum M-352, July 1967. [Richards, 1979] M. Riehards and C. Whitbey-Strevens, BCPL: The Language and its Compiler, Cambridge Univ. Press: Cambridge, 1979. [Ritchie, 1978] D. M. Ritchie, UNIX: A retrospective, Bell Systems TechnicalJournal, Vol. 57, No. 6, (part 2), July-Aug. 1978. [Ritchie, 1984]D. M. Ritchie, The evolution of the UNIX time- sharing system, AT& T Bell Labs. Technh:al Journal, Vol. 63, No. 8, (part 2), Oct. 1984. [Ritchie, 1990] D. M. Ritchie, Variable-size arrays in C, Journal (~fC Language Translation 2, No. 2, Sept. 1990, pp. 81-86. [Sethi, 1981] R. Sethi, Uniform syntax for type expressions and declarators, Software Practice and Experience, Vol. 11, No. 6, June 1981, pp. 623--628. [Snyder, 1974] A. Snyder, A Portable Compiler for the Language C, MIT: Cambridge, Mass., i 974. [Stoy, 1972] J. E. Stoy and C. Strachey, OS6-An experimental operating system for a small computer, Part I: General principles and structure, Computer Journal, Vol. 15, Aug. 1972, pp. 117-124. [Stroustrup 86] B. Stroustrup, The C++ Programming Language, Addison-Wesley: Reading, Mass., 1986. Second edition, 1991. [Thacker 79] C. P. Thacker, E. M. McCreight, B. W. Lampson, R. E Sproull, D. R. Boggs, Alto: A Personal Computer, Computer Structures: Principles and Examples, D. Sieworek, C. G. Bell, A. Newell, McGraw-Hill: New York, 1982. [Thinking 90] C* Programming Guide, Thinking Machines Corp.: Cambridge Mass., 1990. [Thompson 69] K. Thompson, Bon-an interactive language, undated AT&T Bell Laboratories internal memorandum (c. 1969). [Wijngaarden 75] A. van Wijngaarden, B. J. Mailloux, J. E. Peck, C. H. Koster, M. Sintzoff, C. Lindsey, L. G. Meertens, and R. G. Fisker, Revised report on the algorithmic language ALGOL 68, Acta Informatica 5, pp. 1-236.
TRANSCRIPT OF PRESENTATION DENNIS RITCHIE: Thank you. Before I begin the talk, I will put forth a little idea I thought of in the last day or so. It's a programming problem having to do with graph theory: you have a graph. The nodes contain a record with a language and a person, and, just to make the example concrete: the nodes might be (C, Ritchie), (Ada, Ichbiah), (Pascal, Wirth), or (Concurrent Pascal, Brinch Hansen) perhaps. (Lisp, Steele), (C++, Stroustrup) might also be part of the population. There is an edge from X to Y, whenever X.Person will throw a barb in public at Y.Language. And the questions are: is this a complete graph? Does it have self-edges? If it's not complete, what cliques exist? There are all sorts of questions you can ask. I guess if it were a finite state machine, you could ask about diagnosability, too. Can you push at the people and get them to throw these barbs?
C SESSION
687
DENNIS M. RITCHIE
Five Little Languages Bliss
The Development of the C Language or
Pascal
Five Little Languages and How They Grew
Algol 68 BCPL
Dennis M. Ritchie AT&T Bell Laboratories
C
[email protected] Ritchie
HOPL-II
I
Ritchie
SLIDE 1
HOPL -II
2
SLIDE 2
(SLIDE 1) The paper itself tells the history of C, so I don't want to do it again. Instead, I want to do a small comparative language study, although it's not really that either. I'm going to talk about a bunch of 20-year old languages. Other people can discuss what the languages contain. These were things that were around at the time, and I'm going to draw some comparisons between them just to show the way we were thinking and perhaps explain some things about C. Indirectly, I want to explain why C is as it is. So the actual title of the talk, as opposed to the paper, is "Five Little Languages and How They Grew." (SLIDE 2) Here are the five languages: Bliss, Pascal, ALGOL 68, BCPL, C. All these were developed in more or less the same period. I'm going to argue that they're very much similar in a lot of ways. And each succeeded in various ways, either by use or by influence. C succeeded really without politics in a sense that we didn't do any marketing, so there must have been a need for it. What about the rest of these? Why are these languages the same? (SLIDE 3) In the first place, the things that they're manipulating, their atomic types, their ground-level objects, are essentially identical. They are simply machine words interpreted in various ways. The operations that they allow on these are actually very similar. This is in contrast to SNOBOL, for example, which has strings, or Lisp, which has lists. The languages I'm talking about are just cleverly designed ways of shuffling bits around; everybody knows about the operations once they've learned a bit about machine architecture. That's what I mean by concretely grounded. They're
Similadties
Bliss
Atomic types similar
by Wulf et al. at CMU
Concretely grounded
PDP-10 and PDP-11 system language
Procedural
Picked up by DEC
Based on tradition of Algol 60 and Fortran
Word oriented: operator used to access bytes < start, let! >
System programming
Macros used for arrays and structures
Ritchle
HOPL-II
SLIDE
688
3
3
Ritchie
HOPL-II
4
SLIDE 4 CHAPTER XlV
TRANSCRIPT OF C PRESENTATION
procedural, which is, to say, imperative. They don't have very fancy control structures, and they perform assignments; they're based on this old, old model of machines that pick up things, do operations, and put them someplace else. They are very much influenced by ALGOL 60 and FORTRAN and the other languages which were discussed in the first HOPL conference. Mostly they were designed (speaking broadly) for "systems programming." Certainly some of them, like BCPL and C and Bliss, are explicitly system programming languages, and Pascal has been used for that. ALGOL 68 didn't really have that in mind, but it really can be used for the purpose; when Steve Bourne came to Bell Labs with the ALGOL 68C compiler, he made it do the same things that C could do; it had Unix system call interfaces and so forth. The point is, that "system" can be understood in a fairly broad sense, not just operating systems. Let me very briefly characterize each language. (SLIDE 4) Bliss is the one that hasn't been mentioned before at this conference. It was done by Bill Wulf and his students at Carnegie-Mellon. I believe it started as a PDP-10 system programming language, and it was then later used to do system programming on the PDP- 11 for a variety of projects. It went somewhat beyond that--it was picked up in particular by Digital Equipment Corp., I suppose partly through the close connections between DEC and CMU at that time. And in fact it's been used, maybe still is used, for parts of VMS. Bliss is word oriented, by which I mean, there is only one data type, which is the machine word. So that's 36 bits in the case of the PDP-10 version; 16 bits in the case of the ' 11. You accessed individual bytes, or characters, by having a special operator notation where you mentioned the start bit and the length. So it is a special case that accessed characters of a slightly more general case, that accessed individual rows of bits. Bliss was innovative in a variety of ways. It was goto-less; it was an expression language. A lot of things that are built into other languages were not built into Bliss; instead there were syntax macros used for giving meaning to arrays, particularly multidimensional arrays, and structures. An array or structure was represented by the programmer as a sort of in-line function to access the members, instead of being built in as a data type. (SLIDE 5) But the thing that people really remember about Bliss is all those dots. Bliss is unusual in that the value of a name appearing in an expression is the address at which the associated value is stored. And to retrieve the value itself, you put a dot operator in front of the name. For example, in an ordinary assignment of a sum will be written as "C gets .A+.B." Here you're taking the value stored in A and the value stored in B, and adding them. (If you left off the dots, you would be adding the addresses.) On the other hand, the assignment operator wants an address on the left and a value on the right; that's why there's no dot in front of the C.
All t h o s e dots! The value of a name is the address in which the associated value is stored; to retneve the associated value, use the dot operator: c
Ritchie
i n i t (2) ;
X));
and in which version are you most likely to make a mistake? The arguments against it, which were voiced quite a lot at the time, were "but we don't really need it," and "but someone will have used new as an identifier." Both observations are correct, of course. Introducing "operator new" thus made the use of free store more convenient and less error prone. This increased its use even further so that the C free store allocation routine m a l l o c ( ) used to implement new became the most common performance bottleneck in real systems. This was no real surprise either; the only problem was what to do about it. Having real programs spend 50 percent or more of their time in m a l l o c ( ) wasn't acceptable. I found per-class allocators and deallocators very effective. The fundamental idea is that free store memory usage is dominated by the allocation and deallocation of lots of small objects from very few classes. Take over the allocation of those objects in a separate allocator and you can save both time and space for those objects and also reduce the amount of fragmentation of the general free store. The mechanism provided for 1.0, "assignment to t h i s , " was too low level and error prone and was replaced by a cleaner solution in 2.0 (Section 15.4.1). Note that static and automatic (stack allocated) objects were always possible and that the most effective memory management techniques relied heavily on such objects. The string class was a typical example; here s t r i n g objects are typically on the stack so that they require no explicit memory management, and the free store they rely on is managed exclusively and invisibly to the user by the S t r i n g member functions.
TypeChecking
15.3.3.7
The C++ type checking rules were the result of experiments with the C with Classes. All function calls are checked at compile time. The checking of trailing arguments can be suppressed by explicit specification in a function declaration. This is essential to allow C's p r i n t f ( ) : int p r i n t f ( c o n s t
//
°.
char*
. ..) ; // a c c e p t any a r g u m e n t a f t e r // the i n i t i a l c h a r a c t e r s t r i n g
•
printf("date:
%s %d 1 9 % d \ n " , m o n t h , d a y , y e a r ) ;
//
maybe
right
Several mechanisms were provided to alleviate the withdrawal symptoms that many C programmers feel when they first experience strict checking. Overriding type checking using the ellipsis was the most drastic and least recommended of those. Function name overloading (Section 15.3.3.3) and default arguments [Stroustrup 1986b] made it possible to give the appearance of a single function taking a variety of argument lists without compromising type safety. The stream I/O system demonstrates that the weak checking wasn't necessary even for I/O (see Section 15.5.3.1).
15.3.4 Relationship to Classic C With the introduction of a separate name, C++, and the writing ofa C++ reference manual [Stroustrup 1984a], compatibility with C became an issue of major importance and a point of controversy. Also, in late 1983 the branch of Bell Labs that developed and supported UNIX, and produced AT&T's 3B series of computers, became interested in C++ to the point where they were willing to
7'26
CHAPTER XV
PAPER: A HISTORY OF C++: 1979-1991
put resources into the development of C++ tools. Such development was necessary for the evolution of C++ from a one-man show to a language that a corporation could base critical projects on. Unfortunately, it also implied that development management needed to consider C++. The first demand to emerge from development management was for 100 percent compatibility with C. The ideal of C compatibility is quite obvious and reasonable, but the reality of programming isn't that simple. For starters, with which C should C++ be compatible? C dialects abounded, and though ANSI C was emerging, it was still years away from having a stable definition, and its definition allowed many dialects. Naturally, the average user who wanted C compatibility insisted that C++ should be compatible with the local C dialect. This was an important practical problem and a great concern to me and my friends. It seemed far less of a concern to business-oriented managers and salesmen who either didn't quite understand the technical details or would like to use C++ to tie users into their software and/or hardware. Another side of the compatibility issue was more critical: "In which ways must C++ differ from C to meet its fundamental goals?" and also "In which ways must C++ be compatible with C to meet its fundamental goals?" Both sides of the issue are important, and revisions were made in both directions during the transition from C with Classes to C++, shipped as release 1.0. Slowly and painfully an agreement emerged that there would be no gratuitous incompatibilities between C++ and ANSI C (when it became a standard) [Stroustrup 1986b], but that there was such a thing as an incompatibility that was not gratuitous. Naturally, the concept of "gratuitous incompatibilities" was a topic of much debate and took up a disproportional part of my time and effort. This principle has lately been known as "C++: As close to C as possible but no closer," after the title of a paper by Andrew Koenig and me [Koenig 1989]. Some conclusions about modularity and how a program is composed out of separately compiled parts were explicitly reflected in the original C++ reference manual [Stroustrup 1984a]: a. b. c. d.
Names are private unless they are explicitly declared public. Names are local to their file unless explicitly exported from it. Static type is checked unless explicitly suppressed. A class is a scope (implying that classes nest properly).
Point [a] doesn't affect C compatibility but [b], [c], [d] imply incompatibilities: 1. The name of a non-local C function or object is by default accessible from other compilation units, 2. C functions need not be declared before use and calls are by default not type checked, and 3. C structure names don't nest (even when they are lexically nested). In addition, 4. C++ has a single name space whereas C had a separate name space for "structure tags" (Section 15.2.4.5). The "compatibility wars" now seem petty and boring, but some of the underlying issues are still unresolved and we are still struggling with them in the ANSI/ISO committee. I strongly suspect that the reason the compatibility wars were drawn out and curiously inconclusive was that we never quite faced the deeper issues related to the differing goals of C and C++, and saw compatibility as a set of separate issues to be resolved individually. Typically, the least fundamental issue, [4], "name spaces," took up the most effort, but was eventually resolved [Ellis 1990].
C++ SESSION
727
BJARNE STROUSTRUP
I had to compromise the notion of a class as a scope, [3], and accept the C "solution" before I was allowed to ship release 1.0. One practical problem was that I had never realized that a C struct didn't constitute a scope, so that examples like this: struct outer { struct inner int i ;
{
}; int
j;
}; struct
inner
a =
{ 1 };
are legal C. When the issue came up towards the end of the compatibility wars I didn't have time to fathom the implications of the C "solution" and it was much easier to agree than to fight the issue. Later, after many technical problems and much discontent from users, nested class scopes were reintroduced into C++ in 1989 [Ellis 1990]. After much hassle, C++'s stronger type checking of function calls was accepted (unmodified). An implicit violation of the static type system is the original example of a C/C++ incompatibility that is not gratuitous. As it happens, the ANSI C committee adopted a slightly weaker version of C++'s rules and notation on this point and declared uses that don't conform to the C++ rules obsolete. On issue [1], I had to accept the C rule that global names are by default accessible from other compilation units. There simply wasn't any support for the more restrictive C++ rule. This meant that C++, like C, lacks an effective mechanism for expressing modularity above the level of the class and the file. This has led to a series of complaints and the ANSI/ISO committee is now looking into several proposals for mechanisms to avoid name space pollution. 3 However, people like Doug MclIroy, who argued that C programmers would not accept a language where every object and function meant to be accessible from another compilation unit had to be explicitly declared as such, were probably right at the time, and saved me from making a serious mistake. I am now convinced that the original C++ solution wasn't elegant enough anyway.
15.3.5 Tools for Language Design 'Theory and tools more advanced than a blackboard have not been given much space in the description of the history of C++. ! tried to use YACC (an LALR(1 ) parser generator) for the grammar work, and was defeated by C's syntax (Section 15.2.4.5). I looked at denotational semantics, but was again defeated by quirks in C. Ravi Sethi had looked into that problem and found that he couldn't express the C semantics that way [Sethi 1980]. The main problem was the irregularity of C and the number of implementation-dependent and undefined aspects ofa C implementation. Much later, theANSI/ISO C++ committee had a stream of formal definition experts explain their techniques and tools, and give their opinion of the extent to which a genuine formal approach to the definition of C++ would help us in the standards effort. My conclusion is that with the current state of the art, and certainly with the state of the art in the early 1980s, a formal definition of a language that is not designed together with a formal definition method is beyond the ability of all but a handful of experts in formal definition. This confirms my conclusion at the time. However, that left us at the mercy of imprecise and insufficient terminology. Given that, what could I do to compensate? I tried to reason about new features, both on my own and with others, to check my logic. However, I soon developed a healthy 3
In 1994, the C++ standard committee accepted a proposal for a namespace mechanism; see [Stroustrup 1994].
728
CHAPTER XV
PAPER:A HISTORYOF C++: 1979-1991 disrespect for arguments (definitely including my own) because I found that it is possible to construct a plausible logical argument for just about any feature. On the other hand, you simply don't get a useful language by accepting every feature that makes life better for someone. There are far too many reasonable features and no language could provide them all and stay coherent. Consequently, wherever possible, I tried to experiment. My impression was, and is, that many programming languages and tools represent solutions looking for problems, and I was determined that my work should not fall into that category. Thus, I follow the literature on programming language and the debates about programming languages primarily to look for ideas for solutions to problems my colleagues and I have encountered in real applications. Other programming languages constitute a mountain of ideas and inspiration but it has to be mined carefully to avoid featurism and inconsistencies. The main sources for ideas for C++ were Simula, ALGOL 68, and later Ciu, Ada, and ML. The key to good design is insight into problems, not the provision of the most advanced features.
15.3.6 The C++ Programming Language (1st edition) In the fall of 1983 my next door neighbor at work, AI Abo, suggested that I write a book on C++, structured along the lines of Brian Kernighan and Dennis Ritchie's The C Programming Language and based on my published papers, internal memoranda, and the C++ reference manual. Completing the book took nine months. The preface mentions the people who had by then contributed most to C++: Tom Cargill, Jim Coplien, Stu Feldman, Sandy Fraser, Steve Johnson, Brian Kernighan, Bart Locanthi, Doug Mcllroy, Dennis Ritchie, Larry Rosier, Jerry Schwarz, and Jon Shopiro. My criteria for adding a person to that list was being able to identify a specific C++ feature that the person had added. The book's opening line, "C++ is a general purpose programming language designed to make programming more enjoyable for the serious programmer," was deleted twice by reviewers who refused to believe that the purpose of programming language design could be anything but some serious mutterings about productivity, management, and software engineering. However, C++ was designed primarily so that the author and his friends would not have to program in assembler, C, or various modern high-level languages. Its main purpose is to make writing good programs easier and more pleasant for the individual programmer. This was the case, whether those reviewers were willing to believe it or not. The focus of my work is the person, the individual (whether part of a group or not), the programmer. This line of reasoning has been strengthened over the years and is even more prominent in the second edition.
The C++ ProgrammingLanguage was the definition of C++ and the introduction to C++ for an unknown number of programmers and its presentation techniques and organization (borrowed with acknowledgments if not always sufficient skill from "The C Programming Language") have become the basis for an almost embarrassing number of articles and books. It was written with a fierce determination not to preach any particular programming technique. In the same way as I feared to build limitations into the language out of ignorance and misguided paternalism, 1 didn't want the book to turn into a "manifesto" for my personal preferences [Stroustrup 1991]. 15.3.7 The "whatis?" Paper Having shipped release !.0 and sent the camera-ready copy of the book to the printers, I finally found time to reconsider larger issues and to document overall design issues. Just then, Karel Babcisky (the
C++ SESSION
729
BJARNE STROUSTRUP
chairman of the Association of Simula Users) phoned from Osio with an invitation to give a talk on C++ at the 1986 ASU conference in Stockholm. Naturally I wanted to go, but I was worried that presenting C++ at a Simula conference would be seen as a vulgar example of self-advertisement and an attempt to steal users away from Simula. After all, I said, C++ is not Simula so why would Simula users want to hear about it. Karel replied, "Ah, we are not hung up on syntax." This provided me with an opportunity to write not only about what C++ was, but also what it was supposed to be and where it didn't measure up to those ideals. The result was the paper "What is "Object-Oriented Programming?" [Stroustrup 1986], which I presented to the ASU conference in Stockholm. The significance of this paper is that it is the first exposition of the set of techniques that C++ was aiming to provide support for. All previous presentations, to avoid dishonesty and hype, had been restricted to describe what features were already implemented and in use. The "whatis paper" defined the set of problems I thought a language supporting data abstraction and object-oriented programming ought to solve and gave examples of language features needed. The result was a reaffirmation of the importance of the "multi-paradigm" nature of C++: Object-oriented programming is programming using inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction. These techniques need proper support to be effective. Data abstraction primarily needs support in the form of language features and object-oriented programming needs further support from a programming environment. To be general purpose, a language supporting data abstraction or object-oriented programming must enable effective use of traditional hardware. The importance of static type checking was also strongly emphasized. In other words, C++ follows the Simula rather than the Smalltalk model of inheritance and type checking: a Simula or C++ class specifies a fixed interface to a set of objects (of any derived class) whereas a Smalltalk class specifies an initial set of operations for objects (of any subclass). In other words, a Smalltalk class is a minimal specification and the user is free to try operations not specified whereas a C++ class is an exact specification and the user is guaranteed that only operations specified in the class declaration will be accepted by the compiler. This has deep implications on the way one designs systems and on what language facilities are needed. A dynamically typed language such as Smalltalk simplifies the design and implementation of libraries by postponing type checking to run time. For example (using C++ syntax): s t a c k cs ; c s . p u s h ( n e w Saab900); cs.pop()->takeoff(); // Oops! Run time error: // a car does not have a takeoff
method.
This delayed type error detection was considered unacceptable for C++, yet there had to be a way of matching the notational convenience and the standard libraries of a dynamically typed language. The notion of parameterized types was presented as the (future) solution for that problem in C++: stack(plane*) cs; c s . p u s h ( n e w Saab37b); c s . p u s h ( n e w Saab900);
cs.pop()->takeoff(); cs.pop()->takeoff();
730
// ok a S a a b 3 7 b is a p l a n e // error, type mismatch: // car passed, plane* e x p e c t e d // no r u n - t i m e // no r u n - t i m e
check n e e d e d check n e e d e d
CHAPTER XV
PAPER: A HISTORY OF C++: 1979--1991
The key reason for considering compile-time detection of such problems essential, was the observation that C++ is often used for programs executing where no programmer is present. Fundamentally, the notion of static type checking was seen as the best way to provide the strongest guarantees possible for a program, rather than merely a way of gaining run-time efficiency. The "whatis" paper lists three aspects in which C++ was deficient: 1. Ada, Clu, and ML support parameterized types. C++ does not; the syntax used here is simply devised as an illustration. Where needed, parameterized classes are "faked" using macros. Parameterized classes would clearly be extremely useful in C++. They could easily be handled by the compiler, but the current C++ programming environment is not sophisticated enough to support them without significant overhead and/or inconvenience. There need not be any run-time overheads compared with a type specified directly. 2. As programs grow, and especially when libraries are used extensively, standards for handling errors (or more generally: "exceptional circumstances") become important. Ada, ALGOL 68, and Clu each support a standard way of handling exceptions. Unfortunately, C++ does not. Where needed, exceptions are "faked" using pointers to functions, "exception objects," "error states," and the C library s i g n a l and longjmp facilities. This is not satisfactory in general and fails even to provide a standard framework for error handling. 3. Given this explanation it seems obvious that it might be useful to have a class B inherit from two base classes A! and A2. This is called multiple inheritance. All three facilities were linked to the need to provide better (that is, more general, more flexible) libraries. All are now available in C++. Note that adding multiple inheritance and templates was considered as early as 1982 [Stroustrup 1982].
15.4 C++ RELEASE 2.0 Now (mid 1986), the course for C++ was set for all who cared to see. The key design decisions were made. The direction of the future evolution was for parameterized types, multiple inheritance, and exception handling. Much experimentation and adjustment based on experience was needed, but the glory days were over. C++ had never been silly putty, but there was now no real possibility for radical change. For good and bad, what was done was done. What was left was an incredible amount of solid work. At this point C++ had about 2,000 users worldwide. This was the point where the plan--as originally conceived by Steve Johnson and m e a w a s for a development and support organization to take over the day-to-day work on the tools (primarily Cfront), thus freeing me to work on the new features and the libraries that were expected to depend on them. This was also the point where I expected first AT&T, and then others, would start to build compilers and other tools to eventually make Cfront redundant. Actually, they had already started, but the good plan was soon derailed due to management indecisiveness, ineptness, and lack of focus. A project to develop a brand new C++ compiler diverted attention and resources from Cfront maintenance and development. A plan to ship a release 1.3 in early 1988 completely fell through the cracks. The net effect was that we had to wait until June of 1989 for release 2.0, and that even though 2.0 was significantly better than release 1.2 in almost all ways, 2.0 did not provide the language features outlined in the "whatis paper," and consequently a significantly improved and extended library wasn't part of it. Many of the people who influenced C with Classes and the original C++ continued to help with the evolution in various ways. Phil Brown, Tom Cargill, Jim Coplien, Steve Dewhurst, Keith Gorlen,
C++ SESSION
731
BJARNE STROUSTRUP
Laura Eaves, Bob Kelley, Brian Kernighan, Andy Koenig, Archie Lachner, Stan Lippman, Larry Mayka, Doug Mcllroy, Pat Philip, Dave Prosser, Peggy Quinn, Roger Scott, Jerry Schwarz, Jonathan Shopiro, and Kathy Stark were explicitly acknowledged in [Stroustrup 1989b]. Stability of the language definition and its implementation was considered essential. The features of 2.0 were fairly simple modifications of the language based on experience with the 1.* releases. The most important aspect of release 2.0 was that it increased the generality of the individual language features and improved their integration into the language. 15.4.1
Feature Overview
The main features of 2.0 were first presented in Stroustrup [1987c] and summarized in the revised version of that paper [Stroustrup ] 989b], which accompanied 2.0 as part of its documentation:
1. multiple inheritance, 2. type-safe linkage, 3. better resolution of overloaded functions, 4. recursive definition of assignment and initialization, 5. better facilities for user-defined memory management, 6. abstract classes, 7. static member functions, 8. c o n s t member functions, 9. p r o t e c t e d members (first provided in release 1.2), 10. overloading of operator ->, and 11. pointers to members (first provided in release 1.2). Most of these extensions and refinements represented experience gained with C++ and couldn't have been added earlier without more foresight than I possessed. Naturally, integrating these features involved significant work, but it was most unfortunate that this was allowed to take priority over the completion of the language as outlined in the "whatis" paper. Most features enhanced the safety of the language in some way or other. Cfront 2.0 checked the consistency of function types across separate compilation units (type-safe linkage), made the overload resolution rules order independent, and also ensured that more calls were considered ambiguous. The notion of c o n s t was made more comprehensive, and pointers to members closed a loophole in the type system and provided explicit class-specific memory allocation and deallocation operations to make the error-prone "assignment to t h i s " technique redundant. To some people, the most important "feature" of release 2.0 wasn't a feature at all but a simple space optimization. From the beginning, the code generated by Cfront tended to be pretty good. As late as 1992, Cfront generated the fastest running code in a benchmark used to evaluate C++ compilers on a Sparc. There have been no significant improvements in Cfront's code generation since Release 1.0. However, release 1.* was wasteful because each compilation unit generated its own set of virtual function tables for all the classes used in that unit. This could lead to megabytes of waste. At the time (about 1984), I considered the waste necessary in the absence of linker support, and asked for such linker support. By 1987 that linker support hadn't materialized. Consequently, I rethought the problem and solved it by the simple heuristic of laying down the virtual function table of a class right next to its first non-virtual non-inline function.
732
CHAPTER XV
PAPER: A HISTORY OF C++: 1979-1991
15.4.2
Multiple Inheritance
In most people's minds, multiple inheritance, the ability to have two or more direct base classes, is the feature of 2.0. I disagreed at the time because I felt that the sum of the improvements to the type system were of far greater practical importance. Also, adding multiple inheritance in 2.0 was a mistake. Multiple inheritance belongs in C++ but is far less important than parameterized types. As it happened, parameterized types in the form of templates only appeared in release 3.0. There were a couple of reasons for choosing to work on multiple inheritance at the time: The design was further advanced and the implementation could be done within Cfront. Another factor was purely itTational. Nobody doubted that I could implement templates efficiently. Multiple inheritance, on the other hand, was widely supposed to be very difficult to implement efficiently. Thus, multiple inheritance seemed more of a challenge, and since I had considered it as early as 1982 and found a simple and efficient implementation technique in 1984, I couldn't resist the challenge. I suspect that this is the only case where fashion affected the sequence of events. In September of 1984, I presented the C++ operator overloading mechanism at the IFIP WG2.4 conference in Canterbury [Stroustrup 1984c]. There I met Stein Krogdahl from the University of Oslo who was just finishing a proposal for adding multiple inheritance to Simula [Krogdahl 1984]. His ideas became the basis for the implementation of ordinary multiple base classes in C++. He and I later found out that the proposal was almost identical to an idea for providing multiple inheritance in Simula that had been considered by Ole-Johan Dahl in 1966 and rejected because it would have complicated the Simula garbage collector [Dahl 1988]. The original and fundamental reason for considering multiple inheritance was simply to allow two classes to be combined into one in such a way that objects of the resulting class would behave as objects of either base class [Stroustrup 1986c]: A fairly standard example of the use of multiple inheritance would be to provide two library classes displayed and task for representing objects under the control of a display manager and co-routines under the control of a scheduler, respectively. A programmer could then create classes such as class m y _ d i s p l a y e d //
task
: public
displayed,
public
task
{
...
}; class
my_task : public // ...
task
{ // n o t
displayed
}; class
my_displayed // ...
: public
displayed
{ // n o t
a task
};
Using (only) single inheritance only two of these three choices would be open to the programmer. The implementation requires little more than remembering the relative offsets of the Cask and d i s p l a y e d objects in a m y _ d i s p l a y e d _ t a s k object. All the gory implementation details were explained in Stroustrup [1987a]. In addition, the language design must specify how ambiguities are handled and what to do if a class is specified as a base class more than once in a derived class:
C++ SESSION
733
BJARNE STROUSTRUP
Ambiguities am handled ~ compile time: class A { public: void f(); /* ... */ }; class B { public: void f(); /* ... */ }; class C : public A, public B { /* no f() void g( ) { C* p; p->f(); }
// error:
...
*/ };
ambiguous
In this, C++ differs from the object-oriented Lisp dialects that support multiple inheritance. Basically, I rejected all forms of dynamic resolution beyond the use of virtual functions as unsuitable for a statically typed language under severe efficiency constraints. Maybe, I should at this point have revived the notion of c a l 1 and r e t u r n functions (Section 15.2.4.8) to mimic the CLOS : b e f o r e and : a f t e r methods. However, people were already worrying about the complexity of the multiple inheritance mechanisms and I am always reluctant to re-open old wounds. Multiple inheritance in C++ became controversial [Cargill 1991; Carroll 1991; Waldo 1991; Sakkinen 1992] for several reasons. The arguments against it centered around the real and imaginary complexity of the concept, the utility of the concept, and the impact of multiple inheritance on other extensions and tool building. In addition, proponents of multiple inheritance can, and do, argue over exactly what multiple inheritance is supposed to be and how it is best supported in a language. I think, as I did then, that the fundamental flaw in these arguments is that they take multiple inheritance far too seriously. Multiple inheritance doesn't solve all of your problems, but it doesn't need to because it is quite cheap, and sometimes it is very convenient to have. Grady Booth [Booch 1991 ] expresses a slightly stronger sentiment: "Multiple inheritance is like a parachute, you don't need it very often, but when you do it is essential." 15.4.3
Abstract Classes
The very last feature added to 2.0 before it shipped was abstract classes. Late modification to releases are never popular and late changes to the definition of what will be shipped are even less so. I remember that several members of management thought I had lost contact with the real world when I insisted on this feature. A common complaint about C++ was (and is) that private data is visible and that when private data is changed then code using that class must be recompiled. Often this complaint is expressed as "abstract types in C++ aren't really abstract." What I hadn't realized was that many people thought that because they could put the representation of an object in the private section of a class declaration then they actually hadto put it there. This is clearly wrong (and that is how I failed to spot the problem for years). If you don't want a representation in a class, thus making the class an interface only, then you simply delay the specification of the representation to some derived class and define only virtual functions. For example, one can define a s e t of T pointers like this: class set { public : virtual void virtual void virtual
734
int
insert(T*); remove(T*) ; is_member(T*);
CHAPTER XV
PAPER:A HISTORYOF C++: 1979-1991 virtual virtual
T* first(); T* next();
virtual
-set()
{ }
}; Thisprovidesalltheinformationthatpeopleneedto useaset, exceptthat whoev~actuallycm=esa set mustknow something abouthow some particularkind ofsetis ~p~sen~dForexample, given class slist_set : public slink* current_elem; public: void insert(T*); void remove(T*);
set, private
slist
{
int is member(T*); virtual T* first(); virtual T* next();
slist_set()
: slist(),
current_elem(0)
{ }
); we can create s l i s t _ s e t
objects that can be used as s e t s by users who have never heard of a
slist_set.
The only problem was that in C++, as defined before 2.0, there was no explicit way of saying: "The s e t class is just an interface: its functions need not be defined, it is an error to create objects of class s e t , and anyone who derives a class from s e t must define the virtual functions specified in s e t . " Release 2.0 allowed a class to be declared explicitly abstract by declaring one or more of its virtual functions "pure" using the syntax =0: class set { public : virtual void insert(T*) virtual void remove(T*) //
// abstract
class
= 0; // pure virtual = 0;
function
..o
); The =0 syntax isn't exactly brilliant, but it expresses the desired notion of a pure virtual function in a way that is terse and fits the use of 0 to mean "nothing" or "not there" in C and C++. The alternative, introducing a new keyword, say p u r e , wasn't an option. Given the opposition to abstract classes as a "late and unimportant change," I would never simultaneously have overcome the traditional, strong, widespread, and emotional opposition to new keywords in parts of the C and C++ community. The importance of the abstract class concept is that it allows a cleaner separation between a user and an implementor than is possible without it. This limits the amount of recompilation necessary after a change and also the amount of information necessary to compile an average piece of code. By decreasing the coupling between a user and an implementor, abstract classes provide an answer to people complaining about long compile times, and also serve library providers who must worry about the impact on users of changes to a library implementation. I had unsuccessfully tried to explain these
C++ SESSION
735
BJARNE STROUSTRUP
notions in Stroustrup [1986b]. With an explicit language feature supporting abstract classes, I was much more successful [Stroustrup 1991]. 15.5
THE EXPLOSION IN INTEREST AND USE
C++ was designed to serve users. It was not an academic experiment to design the perfect programming language. Nor was it a commercial product meant to enrich its developers. Thus, to fulfill its purpose C++ had to have users--and it had: C++ Use Date
Estimated number of users
Date
Estimated number of users
Oct 1979
1
Oct 1986
2,000
Oct 1980
16
Oct 1987
4,000
Oct 1981
38
Oct 1988
15,000
Oct 1982
85
Oct 1989
50,000
Oct 1983
??+2 (no Cpre count)
Oct 1990
150,000
Oct 1984
??+50 (no Cpre count)
Oct 1 9 9 1
400,000
Oct 1985
500
In other words, the C++ user population doubled every 7.5 months or so. These are conservative figures. The actual number of C++ users has never been easy to count. First, there are implementations, such as GNU's G++ and Cfront, shipped to universities for which no meaningful records can be kept. Second, many companies, both tools suppliers and end users, treat the number of their users and the kind of work they do like state secrets. However, I always had many friends, colleagues, contacts, and many compiler suppliers who were willing to trust me with figures as long as I used them in a responsible manner. This enabled me to estimate the number of C++ users. These estimates are created by taking the number of users reported to me or estimated based on personal experience, rounding them all down, adding them, and then rounding down again. These number are the estimates made at the time and not adjusted in any way. To support the claim that these figures are conservative, I can mention that Borland, the largest single C++ compiler supplier, publicly stated that it had shipped 500,000 compilers by October of 1991. Eady users had to be gained without the benefit of traditional marketing. Various forms of electronic communication played a crucial role in this. In the early years most distribution and all support was done using e-mail, and relatively early on, newsgroups dedicated to C++ were created (not at the initiative of Bell Labs employees) that allowed a wider dissemination of information about the language, techniques, and the current state of tools. These days this is fairly ordinary, but in 1981 it was relatively new. I think that only the spread of Interlisp over the Arpanet provides a contemporary parallel. Later, more conventional forms of communication and marketing arose. After AT&T released Cfront 1.0, some resellers, notably Glockenspiel in Ireland and their US distributor Oasys (later part of Green Hills), started some minimal advertising in 1986, and when independently developed C++ compilers such as Oregon Software's C++ Compiler (developed by Mike Ball at TauMetric Software in San Diego) and Zortech's C++ Compiler (developed by Walter Bright in Seattle) appeared, 'C++' became a common sight in ads (from about 1988).
736
CHAPTER XV
PAPER:A HISTORYOF C++: 1979.-"1991 15.5.1
Conferences
In ]987 USE]NIX, the UNIX Users' association, took the initiative to hold the first conference specifically devoted to C++. Thirty papers were presented to 214 people in Santa Fc, New Mexico in November of 1987. The Santa Fe conference set a good example for future conferences with a mix of papers on applications, programming and teaching techniques, ideas for improvements to the language, libraries, and implementation techniques. Notably for a USENIX conference, there were papers on C++ on the Apple MAC, OS/2, the Connection machine, and for implementing non-UNIX operating systems (for example, CLAM [Call 1987] and Choices [Campbell 1987]). The NIH library [Gorlen 1987] and the Inverviews library [Linton 1987] also made their public debut in Santa Fe. An early version of what became Cfront 2.0 was demonstrated, and I gave the first public presentation of its features. The USENIX C++ conferences continue as the primary technically and academically oriented C++ conference. The proceedings from these conferences are among the best reading about C++ and its use. In addition to the USENIX C++ conferences, there are now many commercial and semi-commercial conferences devoted to C++, to C including C++, and to Object-Oriented Programming. 15.5.2
Journals and Books
By 1991 there were more than 60 books on C++ available in English alone, and both translations and locally written books available in languages such as Chinese, Danish, French, German, and Japanese. Naturally, the quality varies enormously. The first journal devoted to C++, The C++ Report, from SIGS publications, started publishing in January of 1989, with Rob Murray as its editor. A larger and glossier quarterly, The C++ Journal, appeared in the spring of 1991. In addition, there are several newsletters controlled by C++ tools suppliers and many journals such as Computer Language, The Journal of Object-Oriented Programming, Dr. Dobbs Journal, and The C Users'Journal run regular columns or features on C++. Andrew Koenig's column in JOOP is particularly consistent in its quality and lack of hypeo Newsgroup and bulletin boards such as comp.lang.c++ on usenet and c.plus.plus on BIX have also produced tens of thousands of messages over the years to the delight and despair of readers. Keeping up with what is written about C++ is currently more than a full time job. 15.5.3
Libraries
The very first real code written in C with Classes was the task library [Stroustrup 1980b], which provided Simula-like concurrency for simulation. The first real programs were simulations of network traffic, circuit board layout, and so forth, using the task library. The task library is still heavily used today. The standard C library was available from C++, without overhead or complication compared with C, from day one. So are all other C libraries. Classical data types, such as character strings, range checked arrays, dynamic arrays, and lists, were among the examples used to design C++ and test its early implementations. The early work with container classes such as list and array were severely hampered by the lack of support for a way of expressing parameterized types in C with Classes and in C++ up until version 3.0. In the absence of proper language support (later provided in the form of templates (Section 15.6.3), we had to make do with macros. The best that can be said for the C preprocessor's macro facilities is
C++ SESSION
737
BJARNE STROUSTRUP
that they allowed us to gain experience with parameterized types and support individual and small group use. Much of the work on designing classes was done in cooperation with Jonathan Shopiro, who in 1983 produced list and string classes that saw wide use within AT&T and are the basis for the classes currently found in the "Standard Components" library that was developed in Bell labs, and is now sold by USL. The design of these early libraries interacted directly with the design of the language and in particular with the design of the overloading mechanisms. 15.5.3,1
The Stream I/0 Library
C ' s p r i n t f family of functions is an effective and often convenient I/O mechanism. It is not, however, type safe or extensible to user-defined types (classes). Consequently, I started looking for a type safe, terse, extensible, and efficient alternative to the p r i n t f family. Part of the inspiration came from the last page and a half of the Ada Rationale [Ichbiah 1979], which is an argument that you cannot have a terse and type-safe UO library without special language features to support it. I took that as a challenge. The result was the stream UO library that was first implemented in 1984 and presented in [Stroustrup 1985]. Soon after, Dave Presotto re-implemented the stream library without changing the interfaces. To introduce stream UO this example was considered: fprintf(stderr,'x
=
%s\n',x)
;
Because f p r i n t f ( ) relies on unchecked arguments that are handled according to the format string at run time, this is not type safe and had x been a user-defined type like complex there would have been no way of specifying the output format of x in the convenient way used for types "known to p r i n t f ( )" (for example, %s and %d). The programmer would typically have defined a separate function for printing complex numbers and then written something like this: fprintf(stderr,"x = "); put_complex (s t d e r r , x) ; f p r i n t f ( s t d e r r , "\n" ) ;
This is inelegant. It would have been be a major annoyance in C++ programs that use many user-defined types to represent entities that are interesting/critical to an application. 'IXjpe-secufity and uniform treatment can be achieved by using a single overloaded function name for a set of output functions. For example: p u t ( s t d e r r , "x = "); put (stderr,x) ; p u t ( s t d e r r , "\n") ;
The type of the argument determines which "put function" will be invoked for each argument. However, this
is too verbose. The C++ solution, using an output stream for which class v e c t o r { T* v; int sz; public: vector(int); T& operator[] (int); T& elem(int i) { return v[i]; // ... };
)
The t e m p l a t e < c l a s s T> p~fix specifies Mat a ~mplate is being declared and Mat an argument T of ~ p e type will be used in the declaration. After its introduction, T is used exactly like other type names wiMin Me scope of the mmplate declaration. Vectos can then be used like this: v e c t o r < i n t > vl(20); v e c t o r < c o m p l e x > v2(30); typedef
vector
= 7; = v3.elem(4)
// make cvec a s y n o n y m // v e c t o r < c o m p l e x >
for
/ / v2 and v3 are of the same type
cvec v3(40);
vl[3] v213]
cvec;
= complex(7,8) ;
C++ does not require the user to explicitly "instantiate" a template; that is, the user need not specify which versions of a template need to be generated for particular sets of template arguments. The reason is that only when the program is complete can it be known what templates need to be instantiated. Many templates will be defined in libraries and many instantiations will be directly and indirectly caused by users that don't even know of the existence of those templates. It therefore seemed unreasonable to require the user to request instantiations (say, by using something like Ada's 'new' operator). Avoiding unnecessary space overheads caused by too many instantiations of template functions was considered a first order, that is, language level problem rather than an implementation detail. I considered it unlikely that early (or even late) implementations would be able to look at instantiations of a class for different template arguments and deduce that all or part of the instantiated code could be shared. The solution to this problem was to use the derived class mechanism to ensure code sharing among derived template instances. The template mechanism is completely a compile and link time mechanism. No part of the template mechanism needs run-time support. This leaves the problem of how to get the classes and functions generated (instantiated) from templates to depend on information known only at run time. The answer was, as ever in C++, to use virtual functions and abstract classes. Abstract classes used in connection with templates also have the effect of providing better information hiding and better separation of programs into independently compiled units.
15.6.4
Exception Handling
Exceptions were considered in the original design of C++, but were postponed because there wasn't time to do a thorough job of exploring the design and implementation issues. Exceptions were considered essential for error handling in programs composed out of separately designed libraries. 744
CHAPTER XV
PAPER: A HISTORY OF C++: 1979--1991
The actual design of the C++ exception mechanism stretched from 1984 to 1989. Andrew Koenig was closely involved in the later iterations and is the co-author (with me) of the published papers [Koenig 1989a, 1990, 1990]. I also had meetings at Apple, DEC, Microsoft, IBM, Sun, and other places where I presented draft versions of the design and received valuable input. In particular, I searched out people with actual experience with systems providing exception handling to compensate for my personal inexperience in that area. Throughout the design effort there was an increasing influence of systems designers of all sorts and a decrease of input from the language design community. In retrospect, the greatest influence on the C++ exception handling design was the work on fault-tolerant systems started at the University of Newcastle in England by Brian Randeli and his colleagues, and continued in many places since. The following assumptions were made for the design: • Exceptions are used primarily for error handling. • Exception handlers are rare compared to function definitions. • Exceptions occur infrequently compared to function calls. These assumptions, together with the requirement that C++ with exceptions should cooperate smoothly with languages without exceptions, such as C and FORTRAN, led to a design with multilevel propagation. The view is that not every function should be a firewall and that the best error-handling strategies are those where only designated major interfaces are concerned With nonlocal error handling issues. By allowing multilevel propagation of exceptions, C++ loses one aspect of static checking. One cannot, simply by looking at a function, determine which exceptions it may throw. C++ compensates by providing a mechanism for specifying a list of exceptions that a function may throw. I concluded that the ability to define groups of exceptions is essential. For example, a user must be able to catch "any I/O library exceptionr' without knowing exactly which exceptions those are. Many people, including Ted Goldstein and Peter Deutsch, noticed that most such groups were equivalent to class hierarchies. We therefore adopted a scheme inspired by ML where you throw an object and catch it by a handler declared to accepts objects of that type. This scheme naturally provides for type-safe transmission of arbitrary amounts of information from a throw point to a handler. For example: class class class class class // ...
Matherr { /* ... */ ); Overflow : public Matherr { /* ... */ }; Underflow : public Matherr { /* ... */ }; Zerodivide : public Matherr { /* ... */ }; Int_add_overflow : public Overflow { /* ...
*/
};
try { f(); } c a t c h ( O v e r f l o w & over) // h a n d l e O v e r f l o w }
{ or a n y t h i n g
derived
from
Overflow
catch (Matherr& math) { // h a n d l e a n y M a t h e r r }
C++ SESSION
745
BJARNE STROUSTRUP
Thus f ( ) mightbewrit~nlikethis void f() throw(Matherr&)
//
// f() can throw Matherr& exceptions // (and only Matherr& exceptions)
°..
if (d == O) throw Zerodivide(); /!
...
if
(check(x,y)
//
...
) throw Int_add_overflow(x,y);
}
The Z e r o d i v i d e will be caught by the M a t h e r r & handler above and I n t a d d _ o v e r f l o w will be caught by the overflow& handler that might access the operand values x and y passed by f ( ) in the object thrown. The central point in the exception handling design was the management of resources. In particular, if a function grabs a resource, how can the language help the user to ensure that the resource is correctly released upon exit even if an exception occurs? The problem with most solutions is that they are verbose, tedious, potentially expensive and therefore error-prone. However, I noticed that many resources are released in the reverse order of their acquisition. This strongly resembles the behavior of local objects created by constructors and destroyed by destructors. Thus we can handle such resource acquisition and release problems by a suitable use of objects of classes with constructors and destructors. This technique extends to partially constructed objects and thus addresses the otherwise difficult issue of what to do when an error is encountered in a constructor. During the design, the most contentious issue turned out to be whether the exception handling mechanism should support termination semantics or resumption semantics; that is, whether it should be possible for an exception handler to require execution to resume from the point where the exception was thrown. The main resumption vs. termination debate took place in the ANSI C++ committee. After a discussion that lasted for about a year, the exception handling proposal as presented in the ARM (that is, with termination semantics) was voted into C++ by an overwhelming majority. The key to that consensus were presentations of experience data based on decades of use of systems that supported both resumption and termination semantics by representatives of DEC, Sun, Texas Instruments, IBM, and others. Basically, every use of resumption had represented a failure to keep separate levels of abstraction disjoint. The C++ exception handling mechanism is explicitly not for handling asynchronous events directly. This view precludes the direct use of exceptions to represent something like hitting a DEL key and the replacement of UNIX signals with exceptions. In such cases, a low-level interrupt routine must somehow do its minimal job and possibly map into something that could trigger an exception at a well-defined point in a program's execution. As ever, efficiency was a major concern. The C++ exception handling mechanism can be implemented without any run-time overhead to a program that doesn't throw an exception [Stroustrup 1988b]. It is also possible to limit space overhead, but it is hard simultaneously to avoid run-time overhead and code size increases. The first implementations of exception handling as defined in the ARM are just appearing (Spring 1992).
15.6.5 ANSI and ISO The initiative to formal (ANSI) standardization of C++ was taken by HP in conjunction with AT&T, DEC, and IBM. Larry Rosler from HP was important in this initiative. The proposal for ANSI 74,6
CHAPTER XV
PAPER: A HISTORY OF C++: 1979-1991
standardization was written by Dmitry Lenkov [Lenkov 1989]. Dmitry's proposal cites several reasons for immediate standardization of C++: • C++ is going through a much faster public acceptance than most other languages. • Delay will lead to dialects. • Requires a careful and detailed definition providing full semantics for each language feature. • C++ lacks some important features ... exception handling, aspects of multiple inheritance, features supporting parametric polymorphism, and standard libraries. The proposal also stressed the need for compatibility with ANSI C. The organizational meeting of the ANSI C++ committee, X3J16, took place in December of 1989 in Washington, D.C. and was attended by about 40 people, including people who took part in the C standardization, people who by now were "old time C++ programmers." Dmitry Lenkov became its chairman and Jonathan Shopiro became its editor. The committee now has more than 250 members out of which something like 70 turn up at meetings. The aim of the committee was, and is, a draft standard for public review in late 1993 or early 1994 with the hope of an official standard about two years later. 5 This is an ambitious schedule for the standardization of a general-purpose programming language. To compare, the standardization of C took seven years. Naturally, standardization of C++ isn't just an American concern. From the start, representatives from other countries attended the ANSI C++ meetings; and in Lund, Sweden, in June of 1991 the ISO C++ committee WG21 was convened and the two C++ standards committees decided to hold joint meetings--starting immediately in Lund. Representatives from Canada, Denmark, France, Japan, Sweden, UK, and USA were present. Notably, the vast majority of these national representatives were actually long-time C++ programmers. The C++ committee had a difficult charter: 1. 2. 3. 4.
The definition of the language must be precise and comprehensive. C/C++ compatibility had to be addressed. Extensions beyond current C++ practice had to be considered. Libraries had to be considered.
On top of that, the C++ community was very diverse and totally unorganized so that the standards committee naturally became an important focal point of that community. In the short run, that is actually the most important role for the committee. C compatibility was the first major controversial issue we had to face. After some~-occasionally heated--debate it was decided that 100 percent C/C++ compatibility wasn't an option. Neither was significantly decreasing C compatibility. C++ was a separate language and not a strict superset of ANSI C and couldn't be changed to be such a superset without breaking the C++ type system and without breaking millions of lines of C++ code. This decision, often referred to as "As close to C, but no closer" after a paper written by Andrew Koenig and me [Koenig 1989a], is the same that has been reached over and over again by individuals and groups considering C++ and the direction of its evolution (Section 15.3.4).
5
W e still expect to see a C + + ISO standard in late 1995 to mid-1996.
C++ SESSION
747
BJARNE STROUSTRUP
15.6.6
Rampant Featurism?
A critical issue was--and is---how to handle the constant stream of proposals for language changes and extensions. The focus of that effort is the extensions working group of which I'm the chairman. It is much easier to accept a proposal than to reject it. You win friends this way and people praise the language for having so many "neat features." Unfortunately, a language made as a shopping list of features without coherence will die, so there is no way we could accept even most of the features that would be of genuine help to some section of the C++ community. So how is the committee doing? We won't really know until the standard appears because there is no way of knowing which, if any, of the backlog of proposals will be accepted. There is some hope of restraint and that accepted features will be properly integrated into the language. Only three new features have been accepted so far: the "mandated" extensions (exception handling and templates), and a proposal for relaxing the requirements for return types for overriding functions. 6 15.7
RETROSPECTIVE
It is often claimed that hindsight is an exact science. It is not. The claim is based on the false assumptions that we know all relevant facts about what happened in the past, that we know the current state of affairs, and that we have a suitably detached point of view from which to judge the past. Typically none of these conditions hold. This makes a retrospective on something as large, complex, and dynamic as a programming language in large scale use hazardous. Anyway, let me try to stand back and answer some hard questions: 1. Did C++ succeed at what it was designed for? 2. Is C++ a coherent language? 3. What was the biggest mistake? Naturally, the replies to these questions are related. The basic answers are, 'yes,' 'yes,' and 'not shipping a larger library with release 1.0.'
15.7.1
Did C++ succeed at what it was designed for?
"C++ is a general purpose programming language designed to make programming more enjoyable for the serious programmer" [Stroustrup 1986b]. In this, it clearly succeeded, especially in the more specific aim of letting reasonably educated and experienced programmers write programs at a higher level of abstraction ("as in Simula"), without loss of efficiency compared to C, for applications that were demanding in time, space, inherent complexity, and constraints from the execution environment. More generally, C++ made object-oriented programming and data abstraction available to the community of software developers that until then had considered such techniques and the languages that supported them such as Smalltalk, Clu, Simula, Ada, OO Lisp dialects, and so on, with disdain and even scorn: "expensive toys unfit for real problems." C++ did three things to overcome this formidable barrier: As I write this, the chance of any significant additions to the C++ language by the standard committee is about zero. Many minor extensions were added, but I think that C++ is now a significantly more powerful, pleasant, and coherent language than it was when the standards process started. The major "new" extensions were run-time type information, namespaces, and the sum of many minor improvements to templates; see [Stroustrup 1994].
748
CHAPTER XV
PAPER: A HISTORYOF C++: 1979-1991
1. It produced code with run-time and space characteristics that competed head-on with the perceived leader in that field: C. Anything that matches or beats C must be fast enough. Anything that doesn't can and will out of need or mere prejudice--be ignored. 2. It allowed such code to be integrated into conventional systems and produced on traditional systems. A conventional degree of portability, the ability to coexist with existing code, and the ability to coexist with traditional tools, such as debuggers and editors, was essential. 3. It allowed a gradual transition to these new programming techniques. It takes time to learn new techniques. Companies simply cannot afford to have significant numbers of programmers unproductive while they are learning. Nor can they afford the cost of failed projects caused by programmers poorly trained and inexperienced in the new techniques failing by over enthusiastically misapplying ideas. In other words, C++ made object-oriented programming and data abstraction cheap and accessible. In succeeding, C++ didn't just help "itself" and the C++ programmers. It also provided a major impetus to languages that provided different aspects of object-oriented programming and data abstraction. C++ isn't everything to all people and doesn't deliver on every promise ever made about some language or other. It does deliver on its own promises often enough to break down the wall of disbelief that stood in the way of all languages that allowed programmers to work at a higher level of abstraction. 15.7.2
Is C++ a Coherent Language?
C++ was successful in its own terms and is an effective vehicle for systems development, but is it a good language? Does C++ have an ecological niche now that the barriers of ignorance and prejudice against abstraction techniques have been broken? Basically, ] am happy with the language and quite a few users agree. There are many details I'd like to improve if [ could, but the fundamental concept of a statically typed language using classes with virtual functions as the inheritance mechanism and facilities for low-level programming is sound. 15.7.2.1
What Shou/d and Cou/d Have Been Different?
Given a clean slate, what would be a better language than C++ for the things C++ is meant for? Consider the first order decisions: use of static type checking, clean separation between language and environment, no direct support for concurrency, ability to match the layout of objects and call sequences for languages such as C and FORTRAN, and C compatibility. First, I considered, and still consider, static type checking essential both as a support for good design and secondarily for delivering acceptable run-time efficiency. Were I to design a new language for what C++ is used for today, I would again follow the Simula model of type checking and inheritance, n o t the Smalltalk or Lisp models. As I have said many times, "Had I wanted an imitation Smalltalk, I would have built a much better imitation. Smalltalk is the best Smalltalk around. If you want Smalltalk, use it" [Stroustrup 1990]. Having both static type checking and dynamic type identification (for example, in the form of virtual function calls) implies some difficult tradeoffs compared to a language with only static or only dynamic type checking. The static type model and the dynamic type model cannot be identical and thus there will be some complexity and inelegance that can be avoided by supporting only one type model. However, I wouldn't want to write programs with only one model.
C++ SESSION
749
~ARNE STROUSTRUP
I also still consider a separation between the environment and the language essential. I do not want to use only one language, only one set of tools, and only one operating system. To offer a choice, separation is necessary. However, once the separation exists one can provide different environments to suit different tastes and different requirements for supportiveness, resource consumption, and portability. We never have a clean slate. Whatever new we do, we must also make it possible for people to make a transition from old tools and ideas to new. Thus, if C hadn't been there for C++ to be almost compatible with, then I would have chosen to be almost compatible with some other language. Should a new language support garbage collection directly, say, like Modula-3 does? If so, could C++ have met its goals had it provided garbage collection? Garbage collection is great when you can afford it. Therefore, the option of having garbage collection is clearly desirable. However, garbage collection can be costly in terms of run time, real-time response, and porting effort (exactly how costly is the topic of much confused debate). Therefore, being forced to pay for garbage collection at all times isn't necessarily a blessing. C++ allows optional garbage collection [Ellis 1990], and I expect to see many experiments with garbage-collecting C++ implementations in the near future. However, I am convinced (after reviewing the issue many times over the years) that had C++ depended on garbage collection it would have been stillborn. Should a language have reference semantics for variables (that is, a name is really a pointer to an object allocated elsewhere) like Smalltalk or Clu, or true local variables like C and Pascal? This question relates to several issues, such as coexistence with other languages, compatibility, and garbage collection. Simula dodged the question by having references to class objects (only) and true variables for objects of built-in types (only). Again, I consider it an open issue whether a language could be designed that provided the benefits of both references and true local variables without ugliness. Given a choice between elegance and the benefits of having both references and true local variables, I'll take the two kinds of variables. 15.7.2.2
What Should Have Been Left Out?
Even Stroustrup [1980a] voiced concern that C with Classes might have become too large. I think "a smaller language" is number one on any wish list for C++; yet people deluge me, and the standards committee, with extension proposals. The fundamental reason for the size of C++ is that it supports more than one way of writing programs, more than one programming paradigm. From one point of view, C++ is really three languages in one: A C-like language plus an Ada-like language, plus a Simula-like language, plus what it takes to integrate those features into a coherent whole. Brian Kernighan observes that in C there is usually about one way of solving a given problem, whereas in C++ there are more. I conjecture that there typically is more than one way in C but that people don't see them. In C++, there are typically at least three alternatives and experienced people have quite a hard time not seeing them. There always is a design choice but in most languages the language designer has made the choice for you. For C++ I did not; the choice is yours. This is naturally abhorrent to people who believe that there is exactly one right way of doing things. It can also scare beginners and teachers who feel that a good language is one that you can completely understand in a week. C++ is not such a language. It was designed to provide a tool set for a professional, and complaining that there are too many features is like the "layman" looking into an upholsterer's tool chest and exclaiming that there couldn't possibly be a need for all those little hammers.
750
CHAPTER XV
PAPER:A HISTORYOF C++: 1979-1991 15.7.2.3
What Should Have Been Added?
As ever, the principle is to add as little as possible. A letter published on behalf of the extensions working group of the C++ standards committee puts it this way: First, let us try to dissuade you from proposing an extension to the C++ language. C++ is already too large and complicated for our taste and there are millions of lines of C++ code "out there" that we endeavor not to break. All changes to the language must undergo tremendous consideration. Additions to it are undertaken with great trepidation. Wherever possible we prefer to see programming techniques and library functions used as alternatives to language extensions. Many communities of programmers want to see their favorite language construct or library class propagated into C++. Unfortunately, adding useful features from diverse communities could turn C++ into a set of incoherent features. C++ is not perfect, but adding features could easily make it worse instead of better [Stroustrup i 992b]. So, given that, what features have caused trouble by their absence and which are under debate so that they might make it into C++ over the next couple of years? The feature I regret not having put in much earlier, when it could be done without formal debate and experimentation was easy, is some form of name space control. 7 C++ follows C in having a single global name space. C++ alleviates the problems that causes with class scopes and overloading mechanisms, but as programs grow, and especially as independent libraries are developed and later used together in a single program, the problem of name space clashes increases. My only defense is that I didn't like the resolution mechanisms I looked at, such as Ada packages and Modula-2 modules, because they had too great an overlap with the C++ class mechanism and, thus, didn't fit. In the original C++ design, I deliberately didn't include the Simula mechanisms for run-time type identification (QUAand INSPECT). My experience was that they were almost always misused, so that the benefits from having the mechanism would be outweighed by the disadvantages. Several proposals for providing some form of run-time type identification have arisen over the years and the focus is now on a proposal for dynamic casts, that is, type conversions that are checked at run time by Dmitry Lenkov and me [Stroustrup 1992a]. Like other extension proposals, it is going through extensive discussion and experimentation and is unlikely to be accepted in the form presented in that paper. 8 15.7.3
What Was The Biggest Mistake?
To my mind there really is only one contender for the title of "worst mistake." Release 1.0 and my first edition [Stroustrup 1986b] should have been delayed until a larger library, including some simple classes such as singly and doubly linked lists, an associative array class, a range checked array class, and a simple string class, could have been included. The absence of those led to everybody reinventing the wheel and to an unnecessary diversity in the most fundamental classes. However, could I have done that? In a sense, I obviously could. The original plan for my book included three library chapters, one on the stream library, one on the container classes, and one on the task library, so I knew roughly what I wanted. Unfortunately, I was too tired and couldn't do container classes without some form of templates. 7 A facility for definingand using name spaces was introduced into C++ in 1994;see Stroustrup [1994]. 8 Afterextensive discussion and revision, a mechanismfor run-time type informationbased on this proposal was accepted in 1993;s¢¢ Stroustrup [1994].
C++ SESSION
751
BJARNE STROUSTRUP 15.7.4
Hopes for the Future
May C++ serve its user community well. For that to happen, the language itself must be stable and well-specified. The C++ standards group and the C++ compiler vendors have a great responsibility here. In addition to the language itself, we need libraries. Actually, we need a libraries industry to produce, distribute, maintain, and educate people. This is emerging. The challenge is to allow programs to be composed out of libraries from different vendors. This is hard and might need some support from the standards committee in the form of standard classes and mechanisms that ease the use of independently developed libraries. 9 The language itself, plus the libraries, define the language that a user de facto writes in. However, only through good understanding of the application areas and design techniques will the language and library features be put to good use. Thus there must be an emphasis on teaching people effective design techniques and good programming practices. Many of the techniques we need have still to be developed, and many of the best techniques we do have still compete with plain ignorance and snake oil. I hope for far better textbooks for the C++ language and for programming and design techniques, and especially for textbooks that emphasize the connection between language features, good programming practices, and good design approaches. Techniques, languages, and libraries must be supported by tools. The days of C++ programming supported by simply a "naked" compiler are almost over, and the best C++ tools and environments are beginning to approach the power and convenience of the best tools and environments for any language. We can do much better. The best has yet to come.
ACKNOWLEDGMENTS It is clear that given the number of people who have contributed to C++ in some form or other over the last 12 years or so, 1 must have left most unmentioned. Some have been mentioned in this paper, more can be found in Sectuib 15. 1.2c of the ARM, and other acknowledgment sections of my books and papers. Here 1'11just mention Doug Mcllroy, Brian Kernighan, Andrew Koenig, and Jonathan Shopiro, who have provided constant help, ideas, and encouragement to me, and others, for a decade. I'd also like to mention the people who have done much of the hard, but usually unnoticed and unacknowledged, work of developing and supporting Cfront through the years when we were always short of resources: Steve Dewhurst, Laura Eaves, Andrew Koenig, Stan Lippman, George Logothetis, Glen McClusky, Judy Ward, Nancy Wilkinson, and Barbara Moo, who managed AT&T Bell Lab's C++ development and support group during the years when the work got done. Also, thanks to C++ compiler writers, library writers, and so forth, who sent me information about their compilers and tools, most of which went beyond what could be presented in a paper: Mike Ball, Walter Bright, Keith Gorlen, Steve Johnson, Kim Knuttilla, Archie Lachner, Doug Lea, Mark Linton, Aron lnsinga, Doug Lea, Dmitri Lenkov, Jerry Schwarz, Michael Tiemann, and Mike Vilot. Also thanks to people who read drafts of this paper and provided many constructive comments: Dag Bruck, Steve Buroff, Peter Juhl, Brian Kernighan, Andrew Koenig, Stan Lippmann, Barbara Moo, Jerry Schwarz, and Jonathan Shopiro. Most comments on the various versions of this paper were of the form "This paper is too long ... please add information about X, Y, and Z ... also, be more detailed about A, B, and C." 1 have tried to follow the first part of that advice, though the constraints of the second part have ensured that this did not become a short paper. Without Brian Kernighan's help this paper would have been much longer. 9 The standard library now provides containers and algorithms serving this need.
752
CHAPTER XV
PAPER: A HISTORY OF C++: 1979-1991
REFERENCES [Babcisky, 1984] Babcisky, Karel. Simula Performance Assessment, Proceedings of the IFIP WG2.4 conference on System Implementation Languages: Experience and Assessment. Canterbury, Kent, UK. Sept. 1984. [Birtwistle, 1979] Birtwistle, Graham, Dahl, Ole-Johan, Myrhaug, Bcjrn, and Nygaard, Kristen. SIMULA BEGIN, Studentlitteratur, Land, Sweden, 19?9. [Booch, 1991 ] Booch, Grady. Object-Oriented Design, Benjamin Cummings, 199 I. [Booch, 1990] Booch, Grady, and Vilot, Michael M. The Design of the C++ Booch Components, Proceedings of OOPSLA'90. [Call, 1987] Call, Lisa A., et al. An Open System for Graphical User Interfaces, Proceedings t~fthe USENIX C+ + Conference, Santa Fe, NM, Nov. 1987. [Campbell, 1987] Campbell, Roy, et al. The Design of a Multiprocessor Operating System, Proceedings USENIX C++ Conference, Santa Fe, NM, Nov. 1987. [Cargill, 1991] Cargill, Tom A. The Case Against Multiple Inheritance in C++, USENIX Computer Systems, Vol. 4, No. 1, 1991. [Carroll, 1991] Carroll, Martin. Using Multiple Inheritance to Implement Abstract Data Types, The C++ Report, Apr. 1991. [Cristian, 1989] Cristian, Flaviu. Exception Handling, in Dependability of Resilient Computers, T. Andersen, Ed., BSP Professional Books, Blackwell Scientific Publications, 1989. [Cox, 1986] Cox, Brad. Object-Oriented Programming: An Evolutionary Approach, Reading, MA: Addison-Wesley, 1986. [Dahl, 1988] Dahl, Ole-Johan. Personal communication. [Ellis, 1990] Ellis, Margaret A., and Stroustrup, Bjarne. The Annotated C+ + Reference Manual, Reading, MA: Addison-Wesley, 1990. [Goldherg, 1983] Goldberg, Adele, and Robson, David. SmaUtalk-80, The language and its Implementation, Reading, MA: Addison-Wesley, 1983. [Goodenough, 1975] Goodenough, John. Exception Handling: Issues and a Prolu~sedNotation, CACM, Dec. 1975. [Gorlen, 1987] Gorlen, Keith E. An Object-Oriented Class Library for C++ Programs, Proceedings of the USENIX C++ Conference, Santa Fe, NM, Nov. 1987. [Gorlen, 1990] Gorlen, Keith E., Orlow, Sanford M., and Plexico, Perry S. Data Abstraction and Object-OrientedProgramming in C+ +, West Sussex, England: Wiley, 1990. [lchbiah, 1979] lchbiah, Jean D., et al. Rationale~r the Design of the ADA Programming Language, SIGPLAN Notices, Vol. 14, No. 6, June 1979, Part B. [Johnson, 1989] Johnson, Ralph E. The Importance of Being Abstract, The C++ Report, Vol. 1, No. 3, Mar. 1989. [Kernighan, 1981] Kernighan, Brian, and Ritchie, Dennis. The C Programming Language, Englewood Cliffs, NJ: Prentice-Hall, 1978. [Kernighan, 1981] Kernighan, Brian. Why Pascal is not my Favorite Programming Language, AT&T Bell Labs Computer Science Technical Report No. 100, July 1981. [Kernighan, 1988] Kernighan, Brian, and Ritchie, Dennis. The C Programming Language (second edition), Englewood Cliffs, N J: Prentice-Hall, 1988. ISBN 0-13-110362-8. [Kiczales, 1992] Kiczales, Gregor, des Rivieres, Jim, and Bobrow, Daniel G., The Art ~!fthe Metaobject Protocol, Cambridge, MA: MIT Press, 1991. [Koenig,1988] Koenig, Andrew. Associative arrays in C++, Proceedings of the USENIX Conference, San Francisco, June 1988. [Koenig, 1989] Koenig, Andrew, and Stroustrup, Bjarne. C+ +: As close to C as possible--but no closer, The C++ Report, Vol. I, No.7, July 1989. [Koenig, 1989b] . Exception Handling for C++, Proceedings off the "C++ at Work" Conference, Nov. 1989. [Koenig, 1990] . Exception Handling for C++ (revised), Proceedings offthe USENIX C+ + Conference, Apr. 1990. Also, Journal of Object Oriented Programming, Vol. 3, No.2, July/Aug. 1990, pp. 16-33. [Krogdahl, 1984] Krogdahl, Stein. An Efficient Implementation of Simula Classes with Multiple PreJixing, Research Report No. 83, June 1984, University of Oslo, Institute of lnformatics. [Lenkov, 1989] Lenkov, Dmitry. C++ Standardization Proposal, #X3J11/89-016. [Linton, 1987] Linton, Mark A., and Calder, Paul R. The Design and Implementation of InterViews, Proceedings of the USENIX C++ Conference, Santa Fe, NM, Nov. 1987. [Liskov, 1987] Liskov, Barbara. Data Abstraction and Hierarchy, Addendum to Proceedings of OOPSLA '87, Oct. 1987. [Meyer, 1988] Meyer, Bertrand. Object-Oriented S~ftware Construction, Englewood Cliffs, N J: Prentice-Hall, 1988. [McCluskey, 1992] McClaskey, Glen. An Environmentjq~r Template lnstantiation, The C++ Report, Feb. 1992. [Nelson, 1991] Nelson, G., Ed. Systems Programming with Modula-3, Englewood Cliffs, NJ: Prentice-Hall, 1991. [Rose, 1984] Rose, Leonie V., and Stroustrup, Bjarne. Complex Arithmetic' in C++, Internal AT&T Bell Labs Technical Memorandum, Jan. 1984; reprinted in AT&T C++ Translator Release Notes, Nov. 1985.
C++ SESSION
753
BJARNE STROUSTRUP [Sakkinen, 1992] Sakkinen, Markku. A Critique e~fthe Inheritance Principles qfC++, USENIX Computer Systems, Vol. 5, No. 1, Winter 1992. [Sethi, 1980] Sethi, Ravi. A case study in specifying the semantics of a programming language, Seventh Annual ACM Symposium on Principles of Programming Languages, Jan. 1980, pp 117-130. [Shopiro, 1985] Shopiro, Jonathan E. Strings and listsfor C++, AT&T Bell Labs Internal Technical Memorandum, July 1985. [Shopiro, 1987] . Extending the C++ Task System for Real-Time Control, Proceedings of the USENIX C+ + Conference, Santa Fe, NM, Nov. 1987. [Snyder, 1986] Snyder, Alan. Encapsulation and Inheritance in Object-Oriented Programming Languages, Proceedings of OOPSLA '86, Sept. 1986. [Stepanov, 1994] Stepanov, Alexander, and Lee, Meng. The Standard Template Library, HP Labs Technical Report HPL-94-34 (R. 1), Aug. 1994. [Stroustrup, 1978] Stroustrup, Bjarne. On Unifying Module Interfaces, ACM Operating Systems Review, Vol. 12, No.l, Jan. 1978, pp 90--98.. [Stroustrup, 1979a] . Communication and Control in Distributed Computer Systems, Ph.D. thesis, Cambridge University, 1979. [Stroustrup,1979b] . An Inter-Module Communication System for a Distributed Computer System, Proceedings of the I st International Conference on Distributed Computing Systems, Oct. 1979, pp 412--418. [Stroustrup, 1980a] . C~ses: An Abstract Data Type Facilityfi~r the C Language, Bell Laboratories Computer Science Technical Report CSTR-84, Apr. 1980, also SIGPLANNotices, Jan. 1982. [Stroustmp, 1980b] . A Set of C Classes for Co-routine Style Programming, Bell Laboratories Computer Science Technical Report CSTR-90, Nov. 1980. [Stroustrup, 1981a] . Long Return: A technique for Improving The Efficiency of Inter-Module Communication, Software Practice and Experience, Jan. 1981, pp. 131-143. [Stroustrup, 198 lb] . Extensions of the C Language Type Concept Bell Labs Internal Memorandum, Jan. 1981. [Stroustrup, 1982] . Adding Classes to C: An Exercise in Language Evolution, Bell Laboratories Computer Science internal document, Apr. 1982, Software Practice & Experience, Vol. 13, 1983, pp. 139-161. [Stroustrup, 1984a] . The C++ Reference Manual AT&T Bell Labs Computer Science Technical Report No. 108, Jan. 1984. (Written in the summer of 1983). Revised version Nov. 1984. [Stroustrup, 1984b] . Data Abstraction in C, Bell Labs Technical Journal, Vol. 63, No. 8, Oct. 1984, pp 1701-1732. (Written in the summer of 1983) [Stroustmp, 1984c] . Operator Overloading in C++, Proceedings of the IFIP WG2.4 Conference on System Implementation Languages: Experience & Assessment, Sept. 1984. [Stroustrup, 1985] . An Extensible 1/O Facility for C++, Proceedings of the Summer 1985 USENIX ConJerence, June 1985, pp 57-70. [Stroustrup, 1986a] . An Overview of C++, ACM SIGPLANNotices, Special Issue, pp. 7-18. [Stroustrup, 1986b] Stroustrup, Bjarne, The C++ Programming Language, Reading, MA: Addison-Wesley, 1986. [Stroustmp, ! 986c] . What is Object-Oriented Programming? Proceedings offthe 14th ASU Conference, Aug. 1986, pp. 69..-84; revised version in Proceedings of the ECOOP '87, May 1987, Springer Verlag Lecture Notes in Computer Science, Vol. 276, pp. 51-70; revised version in IEEESqftware Magazine, May 1988, pp 10-20. [Stroustrup, 1987a] . Multiple Inheritance for C++, Proceedings of the EUUG Spring Conference, May 1987; also, USENIX Computer Systems, Vol. 2, No. 4, Fall 1989. [Stroustrup, 1987b] Stroustrup, Bjarne, and Shopiro, Jonathan. A Set of C classes for Co-Routine Style Programming, Proceedings USENIX C+ + Conference, Santa Fe, Nov. 1987, pp. 417--439. [Stroustrup, 1987c] Stroustrup, Bjarne. The Evolution of C++: 1985-1987, Proceedings of the USENIX C+ + Conference, Santa Fe, Nov. 1987, pp. 1-22. [Stroustrup, 1988a] . Type-safe Linkage for C++, USENIX Computer Systems, Vol.1, No. 4, Fall 1988. [Stroustrup, 1988b] . Parameterized Types for C++, Proceedings of the USENIX C++ Conference, Denver, Oct. 1988, pp. 1-18; also, USENIX Computer Systems, Vol. 2, No. 1, Winter 1989. [Stroustrup, 1989a] . Standardizing C++, The C+ + Report, Vol. 1, No.l, Jan. 1989. [Stroustrup, 1989b] . The Evolution of C++: 1985-1989, USENIX Computer Systems, Vol. 2, No. 3, Summer 1989. Revised version of [Stroustrup, 1987c]. [Stroustrup, 1990] . On Language Wars, Hotline on Object-Oriented Technology, Vol. 1, No. 3, Jan. 1990. [Stroustrup, 1991] . The C++ Programming Language, Second edition, Reading, MA: Addison-Wesley, 1991. [Stroustrup, 1992a] Stroustrup, Bjarne, and Lenkov. Dmitri, Run-time Type Identification for C++, The C++ Relu~rt, Mar. 1992. [Stroustrup, 1992b] Stroustrup, Bjarne. How to Write a C++ Language Extension Proposal, The C++ Report, May 1992.
754
CHAPTER XV
TRANSCRIPT OF C++ PRESENTATION
[Stroustrup, 1994] . . . The Design and Evolution (~ C+ +, Reading, MA: Addison-Wesley, 1994. [Taft, 1992] Taft, S. Tucker. Ada 9X: A Technical Summary, Communications of the ACM, Nov. 1992. [Tiemann, 1987] Tiemann, Michael. Wrappers, Proceedings of the USENIX C++ Conference, Santa Fe, Nov. 1987. [Waldo, 1991] Waldo, Jim. Controversy:The Case for Multiple Inheritancein C++, USENIX Computer SystetrLv, Vol.4, No. 2, Spring 1991. [Wirth, 1982] Wirth, Niklaus. Programming in Modula-2, New York: Springer-Verlag,1982.
TRANSCRIPT OF PRESENTATION BJARNE STROUSTRUP: First, I want to thank the Committee for suggesting I should write up the history of C++ and encouraging me to do so. This has led to a large paper, and consequently I ' m not going to try to explain what is in that paper. You can read it if you like. Instead, I'll make some comments about why C++ is the way it is, and how it came to be rather than what it is. I think it is rather fitting that I am the last speaker in this seminar on languages. C++ is the youngest language presented, and it is also very nice and fitting and a bit of an honor to follow Dennis. I don't know if its surprising or not, but basically I agree with a lot of what he said, including some of his more radical statements. I have written programs in four out of the five little languages that he has presented. The missing one for me is Bliss. My favorite happens to be the A L G O L 68, where I used the A L G O L 6 8 C m b u t C is by no means bad--and I'll get back to that. There has been a question going through this Conference: "Was it fun?" It was fun at times. You could see that for most of the speakers here, it wasn't just fun. One day, while I was feeling glum, a friend of mine said, "You know how you recognize the people who are out in front?" I said, "No." (And he said:) "By the arrows in their backs." A lot of the speakers here seemed defensive and maybe a little bit sad. I think I know why.--but I don't actually think we have anything to apologize for. And now, I'll start with what I actually planned to say. (SLIDE l) This is a brief overview. I ' m sticking to chronological order because that's always easier. This is basically the stages of C++. The pre-history: then a language called "C with Classes" which I designed and which was used at Bell Labs and elsewhere for some time; then C++, as it was originally introduced, and then C++ going through some intermediate stages to its current stage--plus the standardization that is still going on, And if I am not timed out, maybe a little about the future. (SLIDE 2) I think the most important aspect of a language is its designer's view of what the problem is. What are you trying to do? I very much doubt I would have designed a language just for the fun of designing a language. This may be the wrong place to say so, but maybe not. I think people that
Overview: 1977: 1979:
Simula and BCPL C with Classes
1984: 1989:
C++ 2.0 1989--91: templates and exceptions 1989--: 1993-:
standardization looking ahead
SLIDE 1
C++ SESSION
• A language is someone's response to
a set of problems at a given time • The problems and our understanding of solutions change over time • A language lives and grows
SLIDE 2
755
BJARNE STROUSTRUP
design a language, a general purpose language, if they set out to do so, must be mad. This is a field where the success rate is about zero, and where the amount of trouble over the years descending on a designer is enormous. I had a problem, and I set out to solve it. The solution to a problem, especially when it is successful, leads to different sets of problems. It leads to an evolution of the problem, which leads to an evolution of your understanding of what the problem is, and what the possible solutions are, which again leads to new languages, or new dialects, or to new versions. By the way, please notice the word "grow." I had not read Fred Brooks' slides when I wrote that. It is one of my favorite words for the way designs, in general, and languages, in particular, evolve. (SLIDE 3) The problem that I had to face is best explained in terms of a simulator I was writing in Cambridge. I was studying distributed systems, working with the capability architecture oftbe CAP computer, and trying to find ways of distributing functionality in an operating system and in an operating system kernel; figuring out how machine architecture (which was my old field) could support operating system architectures; studying communication, synchronization, fire walls, that kind of stuff nothing to do with language. And I was having a hard time. I had a hard time thinking about it; I had a hard time expressing the few thoughts I had about it. One day in the "grad pad"--that is the place in Cambridge where the Computer Science graduate students and professors tend to have lunch--4 was sitting moaning about this and especially bemoaning the fact that I didn't have access to the language, Simula, which I had briefly used in Aarhus a few years before. A guy sitting at the next table, I had no idea who he was at the time--and I still don't know--said, "You want Simula? I paid £ 10,000 for an implementation of it, and it doesn't run. If you can get it to run, you can have it." I got it, but never found out what the problem was. I guess he fed it something that wasn't Simula source code. [laughter.] This led to the most pleasant experience in programming that I ever had. The features of Simula were just splendid. The class concept helped me think, helped me to organize my programs. It helped me compose the programs out of the bits and pieces I wrote. I really loved it. There was a problem, though. When I started to run real examples, I was soaking up the University's mainframe at an astounding rate. I think I could have--in a day or two--soaked up my whole department's monthly budget. So I had to find a solution here. I could get Simula to run faster, but didn't think that was plausible, as the guys who wrote Simula were very smart. I could port Simula to a faster machine, except that we didn't have one. I could port Simula to a less used machine, which we did have, except that I couldn't, since Simula's implementation was proprietary and not portable. I could refrain from using the features of Simula that cost me too much. No, I couldn't, because those features were completely integral to the language--run-time checking, run-time typing, garbage collection, all kinds of good stuff that I could not afford and I, in fact, didn't need. But because of the way the language was put together, I couldn't help using it. Could I call external routines to do the work for me, to speed up critical parts the way that people from a slow language might call a FORTRAN routine? No, I could not; that Simula implementation was a closed system. I could leave Cambridge without a Ph.D., but that seemed an unfortunate thing to have to do. I could try to find somebody who could give me an IBM mainframe for myself. That didn't seem likely either. I could wait for people to invent high performance work stations, but that would have meant waiting for about eight years. Nobody would pay my salary waiting for that, so, instead, I rewrote the simulator in BCPL. That was very, very unpleasant. I lost about half of my hair in the process. [laughter.] My wife still comments on the nightmares I had while debugging that program. BCPL makes C look like a very high level language. But--it ran like the clappers, and it could be ported to a machine that was so poorly supported that the physicists and the astronomers didn't dare follow me. It lacked co-routines, which were absolutely essential for my simulator, so we just put them in--it took hardly
756
CHAPTER XV
TRANSCRIPT OF C++ PRESENTATION
C with Classes--why C? The problem (prehistory): the best systems programming language available:
Simula and BCPL • program organization
• flexible, efficient, portable
• run-time efficiency
• available, known
• availability/portability • inter-operability
SLIDE
3
• 2nd order flaws not cdtical but: improve static type checking
SLIDE 4
any time. For that reason, I can take a slight bit of credit for Martin Richards' addition of co-routines to BCPL. Finally, from BCPL you can easily use code written in other languages--like the CAP operating system written in ALGOL 68; that was important. So, I came away from Cambridge with a Ph.D., and a rather fierce determination never to get myself into that kind of mess again. (SLIDE 4) So, when I did get myself into that kind of mess again--when I was beginning at Bell Labs in Murray Hill--.4 backed off and started to build the proper tools for doing this. The proper tool is something that gives me the ability to organize my program, as in Simula, and helps me to design like I would in Simula, but running as fast and with as open a connection to other systems as BCPL. I looked around and chose C. The reason I chose C was rather simple. Now people might think that it was because it was AT&T's language, or because I had to, or some other such thing. That was not the idea at the time. I considered C the best language available for what I wanted to do. I needed to do some systems programming, I needed access to low-level features, I needed efficiency, flexibility, portability, and, later on when I had users, it was absolutely critical that part of the language was known, so that I wouldn't have to teach people how to write a for-loop. I was quite aware of a lot of second-order flaws in C. I am among the ones who think that the C declarator syntax is an experiment that failed. The concept is right, but the non-linear notation is awful. However, I didn't think such issues were all that important. The only thing that I felt obliged to do was to improve the static type checking. I had come to appreciate it from Simula and I am not a programmer of the caliber of say, Ken Thompson, who simply doesn't make the kind of mistakes caught by static type checking. I do make those mistakes, so I need the checking. Here we see a couple of the continuing threads in C++ development. If I don't have to invent something new, I don't. If I feel I must, I do. In this case, static type checking has been improving over the years in C++. It is now becoming possible to write a completely safe program in a well-defined subset of C++. If you don't want to do that, you can break the rules, which is one of the ways you keep the system open. (SLIDE 5) The other half of C++ is basically the Simula ancestry, the classes. And the answer to "why classes?" is strictly "to help me think, to help me design and organize my programs." The fundamental notion and is that you find your concepts in your application, map them into your language as classes. The view is clearly one of classes as a key design aid as opposed to other views where classes are primarily implementation details. I was also very keen on static type checking. I
C++ SESSION
757
BJARNE STROUSTRUP
C with Classes
C w i g Classes
• why Classes?
• work & work environment:
• program organization
• a bit of everything (simulation impor-
• mapping of concepts
tant)
• a class is a type - static checking
• emphasis on individual projects
• (not primarily =re-use")
• emphasis on work useful to others • helpful and encouraging colleagues • freedom from deadlines, commercialism, fads
SLIDE
5
SLIDE
6
appreciated the compiler helping me find the bugs in my program sooner rather than later. The explicit static structure helps me read my programs after the event; it helps me trust my code; it helps me reason about the program. The word "reuse" is one that I have some trouble even understanding. If something can be used and it's general, then it will be used by many. That happens when you have a good concept well represented, well documented, and managed. You're not reusing one of those, you're just using it. The notion that object-oriented programming is for reuse, is to my mind incidental. I am interested in concepts that allow me to reason, think, and express myself clearly, efficiently, etc., and from that comes the good uses. That is the distinction. (SLIDE 6) In which environment did this kind of work get done, and why is that environment important? A programming language is somebody's solution to a problem. Solutions depend on environments, and what you can do depends on the environment. My working environment included a bit of everything. It is hard to think of a kind of work that is not going on in Bell Labs, and a very large subset of that was done by friends and colleagues that I could talk to. Users were absolutely essential for the growth of C++. I had solutions; they got refined when people told me they weren't quite good enough. The selection of problems to deal with was very influenced by people who were walking into my office and telling me that I had been a "bonehead" again. The most important work actually was simulation at the time. Bell Labs did not support me because I was writing a programming language; they supported me because I--and people I cooperated with--wrote really nice simulators faster than anybody else around. The first program written in C with Classes was a library; something to support concurrency for simulation of things like network traffic, board layouts in CPU design, things like that. It was very important for me; this was what gave me my funding. There never was a C++ project--which, on at least three occasions, managers found out when they tried to cancel it. [laughter.] C++, like so many other languages, worked through the early years. There was no sheltered childhood. My environment had a strong emphasis on individual projects. The people in the research center that I'm in are, more or less by choice, anarchists. Since AT&T is a large organization, they have another computer science research center where everybody works in teams, the way the philosophy currently says you have to work. The emphasis on work that was useful to others--and not just sitting around doing things because they were beautiful to you--was strong and very helpful. My colleagues were very helpful, very friendly and encouraging. There was none of that stuff of hoarding good ideas for your next paper. If you had a good idea you barged into somebody's 758
CHAPTER XV
TRANSCRIPT OF C++ PRESENTATION
office and argued with them about it a bit. As a matter of fact, large parts of C++ were designed by me deciding that something was a problem, and going into somebody's office and not leaving until we have made progress on a solution--lots of really solid cooperation. And then there is a really nice freedom from deadlines--since there wasn't any project, nobody could tell me when it should finish. They could just judge the progress in what good things my users were saying about it. There was no commercialism, because there was a law saying AT&T couldn't sell software anyway. And there was also a blessed protection from academic and other fads, so that you could actually concentrate on solving problems. Now, C with Classes was sort of successful; it was a medium success. I had put a lot of emphasis on facilities that would help people get their work done. One of the things that I observed, is that it is much easier to get technical work done than to do anything that requires fundamental changes in the organization, or in your way of thinking as a group---as opposed to individuals. C with Classes was not too successful at that. It allowed you to get medium improvements with medium efforts. It did not allow you to get really large improvements if you were willing to put in a large effort. In some sense, it wasn't a quantum j u m p - - t h e least jump that would get you to the next stable level. Furthermore, the user community was not, and couldn't become, large enough to support an infrastructure for C with Classes. Remember, this was not a company language, there was policy to for people to use C with Classes, there was no guaranteed user group, there was no guaranteed financing. So I had a choice. I could can the project, and leave my users in a lurch, or I could go on, getting myself into a lot of extra work. Since I didn't feel like leaving my users in a lurch, I developed, from C with Classes, a very similar but more powerful language--and a more consistent language---called C++. There is a third alternative, which has, I think, caused a lot of languages to die at this stage. That is, go commercial, use some advertising, use some hype, and get some more users. That way, you can get them to pay for your mortgage, and get on that way. It did not occur to me. I ' m glad. (SLIDE 7) The design of C++ was guided by some rules of thumb. People really like talking about principles--but that sounds so pretentious. The first rule of the game, is that C++ is a language, and not a complete system. This differs from a lot of modern programming languages and systems, but remember that my users were scattered over more application areas and more hardware platforms than most individuals can imagine--including me. There were users on Cray supercomputers, and there were users programming "gadgets," talking refrigerators, fuel injectors, switching stuff. It was important to disassociate the C++ language from its environment, because most people had an environment and they were pretty happy with it. What you don't use, you don't pay for. This is a rather strict rule, known as "the zero overhead rule," and that's quite important. Lots of people have known a system written in a bit of C, and a bit of something else. Mostly, they wake up one morning and find that the whole system is in C. I was rather determined that this would not happen to C++; that is, you should not have to choose between the flexibility and the efficiency of C, and whatever else I could offer. If you don't use a C++ feature, you don't ask for it. C++ must be useful n o w . I ' m serving my users. I ' m not serving the future, and I ' m not in the business of writing academic papers. So C++ has to work on the current machines, not just on the machines that people might get in five years. I did most of my development on a PDP 11/70 and then on a VAX. Those were pretty good machines for the day compared to what the average user had. I wrote some nice simulations using seven hundred tasks (my C++ notion of processes) on the 11/70--which was pretty good for the time, I think. C++ had to address problems now, for users now, with the education level of understanding, and on current machines. Don't try and design the world's best programming language. Nobody will ever agree on what that is anyway. C++ SESSION
759
BJARNE STROUSTRUP
C++ design rules of thumb (general "pnnciples"): • C++ is a language, not a complete system • what you don't use you don't pay for (zero-overhead rule) • C++ must be useful NOW (current machines, programmers, and problems)
C++ design rules of thumb (language "principles"): • use traditional (dumb) linkers • no gratuitous incompatibilities with C (source and linkage) • no implicit violations of the type system • same support for user-defined and built-in types
• don't get involved in a sterile quest for perfection SLIDE
7
SLIDE 8
(SLIDE 8) Some of these principles actually have something to do with programming languages directly, though most do not. I was trying rather hard to put constraints on the solution, rather than saying what the solution was. One rule is that I had to use traditional dumb linkers. Otherwise, I would have spent my whole life porting code and wanting to be portable. To match C's portability led to a lot of decisions, and this was one of them. In fact, we have evidence of one of the early C++ compilers being ported to a new machine architecture--by people that had never written a C++ program before--in four hours. My ideal was a week, and I overshot that target. No gratuitous incompatibilities with C, neither in source nor in linkage--that was important. We have had some really interesting discussions with the word "gratuitous" here. The areas where incompatibilities are not gratuitous, usually has to do with type safety and the type system. You will find that ANSI C is largely a subset of C++, except for a few cases where it allows type violations that C++ was not willing to live with. The one technical principle was that the support for built-in type and user-defined types should be the same. I actually over-shot that target a bit, because there is now slightly better support for user-defined types than built-in types. On the scale you saw before, between dogmatic and pragmatic/empirical emphasis in design, C++ is definitely on the pragmatic and empirical side. I do not think that means unprincipled. When I studied history and philosophy, I definitely preferred somebody like Hume to Decartes or even Kant, even though Kant was clearly smarter. It is just the way I think, and it fits better with my world view. A lot of the work goes into looking at what the language is being used for. What else couldthe language be used for? What is the biggest problem? Fix it. This goes on at many levels, like the little-language level, where you look at individual language features. For example, what's the problem with pointers? Well, too many of them are dangling. What tools do you have for solving them? Well, ALGOL 68 has references. Should we add references to C++? Well it might be a good idea; references support operator overloading also. But what was the problem when I wrote programs in ALGOL 68? Well, 80 percent of my real bugs using ALGOL 68 were problems related to confusion between assignment through a reference and re-assignment of a reference. For that reason, C++ has references, but you cannot reassign a reference after its initialization. People think that's a limitation; I think it protects me from one of my worst sources of bugs. (SLIDE 9) So what is C++? Well, this slide shows an explanation. Once upon a time, I was asked to give an executive summary to a very exalted being at Bell Labs. Naturally, being a young technical guy, I didn't know what an executive summary was, so I said, "What is it?" "Well," came the answer,
760
CHAPTER XV
TRANSCRIPT OF C++ PRESENTATION How, Why, and Where did C++ use grow: C-i-+
* no advertising, marketing, support => low price • encourage self-sufficiency among users
• is a better C • supports data abstraction • supports object-oriented programming
• portability • powerfuVexpressive compared with C, Pascal, etc.
• fast, compact, and cheap compared to everything else - woddwide (email, netnews)
• industry and academia • most important: technology-oriented US industry SLIDE
9
SLIDE
10
"an executive summary is something that fits on half a sheet of paper, using very large print." [laughter.] So, this is the executive summary of C++. It is meant to be a better C, under very strict rules. Anything you can do in C, you can do in C++. Anything reasonable, you can do in exactly the same way. You don't have any extra overhead, and there are some notational conveniences and things to increase safety. But in that sense, it is a better C. Next, C++ supports data abstraction. I want to be able to organize my program by saying, "Here's my concept, here's my type. The mapping between the two is straightforward and effective." I want to be able to have matrices. I want to be able to have vectors. I want to be able to have switches, lines, whatever exists in the application area. I want to be able to multiply an array with a vector without any problems. The next level, the object-oriented programming level, is usually for practical reasons associated with the notion of inheritance. I see object-oriented programming as going one step beyond data abstraction, by allowing us to represent hierarchical relationships between concepts. Again, the notion is strictly that if there is some order in your concepts, you may be able to represent that ordering in your classes through inheritance. Not all organizations fit into this, but so what! The hierarchical ones, or rather the lattice-form ones, can be represented directly and they're very useful. (SLIDE 10) So, why did it work? As someone said, you have to be lucky, and also you have to work hard, and you have to listen a lot. The low price certainly was important. C++ was made available to a lot of users, without anybody trying to make a million from it. This was the resultnnot so much of a desire to get usersnbut of a wish to serve existing users well. We had no advertising, no marketing, and offered no support. Therefore, we had to encourage self-sufficiency among the users. We had to have portability. When you go through these concepts a couple of times, iteratively, and in any order you care to, a low price results unless somebody gets greedy. Users were interested in C++ because compared to C, and Pascal, and such, it was more expressive--you could say more. Usually, you could say more in fewer lines of code and in a clearer way. You could express your concepts more directly--and have them more directly checked--than if you had to go to pointers and bytes and such things. Compared to anything else, C++ was compact, fast, and cheap. That helps! It also was flexible; it fit into more environments with less trouble than just about anything else. The spread was world-wide from the beginning. Very soon after the development of C with Classes started, people started using it throughout the U.S. and various places in Europe. The feedback I got from those places was very important. A lot of the support and distribution, in the old days, was done
C++ SESSION
761
BJARNE STROUSTRUP
Availability (technical): Compilers (=more than 1,000,000 sold'): • AT&T, Oregon (TauMetric), GNU, Zortech (Symantec), Bodand, Micro-
soft, JPI, IBM, DEC, Metaware, Watcom, ... Environments (dozens): • ParcPlace, Centertins, HP, Lucid .... Libraries (many dozens): • USL, Interviews, GNU, M++, DBMS interfaces ....
SLIDE 11
Availability (social): Conferences • Usenix, Commercial (SIGS, BU), ECUG .... Training/Education (dozens): • commercial, university, ... Books (100+) • introductory, general, design, environment specific, library specific, application specific .... Journals/Bulletin boards/Netnews
SLIDE 12
using e-mail. It was important that both industry and academia were involved, because you get very different views of what the world is, and what the world is supposed to be, and what the problems are from the various angles. Europe and the U.S. are not the same, and they are not the same as Japan and Australia. Academia is not the same as academia, and industry is not the same as industry--if you consider examples from different places. The spread of C++ use was very important for the development of C++. Of course, there was a focus, which was the technology-oriented U.S. industry. It had the kind of problems I understood best, and I think that is why C++ was used there. (SLIDE 11) This has led to a notion of availability. It is hard to serve your users, if they can't understand what you are doing, or if they can't use it. For that reason, we have encouraged people to go build C++ compilers and tools--"encouraged" simply means talking to people, it doesn't mean government policy or AT&T corporate policy. This fits very well, though. AT&T is the biggest civilian user of software projects in the U.S., so anything that will increase the state-of-art and give better tools, better compilers, better languages, and better ways of designing things, is good for AT&T. Lots of people have joined in this vision. There was an initial intent to make the C++ language distinct from environments, but of course, some people really want environments--and that's fine--if you're doing the kind of work where you can use an extended environment, you should have one. The only constraint I can see is that code should be able to come from the simplest environment and come into an advanced software development environment. And once you have built something in the software development environment, you have to be able to export it out again. I do not mind my airplanes being built in a large hanger, as long as I do not have to carry the hanger with me when I try to fly. We have similar ideas about libraries; that is, C++ does not demand large run-time libraries--support libraries--you can write programs in C++ using very primitive libraries. That's important if you are trying to program a gadget of sorts. On the other hand, you do not want to write, say, windows code in C++ without support libraries. It is simply too unpleasant, so the libraries are coming. In my opinion, you do not want to write yet another dialog box, and you don't have to. (SLIDE 12) There is a distinct social aspect to real reusability--people sometimes have really nice language wars over individual features or what language manual is the cleanest. I think that is a very parochial view. It is the totality of what is available to allow you to get the whole job done that's important. And therefore, the social issues matter. USENIX has some conferences. There is a lot of commercialism now, which is sometimes useful. There are users groups. I want to point out that none of these were started by, or supported by, AT&T. There is training and education--lots of it. There are
762
CHAPTER XV
TRANSCRIPT OF C++ PRESENTATION
Standardization: ANSI X3J16: Dec 1989, ISO SC22-WG21: June 1991 • Initiative: IBM, DEC, HP Why?
Standardization: why not?
* language still evolving • premature
• many implementations • single company control unacceptable • rule requiring =under standardization" • forum for debate and dissemination of
ideas SLIDE
13
SLIDE 14
more books than people could possibly dream of, even in their worst nightmares. There are some journals and all kinds of media for exchange. I would like to point out that I sometimes see, on the net, references to the C++ marketing juggernaut, or the AT&T marketing juggernaut. This is highly amusing---especially when this juggernaut is supposed to be running over things like Ada. AT&T once had a marketing budget for C++. It was a total of $3,000 for the first three years of C++'s life. What do you do with $3,000, when you want to market a language? Well, our marketing department's idea was to send a plain white letter to all UNIX system managers, telling them that C++ existed, without explaining what it was. I doubt that had any effect at all. That left us with $2,000. When I heard about it, I got them to give a reception for the first C++ users conference. That was the formal marketing of C++ during the first three or four years. (SLIDE 13) Next, we are going to standardization. People want a standard. Why? Because there are lots of implementations and because nobody could tolerate single company control. I mean, they may trust me, but would they trust my management? My immediate management they could trust, but AT&T is a very big place. You need something more national and international. Several companies said that they were allowed to use something provided it was under standardization--that is, you didn't have to finish but there had to be a standards group. For that reason, we absolutely had to have it. And I found, for social reasons, that standards groups are very useful for discussion and debate, and for exchange of information. Before that, everything went through my mailbox, which was rather unpleasant--but necessary--when organizations that are not allowed to talk to each other, need to exchange information. (SLIDE 14) There is a quick "Why not?" I mean, the language is evolving and standardization could easily be very premature. That is just sad if that happens. There have been a few cases where things have been standardized before being implemented. That is sad, and not in the general spirit of C++. (SLIDE 15) And here comes the last one. I said I might be timed out. Basically, the main challenge is to stay coherent with so many factors, so many people, so many organizations involved. The ultimate purpose of C++ is to allow you to program to a higher level of abstraction, and to organize your programs better. A lot of people do not understand that. A lot of people do not want to understand that, and with a growth rate like C++'s, we can't teach teachers fast enough to get it across. Education is very important. There are also lots of technical challenges that I'll skip, because they are of secondary importance relative to the other. [applause.]
C++ SESSION
763
TRANSCRIPT OF QUESTION AND ANSWER SESSION
Current Challenges: Thanks
Staying coherent Education
Dennis Ritchie, Kristen Nygaard
Technical
Brian Kernighan, Andrew Koenig,
• Language • Environments
Doug Mcllroy, Jonathan Shopiro
• Libraries
• Design
SLIDE 15
SLIDE 16
(SLIDE 16) I really appreciate having worked on the languages designed by Dennis Ritchie and Kristen Nygaard; they are real gentlemen, and that is a very important personal feature. I could mention lots of people, but the four people there are the ones that have given me the most trouble and, therefore, contributed the most to the language. [applause.] T R A N S C R I P T OF QUESTION AND A N S W E R SESSION
JEAN ICHBIAH: One of the weakest properties of SIMULA was the confusion between classes used as a unit of knowledge, for example in simulation, and classes used as abstracted data type for which you instantiate objects. Why did you choose to perpetuate this confusion or unification of the two concepts?
STROUSTRUP: I use, and I think of, classes strictly as a type, not as a module or name space. For that reason, I think that C++ has the ability to create types and hierarchies of types, but no further. If you want to partition your system in separate name spaces, if you want to define a group of related classes, which I think is the other aspect of it, you shouldn't use classes. We very often don't use classes. We have a very inferior, in my opinion, concept in terms of the C source file. We are moving towards a separate name space concept in the standards process. But, I think that if there is a confusion, either I have missed it or it is in uses of classes, some of which I will classify as misuses. I ' m not 100 percent sure I answered the question. GUY STEELE (Thinking Machines): The paper notes that the exception handling, in C++, was inspired by ML. But ML uses the word RAISE and not THROW. I was curious to know whether the words CATCH and THROWstem from their use in Mac LISP in 1972, and if so--this is the point of the question---by what path?
STROUSTRUP: The exception handling mechanism in C++ was designed, by me, with a fair bit of help by Andy Koenig. It was inspired to a large extent by CLU's mechanism, a little bit by Ada, and some look at what they did in Modula2t and ML for the use of types. The reason the name is not RAISE is that RAISE is a standard function in the C library. C reserves half of the names in the universe for its standard library and it doesn't have a name space concept. Basically, we played around with a lot of names for this idea, for saying "help me" or "get me out of here." I knew of the use of THROW and CATCH in LISP, because somebody had told me, not because I'd used them. I also think I knew
764
CHAPTER XV
TRANSCRIPT OF QUESTION AND ANSWER SESSION
whatever names had been used in just about any language with exceptions, and just were the ones I liked best.
THROW
and
CATCH
ADAM RIFKEN (Cal Tech): How do you feel about new languages being designed with C++ as their base, when C++ itself is still evolving and being standardized? STROUSTRUP: First of all, I think it is very stupid to fight the inevitable too hard. Second, when people actually are working hard and doing a decent job, which they sometimes do, you should thank them. You should think it is an honor that people are willing to take your work and build on it. There are several dozen extensions of C++, mostly to do with things like concurrency and constraints, and some of them are very nice. BRIAN MEEK (Kings College, London): There is a school of thought that there should be, not just no gratuitous incompatibilities between C and C++, but no incompatibilities at all. Could you have designed a satisfactory C++ language with that constraint? Have you any general views on incompatibilities between similar languages?
STROUSTRUP: The first answer is no. Much stronger static type checking--in the end approximating total safety, is the ideal. C allows, for historical reasons, some really major unsafety in the function calling mechanism, and in the array concept, and a few other places. Those, I have absolutely no intention of living with. We are now approaching the state where people who want "safe C++" can have it. Don't use casts, don't use arrays--that's it, as far as I remember. Now you can't not use arrays because you need some form of arrays, but we have a standard template that gives you the array concept, that you can use, and that is type safe and checked. Basically, I could not have designed a C++ that would serve the purpose I wanted it to serve, while staying fully compatible with C. But it is much more compatible than you believe. And if you write ANSI C, and if you do it with your strictest compiler options set (so that prototypes are required), you are much closer than you think. In general, I believe in evolution, which implies that you have to move forward, you have to respect where you come from, but sometimes things have to be broken.
MARK DAY (MIT): What was the interaction, if any, between your work and that of Jacob Katz Nelson on enhanced C? Why do you think that C++ made it out of sell Labs, while EC didn't? STROUSTRUP: There was hardly any interaction. He read my papers, I'm not sure he understood them. I read his papers, I ' m not sure I understood them. We had some nice talks, because he is a nice guy. His stuff was deeply macro-based, which I didn't like. Mine wasn't, which he didn't like. I think that I worked a bit harder and had a better language. Editor's note: the following questions were answered after the conference by the author. STAVROS MACRAKIS (OSF Research Institute): Why didn't you start with Simula 67 and make it faster & better, rather than start with C and make it better? (Perhaps by eliminating some things?)
STROUSTRUP: First of all, a practical reason: Simula's implementations were proprietary, so that I would either have had to do an implementation from scratch or get involved in negotiations about large sums of money. Neither sounded attractive, and neither would get me closer to my aim of getting real work done on distributed systems design for years. C had the low-level features necessary for systems work, the raw efficiency, and the ability to interface to other code that Simula lacked. Initially, I could add to that without even touching the internals of a C compiler. To gain the nice features from a Simula dialect, I would have to subtract from a Simula compiler in places very close to the most fundamental aspects of the implementation.
C++ SESSION
765
TRANSCRIPT OF QUESTION AND ANSWER SESSION
I wasn't even sure that could be done. In retrospect, sticking very close to C has brought a fair bit of frustration, but also the key benefits I was looking for. I don't see another way that would have allowed me to deliver greater benefits to more people. SCOTT GUTHREY (Schlumberger): The name, and marketing of C++, invite us to regard it as a superset of C. Nevertheless there are many incompatibilities between C and C++. In retrospect, to avoid confusing people, and facilitate clearer design, should C++ have been named "P"?
STROUSTRUP: There aren't that many incompatibilities between C++ and ANSI C. I think ANSI C is close enough to being a subset of C++ for the name to be accurate. Quite a few languages have been designed to be "a better C," and most have been called "D" for obvious reasons. I have not heard of any of those succeeding, but the name was taken. The other "obvious" name "P"---coming from the next letter after C in the sequence BCPL is too cute, and would have caused confusion with Pascal derivatives. Finally, I simply like the name "C++." It--correctly I think--emphasizes the evolutionary nature of the change, and leaves the origins of C++ in C for all to see. The other alternative "++C" would have driven producers of indexes, dictionaries, and the like, mad. If the real question was "Could you have designed a cleaner language if you had broken C compatibility in fundamental ways?" the answer is Yes, I could, but the result would have been of little practical use--and I wouldn't have been here today. DOUG ROSS (SofTech/MIT): In the context of C++ as O O - - M a y h e you could ask Bjarne to answer. The point is that call-by-loc hidden yields 00 all along--since 1962. STROUSTRUP: The basic mechanisms for implementing OO have been available for a very long time--at least since the invention of the subroutine that could be called through a value in memory. However, OO isn't just, and maybe not even primarily, an issue of implementation technique. It is a way of looking at design, a way of structuring programs. The way I see it, Dahl and Nygaard developed a new way of writing programs and designed Simula as a notation for that. We can go back and see that the key techniques for implementing Simula, C++, etc., were available for years before anyone talked about OO, but that doesn't mean that programmers using indirect calls of assembler routines were doing OO. A few did--4f I understand some of the early operating system designs correctly-.--but they didn't get the message to the rest of us, and I suspect most didn't generalize from simple programming tricks to a full-blown design approach the way the Norwegians did. The key OO breakthrough was in design, in the way of thinking about programming, rather than in programming language implementation techniques. Programmers, in general, need to become more ambitious and more critical about the structure of their code. S. KELLY-BOOTLE (UNIX Review): Can a non-constant member function be called via a temporary un-named object?
STROUSTRUP: Yes, if and only if, the temporary is not constant. For example: class Stan{ public : void Kelley ( ); void Bootle() const; private : // ... ) ;
766
CHAPTER XV
TRANSCRIPT OF QUESTION AND ANSWER SESSION
Stan f ( ); const Stan g(); void g() { f( ->Kelley(); g( ->Bootle(); g( ->Kelley(); g( ->Bootle();
/ / ok / / ok // error: non-const function // applied to const object // ok
}
WENDY McKNI1r'r (Univ. of Delaware): Thinking of C++ in terms of object-oriented programming, was there a specific reasoning behind the absence of a default base class? STROUSTRUP: Yes. I think a universal base class encourages sloppy design and programming. In particular, it tempts people to seriously overuse run-time type identification where static type checking is appropriate and leads to superior designs. In addition, the absence makes it trivial to avoid space and time overhead. For many fundamental classes, such as complex numbers and time of day, it is particularly important to avoid space overheard, because space overhead can prevent layout compatibility with languages such as C and FORTRAN. HERBERT KLAEREN (Univ. of Tubingen): It seems that C++ is to C about the same as LaTex is to Tex. As in that case, it is easy to blow the C++ intents by inappropriate manipulation on the underlying C level. Is there anything that can be done about that? STROUSTRUP: I strongly believe in making undesirable features redundant rather than outlawing them. Once redundant, you might consider banning them, but why bother. A better approach is style checkers. I actually think that the real problem with "unsafe" and "tricky" features is that many are used in libraries where they are (sometimes) appropriate so that they show up in non-expert users' code using those libraries. This makes it hard to, say, enforce a rule like "never use explicit type conversions" because a reasonable use might occur in an inline library function. I think the right approach in the long run is to provide programmers with good analysis tools, so that they can easily see what they--or their predecessors on a piece of code--have done. Today, few programmers have tools that allow them to simply and effectively examine a program for error-prone constructs and techniques. I don't think we will succeed before textbooks and foundation libraries set a good example. ANDY MIKEL (MCAD Computer Center): C++ to write NEXTStep?
Why did NEXT consciously choose Objective C over
STROUSTRUP: Did they? The story I heard was that when they first heard of C++, they had already started using Objective C and they asked the PPI salesman to explain C++ to them. Since he didn't make C++ sound attractive, they proceeded with Objective C. By the time they looked at C++ again, they already had a significant amount of code and a design philosophy depending on Objective C's brand of run-time type checking. I have no way of verifying this story (heard about ten years ago), but it is interesting--though not productive--to consider what might have happened if C++ had been commercially available as early as Objective C, or even if I had had a chat with the NEXT guys early on.
C++ SESSION
767
TRANSCRIPTOF QUESTIONAND ANSWER SESSION
JOHN BIGBO'I'TE: Is "++" in danger of becoming as meaningless as "considered harmfull" ? STROUSTRUP: Possibly. Any adjective that becomes popular gets overused. I have even seen ++s as an integral part of the ad campaign of a major bank. RICHARD NANCE (Virrginla Tech): it relate to C++?
Are you familiar with a language called SIM++? Ifso, how does
STROUSTRUP: No. Sorry. I have heard the name, but I'm not doing much simulation these days and I don't keep track of all the C++ related simulation language and libraries. RONALDFISCItER(Consultant): Why do you have two reserved w o r d s - - s t r u c t c l a s s - - f o r the (semantically) same purpose? Why not simply stick with the word s t r u c t ?
and
STROUSTRUP: I considered it infeasible to teach the fundamental difference between programming using data structures, and data abstraction without a syntactic "handle" for people to latch on to. I also happen to like the word c l a s s in this context, and its use is a tribute to Simula. S c o T t GUTHREY (Schlumberger): C changed very little after it went into use. C++ has changed and continues to change. Which of these language histories is to be preferred? STROUSTRUP: Ideally, a language springs perfectly formed from its designer's head. In reality, this doesn't happen. C was designed for a relatively well-known problem domain supporting a relatively well-understood set of techniques. Consequently, C was almost adequate from the start and only a few improvements, corrections, and extensions were ever done. Dennis and others decided to live with C--warts and all--and the result has been some frustration, and enormous benefits from its stability. C++ followed a different path. I think it had to. C++ was attacking a set of problems that was less well understood, and aimed to serve a larger set of techniques directly. I don't think I had any chance of getting C++ as right at the first try as C was. Consequently, I had to use a strategy of implementing and using the ideas I trusted most, getting feedback, then extending the language based on the experience gained. The result has been a much better language than I could have designed initially, but at a loss of stability. Also, I think that many people underestimate the length of C's "gestation period." ANSI C is notably different from the C first used in 1972. Similarly, people underestimate the stability of the core facilities of C++. BOB ROSIN (ESPI): What was/is your working relationship with Dennis? What did you learn from him? What do you think he learned from you?
STROUSTRUP: We are colleagues in the same research center, but we are not close collaborators. By the time I arrived, Dennis's interests had drifted from languages (if that ever was a primary interest) into operating systems. I drifted the other way; at least for a while. In the early days of C with Classes, I discussed quite a few language-technical details with Dennis and I think he helped me avoid making some facilities narrow and paternalistic. I think that had effects beyond the features we actually discussed. Importantly, he and the rest of the people in the computer science research center emphasized an approach to work based on the solution of practical problems with moderate means, as opposed to chasing "perfection" without concern for resources and the opinions of the system builders "in the trenches." Dennis can also teach by simple example. In the 16 years I have known him, I have never heard him say an unkind word about any programming language. That absence of fanaticism can be refreshing.
768
CHAPTER XV
BIOGRAPHY OF BJARNE STROUSTRUP
BIOGRAPHY OF BJARNE STROUSTRUP Bjarne Stroustrup, Cand.Scient. (Mathematics and Computer Science), 1975, University of Aarhus, Denmark; Ph.D. (Computer Science) 1979, Cambridge University, England. Bjarne Stroustrup is the designer and original implementor of C++ and the author of The C+ + Programming Language (1 st edition 1985, 2nd edition 1991) and The Design and Evolution of C+ +. His research interests include distributed systems, operating systems, simulation, design, and programming. Dr. Stroustrup is the head of Bell Labs' Large-scale Programming Research department and an AT&T Bell Laboratories Fellow. He is actively involved in the ANSI/ISO standardization of C++ as the author of the base document and the chairman of the working group for extensions. Recipient of the 1993 ACM Grace Murray Hopper award, he is also an ACM fellow. His non-research interests include general history, light literature, and music. He lives in Watchung, New Jersey, with his wife, daughter, and son.
C++ SESSION
769
XVI Forum on the History of Computing (April 20, 1993)
ForumChair: Robert F. Rosin
During its deliberations, the HOPL-II Program Committee concluded that, although the work of many computer scientists becomes part of the history of computing, very few computer scientists understand the history of computing or are involved in crafting that history. Assuming that a significant number of skilled computer scientists would attend HOPL-II, the Committee decided to take advantage of this opportunity to sensitize a portion of that community to issues in the history of computing and to entice some of them to become involved. Therefore, the HOPL-II Program Committee authorized a l/2-day "Forum on the History of Computing" that was held in conjunction with, and immediately prior to, HOPL-II. The Forum program had four segments. • The opening lecture introduced attendees to the work and challenges that abound in the history of computing. • Each of five overview presentations discussed briefly one specific activity of which Forum attendees might be, at best, only vaguely aware. • Four parallel group discussions gave attendees information needed to become personally involved in the craft of the history of computing. • The concluding panel was a prelude to HOPL-II itself and addressed issues about computer exhibits. Conference attendees who did not participate in the earlier Forum sessions were welcome to attend. The complete program, including the names and affiliations of speakers, discussion leaders, and panelists, can be found elsewhere in this book. The original idea for the Forum grew out of e-mail discussion among HOPL-II Program Committee Members Brent Hailpern, Robert E Rosin, and Jean E. Sammet. A subset of the Program Committee, consisting of Barbara Ryder, Michael S. Mahoney, Rosin, and Sammet, drafted the proposal for what has become the Forum. The details of the Forum program were managed by the Forum Committee consisting of Thomas J. Bergin, Michael Marcotty (consultant), Thomas J. Marlowe, Jr. (Seton Hall University), Michael S. Mahoney, and Jean E. Sammet. Robert F. Rosin, Forum Chair Enhanced Service Providers, Inc.
77/1
MICHAEL S. MAHONEY
ISSUES IN THE HISTORY OF COMPUTING
Michael S. Mahoney Program in the History of Science Princeton University Princeton, New Jersey 08544 e-mail: mike @pucc.princeton.edu
COMPILING THE RECORD It should be easy to do the history of computing. After all, computing began less than 50 years ago, and we have crowds of eye witnesses, mountains of documents, storerooms of original equipment, and the computer itself to process all the information those sources generate. What's so hard? What are we missing? Well, the record is not quite as complete as it looks. As the Patent Office discovered during the '80s, much of the art of programming is undocumented, as is much of the software created during the '50s and since. The software itself is becoming inaccessible, as the machines on which it ran disappear through obsolescence. Critical decisions lie buried in corporate records--either literally so, or as trees are in a forest. Many eye witnesses have testified, but few have been cross-examined. Much of the current record exists only on-91ine and, even if archived, will consist of needles in huge haystacks. But these are minor matters, to be discussed in the context of broader issues. The major problem is that we have lots of answers but very few questions, lots of stories but no history, lots of things to do but no sense of how to do them or in what order. Simply put, we don't yet know what the history of computing is really about. A glance at the literature makes that clear. We still know more about the calculating devices that preceded the electronic digital computer--however tenuously related to it--than we do about the machines that shaped the industry. We have hardly begun to determine how the industry got started and how it developed. We still find it easier to talk about hardware than about software, despite the shared sense that much of the history of computing is somehow wrapped up in the famous inversion curve of hardware/software costs from 1960 to 1990. We still cast about for historical precedents and comparisons, unsure of where computing fits into the society that created it and has been shaped by it. That uncertainty is reflected in the literature and activities of the History of Science Society and the Society for the History of Technology, where the computer as the foremost scientific instrument, and computing as the salient technology, of the late twentieth century are all but invisible, not only in themselves but in the perspective they shed on earlier science and technology. The presentations in the second session today are addressed to the various materials that constitute the primary sources for the history of computing: artifacts, archives and documents, first-person experience both written and oral. The business of HOPL-II itself is to enrich the sources for programming languages. As I noted at the outset, we seem to have no shortage of such materials. Indeed, as someone originally trained as a medievalist, I feel sometimes like a beggar at a banquet. I hardly know where to begin, and my appetite runs ahead of my digestion. It's a real problem, and not only for the consumer. To continue the metaphor, at some point the table can't hold all the dishes, and the pantry begins to overflow. We have to pick and choose what we keep in store and what we set out. But by what criteria? Conflagration has done a lot of the selecting for medievalists. Historians of computing--indeed of modern science and technology in general--have to establish principles of a less random character.
772
CHAPTER XVl
PAPER: ISSUES IN THE HISTORY OF COMPUTING
Once collecting and preserving become selective (I mean consciously selective; they are always unconsciously selective), they anticipate the history they are supposed to generate and, thus, create that history. That is, they are historical activities, reflecting what we think is important about the present through what we preserve of it for the future. What we think is important about the present depends on who we are, where we stand--in the profound sense of the clich6, where we are coming from. Everyone at HOPI-II is doing history simply by being here and ratifying through our presence that the languages we are talking about and what we say about their origin and development are historically significant. There's an important point here. Let me bring it out by means of something that seems to be of consuming interest to computer people, namely "firsts." Who was first to ... ? What was the first ... ? Now, that can be a tricky question because it can come down to a matter of meaning rather than of order in time. Nothing is entirely new, especially in matters of scientific technology. Innovation is incremental, and what already exists determines to a large extent what can be created. So collecting and recording "firsts" means deciding what makes them first, and that decision can often lead to retrospective judgments, where the first X had always been known as a Y. Let me give an example prompted by a distinguished computer scientist's use of history. I want to return to the topic at the end of this paper, so the example is more detailed than it need be for the present point. In a review of business data processing in 1962, Grace Hopper, then at Remington Rand UNIVAC Division, sought to place the computer in the mainstream of American industrial development by emphasizing a characteristic sequence of venture--enterprise--mass production--adventure. The model suggested that computing was entering a period of standardization before embarking in daring new directions. The first two stages are tentative and experimental, but As the enterprise settles down and becomes practical mass production, the number of models diminishes while the number made of each model increases. This is the process, so familiar to all of us, by which we have developed our refrigerators, our automobiles, and our television sets. Sometimes we forget that in each case the practical production is followed by the new adventure. Sometimes we forget that the Model T Ford was followed by one with a gear shift [Hopper 1962]. That Model T, an icon of American industrialism, deserves a closer look. Shifting-gear transmissions antedated the Model T. But the softness of the steel then available and the difficulty of meshing gears meant the constant risk of stripping them. Concerned above all with reliability and durability, Ford consciously avoided shifting by going back to the planetary transmission, in which the gears remain enmeshed at all times and are brought to bear on the drive shaft in varying combinations by bands actuated by foot pedals. Although the Model A indeed had a gear shift, made reliable by Ford's use of new alloys, it is perhaps more important historically that the planetary transmission had just begun its life. For later, with the foot pedals replaced by a hydraulic torque converter, it served as the heart of the automatic transmissions that came to dominate automotive design in the 1950s. Now, how does one unravel the "firsts" in all this? Would we think to keep a Model T around for the history of automatic transmissions? What then of the first operating system, or the first database? Does the equivalent of a planetary transmission lurk in them too?
DOCUMENTING PRACTICE In deciding what to keep, it may help to understand that historians look at sources not only for what is new and unusual but also for what is so common as to be taken for granted. In terms of information theory, they arc equally interested in the redundancy that assures the integrity of the message. For much of common practice is undocumented, and yet it shapes what is documented. The deep effect
FORUM ON THE HISTORY OF COMPUTING
773
MICHAEL S. MAHONEY
of innovation is to change what we take for granted. This is what Thomas S. Kuhn had in mind with the notion of "paradigm shift," the central concept of his immensely influential book, The Structure of Scientific Revolutions [Kuhn 1962]. He later replaced "paradigm" with "disciplinary matrix," but the meaning remained the same: in learning to do science, we must learn much more than is in the textbook. In principle, knowing that F = ma is all you need to know to solve problems in classical mechanics. In practice, you need to know a lot more than that. There are tricks to applying F = ma to particular mechanical systems, and you learn how to do it by actually solving problems under the eye of someone who already has the skill. It is that skill, a body of techniques, and the habits of thought that go with them, that constitutes effective knowledge of a subject. Because all practitioners of a subject share that skill, they do not talk about it. They take it for granted. Yet it informs their thinking at the most basic level, setting the terms in which they think about problems and shaping even the most innovative solutions. Thus it plays a major role in deciding about "firsts." Over time, the body of established practice changes, as new ideas and techniques become common knowledge and older skills become obsolete. Again, one doesn't talk much about it; "everyone knows that!" Yet, it is fragile. It is hard to keep, much harder than machines or programs. To gain access to undocumented practice, historians are learning to do what engineers often take for granted: to read the products of practice in critical ways. In The Soul of a New Machine Tracy Kidder relates how Tom West of Data General bluffed his way into a company that was installing a new VAX and spent the morning pulling boards and examining them. Looking into the VAX, West had imagined he saw a diagram of DEC's corporate organization. He felt that VAX was too complicated. He did not like, for instance, the system by which various parts of the machine communicated with each other; for his taste, there wa.s too much protocol involved. He decided that VAX embodied flaws in DEC's corporate organization. The machine expressed that phenomenally successful company's cautious, bureaucratic style. Was this true? West said it didn't matter, it was a useful theory [Kidder 1981, p. 26]. Historically, it is indeed a useful theory. Technology is not a literate enterprise; not because inventors and engineers are illiterate, but because they think in things rather than words.[Ferguson 1979; Wallace 1978] Henry Ford summed it up in his characteristically terse style: There is an immense amount to be leamed simply by tinkering with things. It is not possible to learn from books how everything is made--and a real mechanic ought to know how nearly everything is made. Machines are to a mechanic what books are to a writer. He gets ideas from them, and if he has any brains he will apply those ideas [Ford 1924, pp. 23-24]. In short, the record of technology lies more in the artifacts than in the written records, and historians have to learn to read the artifacts as critically as they do the records. It is perhaps the best way of meeting Dick Hamming's challenge to "... know what they thought when they did it" [Hamming 1980]. For that, historians need, first and foremost, the artifacts. That is where museums play a central role in historical research. But historians also need help in learning how to read those artifacts. That means getting the people who designed and built them to talk about the knowledge and know-how that seldom gets into words. As I use the word "artifact" here, I suspect that most of the audience has a machine in mind. But computing has another sort of artifact, one that seems unique until one thinks about it carefully. I mean a program: A high-level language compiler, an operating system, an application. It has been the common lament of management that programs are built by tinkering and that little of their design gets captured in written form, at least in a written form that would make it possible to determine how they work or why they work as they do rather than in other readily imaginable ways. Moreover, what
"774
CHAPTER XVI
PAPER: ISSUES IN THE HISTORY OF COMPUTING
programs do and what the documentation says they do are not always the same thing. Here, in a very real sense, the historian inherits the problems of software maintenance: the farther the program lies from its creators, the more difficult it is to discern its architecture and the design decisions that inform it. Yet software can be read. In Alan Kay's talk, we'll hear a counterpart to Tom West's reading of the VAX boards: Head whirling, I found my desk. On it was a pile of tapes and listings, and a note: "This is the ALGOL for the 1108. It doesn't work. Please make it work." The latest graduate student gets the latest dirty task. The documentation was incomprehensible. Supposedly, this was the Case-Western Reserve 1107 ALGOL--but it had been doctored to make a language called Simula; the documentation read like Norwegian transliterated into English, which in fact was what it was. There were uses of words like activity and process that didn't seem to coincide with normal English usage. Finally, another graduate student and I unrolled the listing 80 feet down the hall and crawled over it yelling discoveries to each other. The weirdest part was the storage allocator, which did not obey a stack discipline as was usual for ALGOL. A few days later, that provided the clue. What Simula was allocating were structures very much like instances of Sketchpad [Kay 1993, p. 71(5)]. In the draft version, Kay added as a gloss to his tale that such explorations of machine code were common among programmers: "Batch processing and debugging facilities were so bad back then that one would avoid running code at any cost. 'Desk-checking' listings was the way of life." Yet, it is not the sort of thing one finds in manuals or textbooks. Gerald M. Weinberg gives an example of how it is done for various versions of FORTRAN in Chapter I of The Psychology of Computer Programming [Weinberg 1971], and Brian Kernighan and P.J. Plauger's Elements of Programming Style [Kernighan 1974] can be read as a guide to the art of reading programs. But the real trick is to capture the know-how, the tricks of the trade that everyone knew and no one wrote down when "desk-checking" was the norm. We need to think about how best to do that, because for historians without access to the machines on which programs ran or without the resources to have emulators written, desk-checking could again become a way of life. At the very least, it will demand fluency in the languages themselves.
THE IMPORTANCE OF CONTEXT An emphasis on practice is also an emphasis on context. In focusing on what was new about computing in general and about various aspects of it in particular, one can lose sight of other elements of tradition (in the literal sense of "handing over") and of training that determined what was taken for granted as the basis for innovation. From the outset, computing was what Derek J. DeS. Price, a historian and sociologist of science, termed "big science" [Price 1963]. It relied on government funding, an expanding economy, an advanced industrial base, and a network of scientific and technical institutions. Over the past 40oodd years it has achieved autonomy as a scientific and technical enterprise, but it did so on the basis of older, established institutions, from which the first generations of computer people brought their craft practices, their habits of thought, their paradigms, and their precedents, all of which shaped the new industry and discipline they were creating. As in many other things, Alan Pedis offered a productive metaphor for thinking about context. At the first HOPL he reflected on the fate of A L G O L 58 in competition with FORTRAN, noting that: The acceptance of FORTRAN within SHARE and the accompanying incredible growth in its use, in competition with a better linguistic vehicle, illustrated how factors other than language determine the choice
FORUM ON THE HISTORY OF COMPUTING
775
MICHAEL S. MAHONEY
of programming languages of users. Programs are not abstractions. They are articles of commerce in a society of users and machines. The choice of programming language is but one parameter governing the vitality of the commerce [Pedis 1981, 1983]. A comment by Kristen Nygaard during discussion led Pedis to expand the point: I think that my use of the world 'commerce' has been, at least in that case, misinterpreted. My use of the word 'commerce' was not meant to imply that it was IBM's self-interest which determined that FORTRAN would grow and that ALGOL would wither in the United States. It certainly was the case that IBM, being the dominant computer peddler in the United States, determined to a great extent--that the language FORTRAN would flourish, but IBM has peddled other languages which haven't flourished. FORTRAN flourished because it fitted well into the needs of the customers, and that defined the commerce. SHARE is the commerce. The publication of books on FORTRAN is the commerce. The fact that every computer manufacturer feels that if he makes a machine, FORTRAN must be on it is part of the commerce. In Europe, ALGOL is part of a commerce that is not supported by any single manufacturer, but there is an atmosphere in Europe of participation in ALGOL, dissemination of ALGOL, education in ALGOL, which makes it a commercial activity. That's what I mean by 'commerce'--the interplay and communication of programs and ideas about them. That's what makes commerce, and that's what makes languages survive [Perlis 1981, pp. 164-5]. One can extend Perlis' metaphor ever further, shifting the focus from survival to design. Henry Ford insisted that the Model T embodied a theory of business. He had designed it with a market in mind. The same may be said of any product, including programs. An industrial artifact is designed with a consumer in mind and hence reflects the designers' view of the consumer. The market--another term for "commerce"--is thus, not a limiting condition, an external constraint on the product, but rather a defining condition built into the product. "What does this mean?" can often best be answered by determining for whom it was meant. For both hardware and software, that may not be an easy thing to do. Stated goals may not have coincided with unstated, the people involved may not have agreed, and the computing world has a talent for justifying itself in retrospect. As Pedis suggested, "commerce" in a general sense extends beyond industry and business to encompass science, technology, and the institutions that support them. The notion emphasizes the role of institutions in directing the technical development of computing and, to some extent, conversely. In Creating the Computer, Kenneth Flamm has revealed the patterns of government support that gave the computer and computing their initial shape [Flamm 1988]. The recent historical report by Arthur Norberg and Judy O'Neill on DARPA's Information Processing Techniques Office explores the interplay between defense needs and academic interests in the development of time-sharing, packetswitched networks, interactive computer graphics, and artificial intelligence [Norberg 1992]. What is particulady striking is the mobility of personnel between government offices and university laboratories, making it difficult at times to discern just who is designing what for whom. The study of the NSF's program in computer science, now being completed by William Aspray and colleagues, opens similar insights into the reciprocal influences between programs of research and sources of funding. In IBM's Early Computers, Charles Bashe and his coauthors show how commercialization of a cutting-edge technology forced the corporation, until then used to self-reliance in research and development, to open new links with the larger technical community and to play an active role in it, as evidenced by the IBM Journal of Research and Development, first published in 1957 [Bashe 1986]. Closer to my own home, the development of computer science at Princeton has been characterized by the easy flow of researchers between the University and Bell Labs, and that same pattern has surely occurred elsewhere. Taken broadly, then, the notion of "commerce" directs the historian's attention to the determinative role of the marketplace in modern scientific technologies, such as computing. It is one thing to build
776
CHAPTER XVI
PAPER: ISSUES IN THE HISTORY OF COMPUTING
number-crunchers one-by-one on contract to the government for its laboratories; it is another to develop a product line for a market that must be created and fostered. The explosive growth of computing since the early '50s depended on the ability of the industry to persuade corporations and, later, individuals that they needed computers, or at least could benefit from them. That meant not only designing machines but also, and increasingly, uses for them in the form of computer systems and applications. Henry Ford put Americans on wheels in part by showing them how they could use an automobile. Similarly, the computing industry has had to create uses for the computer. The development of computing as a technology has depended, at least in part, on its success in doing so, and hence, understanding the directions the technology has taken, even in its most scientific form, means finding the market for which it was being designed, or the market it was trying to design. "Market" here includes people and people's skills. Earlier, I said a program seems "unique until one thinks about it." One may think about a program as essentially the design of a machine through the organization of a system of production. Other people thought about the organization of production and the management of organizations, and in many cases creating a market for computing meant creating a market for the skills of organizing systems of production. In examining the contexts of computing, historians would do well to explore, for example, the close relations between computing and industrial engineering and management. The Harvard Business Review introduced its readers to the computer and operations research in back-to-back issues in 1953 [HBR 1953a, 1953b], and the two technologies have had a symbiotic relationship ever since. Both had something to sell, both had to create a market for their products and they needed each other to create it. Computers and computing have evolved in a variety of overlapping contexts, shaping those contexts while being shaped by them. The history of computing thus lies in the intersections of the histories of many technologies, to which the historian of computing must remain attuned. The notion of "computing as commerce" brings out the significance of techniques of reading artifacts, combined with the more usual techniques of textual criticism. To repeat: from the outset, computing has had to sell itself, whether to the government as big machines for scientific computing essential to national defense, to business and industry as systems vital to management, or to universities as scientific and technological disciplines deserving of academic standing and even departmental autonomy. The computing community very quickly learned the skills of advertising and became adept at marketing what it often could not yet produce. The result is that computing has had an air of wishful thinking about it. Much of its literature interweaves performance with promise, what is in practice with what can be in principle. It is a literature filled with announcements of revolutions subsequently (and quietly) canceled owing to unforeseen difficulties. In the case of confessed visionaries like Ted Nelson, the sources carry their own caveat. But in many instances computer marketers and management consultants, not to mention software engineers, were no less visionary, if perhaps less frank about it. What sources claimed or suggested could be done did not always correspond to what in fact could be done at the time. An industry trying to expand its market, engineers and scientists trying to establish new disciplines and attract research and development funding, new organizations seeking professional standing did not talk a lot about failures. The artifacts, both hard and soft, are the firmest basis for separating fact from fiction technically, provided one learns to read them critically. Doing so is essential to understanding the claims made for computers and programs, and why they were believed. DOING HISTORY Recognizing the elements of continuity that link computing to its own past, and to the past of the industries and institutions that have fostered it, brings out most clearly the relation of history and FORUM ON THE HISTORY OF COMPUTING
777
MICHAEL S. MAHONEY
current practice. History is built into current practice; the more profound the influence, the less conscious we are of its presence. It is not a matter of learning the "lessons of history" or of exploring "what history can teach us," as if these were alternatives or complements to practice. We are products of our history or, rather, our histories; we do what we do for historical reasons. Bjarne Stroustrup notes in his history of C++, We never have a clean slate. Whatever new we do we must also make it possible for people to make a transition from old tools and ideas to new [Stroustrup 1993, p. 294(47)]. History serves its purpose best, not when it suggests what we should be doing, but when it makes clear what we are doing, or at least clarifies what we think we are doing. On matters that count, we invoke precedents, which is to say we invoke history. We should be conscious of doing that, and we should be concerned both that we have the right history and that we have the history right. Earlier, to make a point about "firsts," I cited Grace Hopper's evocation of the Model T. You may well have felt that my critique focused on a matter of detail that is irrelevant to her main point. Perhaps; but consider the historical basis of that main point. She was taking the automobile industry as a precedent for business data processing and by extension for computing as a whole. It was not the first time she had done so. The precedent she invoked in her famous Education of a Computer [Hopper 1952], was also taken from the automotive production line, and it has persisted as a precedent down to the present: look at the cover of IEEE Software for June 1984, where the Ford assembly line around 1940 serves as backdrop to Peter Wegner's four-part article on industrial-strength software [Wegner 1984]; then look at the Ford assembly line of the '50s on the jacket of Greg Jones's Software Engineering in 1990. These are not isolated examples, nor are they mere window dressing. They reflect a way of thinking about software engineering, and there is history built into it, as there is in the notion of engineering itself; witness Mary Shaw's comparison of software engineering with other engineering disciplines [Shaw 1990]. There were other ways to think about writing programs for computers. If people thought, and even continue to think, predominantly about automobiles or engineering, it is for historical reasons. In commenting on a draft of this paper, Bob Rosin noted at this point that "automobiles and engineering are (outdated?) paradigms that are largely unfamiliar to younger computer people. Many kids, who grew up hacking on Ataris and PCs and Macs, didn't hack automobiles and rarely studied engineering." The implied objection touches my argument only where I shift from history to criticism of current practice. Historically, at least through the '80s, software engineering has taken shape with reference to the assembly line and to industrial engineering as models. Those models are built into the current enterprise. One only has to read Doug Mcllroy's "On Mass-Produced Software Components," presented to the first NATO Software Engineering Conference in 1968, to see where the conceptual roots of object-oriented programming lie [Mcllroy 1976]. Ignorance of the automobile and engineering, or at least of their role in the formation of software engineering, will not free a new generation of software developers from the continuing influence of the older models built into the practice they learn and the tools they use. Rather, it means that practitioners will lack critical understanding of the foundations on which they are building. Moreover, it is not just software engineers who talk about the automobile. How often have we heard one personal computer or another described as the "Model T of computing?" What would it mean to take the claim seriously? What would a personal computer have to achieve to emulate the Model T as a technological achievement and a social and economic force? Would it be useful for historians of computing to take the Model T as a historical precedent? If not, what is a useful historical precedent? Are there perhaps several precedents?
778
CHAPTER XVl
PAPER: ISSUES IN THE HISTORY OF COMPUTING
AN AGENDA FOR HISTORY OF COMPUTING So, maybe the history of computing is not so easy, but what's to be done? Let me conclude by setting out an agenda, for which I claim neither completeness nor objectivity. For one thing, it reflects my own bias toward software rather than hardware. We need to know more than we do about how the computing industry began. What was the role of the government? How did both older companies and start-ups identify a potential market and how did the market determine their products? What place did research and development occupy in the companies' organization, and how did companies identify and recruit staffs with the requisite skills? We need to know about the origins and development of programming as an occupation, a profession, a scientific and technological activity. A proper history here might help in separating reality from wishful thinking about the nature of programming and programmers. In particular, it will be necessary for historians of computing to embed their subject into the larger contexts of the history of technology and the history of the professions as a whole. For example, in The System of Professions, Andrew Abbott argues that It is the history of jurisdictional disputes that is the real, the determining history of the professions. Jurisdictional claims furnish the impetus and the pattern to organization developments.... Professions develop when jurisdictions become vacant, which may happen because they are newly created or because an earlier tenant has left them altogether or lost its firm grip on them [Abbott 1988, pp. 2-3]. That is, the professions as a system represent a form of musical chairs among occupations except that chairs and participants may be added as well as eliminated. Not all occupations are involved. Competition takes place among those that on the basis of abstract knowledge "can redefine [their] problems and tasks, defend them from interlopers, and seize new problems." Although craft occupations control techniques, they do not generally seek to extend their aegis. One only has to page through the various computing journals of the late '50s and early '60s to see conflicts over jurisdiction reflecting uncertain standing as a profession. Whose machine was it? Soon after the founding of the ACM, it turned its focus from hardware to software, ceding computing machinery to the IRE. Not long thereafter, representatives of business computing complained about the ACM's bias toward scientific computing and computer science. Numerical analysts scoffed at "computerologists," inviting them to get back to the business at hand. One does not have to look hard to find complaints in other quarters that computing was being taken over by academics ignorant of the problems and methods of "real" programming. Similar tensions underlay discussions of a succession of ACM committees charged with setting the curriculum for computer science. Following from that is the need for histories of the main communities of computing: numerical analysis, data processing, systems programming, computer science, artificial intelligence, graphics, and so on. When and how did the various specialties emerge, and how did each of them establish a separate identity as evidenced, say, by recognition as a SIG by the ACM or the IEEE, or by a distinct place in the computing curriculum? How has the balance of professional power shifted among these communities, and how has the shift been reflected in the technology? The software crisis proclaimed at the end of the '60s is still with us, despite the accelerated expansion of software engineering in the '70s and '80s. The origins and development of the problem and the response to it provides a rare opportunity to trace the history of a discipline shaping itself. It did not exist in 1969. Throughout the '70s and early '80s, keynote speakers and introductions to books repeatedly asked, "Are we there yet?" without making it entirely clear where "there" was. Today, software engineering has a SIG, its own Transactions, its own IEEE publication, an ACM approved curriculum, and a growing presence in undergraduate and graduate programs. One only has to compare
FORUM ON THE HISTORY OF COMPUTING
779
MICHAEL S. MAHONEY
Barry Boehm's famous article of 1972 [Boehm 1973], with reports about DoD software in any issue of Software Engineering Notes to doubt that the burgeoning of software engineering reflects its success in meeting the problems of producing reliable software on time, within budget, and to specifications. How, then, has the field grown so markedly in 20 years? Software takes many forms, and we have begun the history of very few of them, most notably programming languages and artificial intelligence. Still awaiting the historian's attention are operating systems, networks, databases, graphics, and embedded systems, not to mention the wealth and variety of microcomputer programs. This is HOPL-II; we still await HOS-I (operating systems), or any of a host of HOXs. SIGGRAPH undertook a few years ago to determine the milestones of the field, but there has been little or no work since then. In each of these areas, history will have to look well beyond the software itself to the fields that stimulated its development, supplied the substantive methods, and in turn incorporated computing into their own patterns of thinking. Finally, there remains the elusive character of the "Computer Revolution," first proclaimed by Edmund C. Berkeley, then editor of Computers and Automation back in 1962 and subsequently heralded by a long line of writers, both in and out of computing [Berkeley 1962]. Clearly something epochal has happened. Yet, as I pointed out several years ago in an article [Mahoney [ 988], it would be hard to demonstrate for the computer, in whatever form, as pervasive an impact on ordinary people's lives as Robert and Helen Lynd were able to document for the automobile, in their famous study of Muncie, Indiana in 1924 [Lynd ] 929]. But here I am, back at the automobile again. Maybe I've been spending too much time with computer people. REFERENCES
[Abbot, 1988]Abbott,Andrew,The System ~ifPr~tfe.~siott~:An Essay on the Division ~tfExpert Labor, Chicago: Universityof Chicago Press, 1988. [Bashe, 1986] Bashe, Charles, and Pugh, Emerson, IBMs Early Computers, Cambridge, MA: MIT Press, 1986. [Berkeley, 1962] Berkeley,Edmund C., The Computer Rewdution, Garden City, NY: Doubleday& Co., 1962. [Boehm, 1973] Boehm, Barry W., Software and its impact: A quantitative assessment, Datamation Vol. 19, May 1973, pp. 48-59. [Ferguson, 1979]Ferguson,EugeneS., The mind's eye: Nonverbalthoughtin technology,Science Vol. 197, 1979,pp. 827-836. [Flamm, 1988] Flamm, Kenneth, Creating the Computer: Government, Industry, and High Technology, Washington, D.C.: Brookings Institution, 1988. [Ford, 1924] Ford, Henry,My Life and Work, Garden City, NY: Doubleday, 1922. [Hamming, 1980] Hamming, Richard W., We would know what they thoughtwhen they did it, in N. Metropolis, J. Howlett, G. C. Rota eds., A History ~tfComputing in the Twentieth Century: A Collection of Essays. NY: AcademicPress, 1980, pp. 3-9 [HBR, 1953a]Herrmann,Cyril C., and Magee, John E, 'Operationsresearch'for management,Harvard Business Re" iew, Vol. 31, No. 4, 1953,pp. 100-12. [HBR, 1953b] First advertisementsfor IBM and Univacin Harvard Business Reviev4 Vol.31, No. 5--6, 1953. [Hopper, 1952] Hopper, Grace, The education of a computer, Proceedings of the Association for Computing Machinery Conference, Pittsburgh, May 1952;repr. with introductionby David Giles, Annals ttfthe History ttfComputing, Vol.9, No. 3•4, 1988, pp. 271-281. [Hopper, 1962] Hopper, Grace, Business data processing--a review, IFIP, Vol. 62, pp. 35-39. [Kay, 1993] Kay, Alan C., The early historyof Smalltalk, SIGPLAN Notices, Vol. 28, No. 3, March 1993,pp. 69-95. [Keraighan, 1974] Kernighan, Brian, and Plauger, P.J., The Eleraents RfProgramming Style, New York:McGraw-Hill, 1974; second ed., 1978 [Kidder, 1981] Kidder, Tracy, The Soul of a New Machine, Boston:Little, Brown, and Co., 198l [Kuhn, 1962] Kuhn, Thomas S., The Structure of Scientific Revolutions, Chicago: Universityof Chicago Press, 1962. [Lynd, i 929] Lynd,Robert S., and Lynd,Helen Merrell, Middletown: A Study in American Culture, New York:Harcourt,Brace & World, 1929;repr. 1956.
780
CHAPTER XVI
PAPER: ISSUES IN THE HISTORY OF COMPUTING
[Mahoney, 1988] Mahoney, Michael S., The history of computing in the history of technology, Annals of the History of Computing, Vol. 10, 1988, pp. 113-125. [McIIroy, 1976] Mcllroy, M. D., On mass-produced software components, in Software Engineering: Concepts and Techniques. Ptr~'eedings of the NATO Conferences, Peter Naur, Brian Randall, J. N. Buxton, Eds.,[Garmisch, 1968; Rome, 1969)]. New York: Petrocelli/Charter, 1976, pp. 88-95. [Norberg, 1992] Norberg, Arthur L., and O'Neill, Judy E., Promoting technological innovation: The Information Processing Techniques Office of Defen.ve Advanced Research Projects Agenc~y, a report W the Software and Intelligent System.~ Technology Office, DARPA. Minneapolis: The Charles Babbage Institute, 1992. [Perlis, 1981] Perils, Alan, The American side of the development of Algol, in History of Programming Languages, Richard L. Wexelblat, ed., New York: Academic Press, 1981. [Price, 1963] Price, Derek J. deSolla, Little Science, Big Science. New York: Columbia University Press, 1963. [Shaw, 1990] Shaw, Mary, Prospects for an engineering discipline of software, IEEE S~tfhcare Vol. 7, No. 6, Nov. 1990, pp. 15-24. [Stroustrup, 1993] Stroustrup, Bjarne, A history of C+ +: 1979-1991, SIGPILANNotices, Vol. 28, No. 3, Mar. 1993, pp. 271-97. [Wallace, 1978] Wallace, Anthony F. C., Thinking About Machinery, in The Growth of an American Village in the Early Industrial Revolution, Rockdale, N.Y.: Knopf, 1978), pp. 237ff. [Wegner, 1984] Wegner, Peter, Capital-intensive software technology, IEEE Software, Vol. l, No. 3, 1984, pp. 7-45. [Weinberg, 1971] Weinberg, Gerald M., The Psyclu~logy ¢~fComputer Programming, New York: Van Nostrand Reinhold Co., 1971.
FORUM ON THE HISTORY OF COMPUTING
781
BRUCE H. BRUEMMER
ARCHIVES
SPECIALIZING
IN T H E H I S T O R Y O F C O M P U T I N G
Bruce H. Bruemmer CharlesBabbage Institute 103 WalterLibrary University of Minnesota
Minneapolis,MN 55455 The following public institutions have a special interest in supporting and documenting the history of computing. A very brief description of each repository's interest in archival materials is noted. For further information, contact the repository directly or refer to one of the guides listed at the end of this section. Charles Babbage Institute 103 Walter Library 117 Pleasant St. SE University of Minnesota Minneapolis, MN 55455
612 624-5050, FAX 612 625-8054 contact: Bruce Bruemrner (
[email protected])
History of computing largely after 1935. Holds records of individuals, companies (Burroughs and Control Data), professional organizations and individuals. Also, computer literature, film, photographs, and oral history. Computer Museum 300 Congress Street Boston, MA 02210
617 426-2800 contact: Oliver Strimpel
Computer manuals, photographs, films, particularly those relating to artifact collection. Hagley Museum and Library PO Box 3630 Wilmington, DE 19807
302 658-2400 contact: Michael Nash
Computer industry, particularly around Delaware Valley. Holds Sperry Rand records. Library of Congress Manuscripts Division Washington, DC 20540
202 287-5387
Records of prominent individuals. Holds Hollerith, yon Neumann, and Vannevar Bush papers. National Archives and Records Administration Office of Records Administration Washington, DC 20408
202 523-3220 contact: James Moore
Records relating to data processing in the federal government. Smithsonian Institution. National Air and Space Museum. Space Science and Exploration Dept. Washington, DC
202 357-2828 contact: Paul Ceruzzi
Records relating to data processing for aerospace applications. 782
CHAPTER XVI
PAPER: ARCHIVES SPECIALIZING IN THE HISTORYOF COMPUTING
Smithsonian Institution, National Museum of American History Washington, DC 20560
202 357-3270 contact: John Fleckner
Records relating to computing in America. Holds Smithsonian/AFIPS oral history collection, Hopper papers, computer literature collection. Stanford University Libraries Department of Special Collections Stanford, CA 94305
415 723-4602 contact: Henry Lowood
Records relating to science and technology of the Silicon Valley area. Holds records of prominent individuals, businesses, and organizations. CORPORATIONS WITH ESTABLISHED HISTORICAL PROGRAMS Many companies have established their own archival and/or museum operations. Individuals holding records relating to these companies may wish to contact their archives or museum.
AT&T Archives PO Box 4647 Warren, NJ 07059
908 756-1586 contact: Bunny White
Apple Computer, Inc.
408 974-1503
Records Management 20525 Mariani Ave. MS 36R Cupertino, CA 95014
Digital Equipment Corp 146 Main St. MLO 3-4/'1"83 Maynard, MA 01754
Hewlett-Packard Co. HP Company Archives 3000 Hanover 20BR Paio Alto, CA 94304
International Business Machines Corp. IBM Archives Rt 100 Bldg. CSB Somers, NY 10589
MIT Lincoln Laboratories Room A082 244 Wood Street Lexington, MA 02173
FORUM ON THE HISTORYOF COMPUTING
508 952-3559 contact: Craig G. St. Clair
415 857-8537 contact: Karen Lewis
914 766-0612 contact: Robert Godfrey
617 981-7179 contact:Mary Murphy
783
BRUCE H. BRUEMMER
MITRE Corporation Corporate Archives MS K450 Burlington Road Bedford, MA 01730
Texas Instruments Corporate Archives, MS 233 PO Box 655474 Dallas, TX 75265
617 721-7854 contact: David Baldwin
214 995-4458 contact: Ann Westerlin
UNIVERSITY ARCHIVES WITH SIGNIFICANT HOLDINGS The following university archives have significant archival collections pertaining to the history of computing. Individuals seeking to donate historically valuable records that relate to the programs or research at specific academic institutions should contact the pertinent university or college archivist. Dartmouth College Harvard University Massachusetts Institute of Technology
Stanford University University of Illinois University of Pennsylvania
REFERRALS
American Institute of Physics
212 661-9404
Center for the History of Electrical Engineering IEEE Rutgers--The State University 39 Union St. New Brunswick, NJ 08903
contact: Joan Warnow
908 932-1066
Charles Babbage Institute 103 Walter Library University of Minnesota Minneapolis, MN 55455
contact: Andrew Goldstein (agoldstein @zodiac.rutgers.edu)
Center for the History of Physics 335 East 45th St. New York, NY 10017
612 624-5050 contact:Bruce Bruemmer (bruce@fsl .itdean.umn.edu)
Society of American Archivists 600 S. Federal Suite 504 Chicago, IL 60605 312 922-0140 contact: Debra Mills
NATIONAL ARCHIVAL GUIDES Bruce H. Bruemmer,Re,vources of the History of Computing: A Guide to U.S. and Canadian Records, Minneapolis:Charles BabbageInstitute, 1987. JamesW.Cortada,Ed.,Archives of Data-Processing History: A Guide to Major U.S. Collections, New York:Greenwood,1990.
784
CHAPTER XVl
PAPER:THE ROLE OF MUSEUMS IN COLLECTINGCOMPUTERS
THE ROLE OF MUSEUMS IN COLLECTING COMPUTERS
Gwen Bell
(with additional editing by Robert F. Rosin) The ComputerMuseum 300 CongressStreet Boston MA 02210
SEEING IS BELIEVING Pictures of a three-dimensional technological object, especially in its original context, are rich in clues about the use of that object. But the object itself, examined closely and from all directions--and in special cases, used or operated--provides an understanding like no other of that object and its technology. The original and primary purpose of museums of science and technology was for the preservation of artifacts. But many museum artifacts, by their nature, are rare and fragile, so traditionally they have been accessible to only a few professionals and interested people. Students and the public were seldom given the same opportunity, nor was material presented in such a way that they could understand it. However, in this century, with the widespread movement for universal education, those concepts changed. Museums were reinterpreted as broad-based educational institutions.
MUSEUM CHARTERS The mission of many museums reflects this historical evolution. Some museums remain only collecting institutions, others were started with the educational theme in mind and have no collections, and some combine these two. The Computer Museum is the third type, combining education and collections. Specifically, its mission is: 1. To educate and inspire all ages and levels of the public, through dynamic exhibitions and programs on the technology, applications, and impact of computers. 2. To preserve and celebrate the history and promote the understanding of computers worldwide. 3. To be an international resource for the history of computing.
COMPUTER COLLECTIONS Five national museums have computing collections: 'The Deutchcs Museum, Munich; The National Museum of Science and Technology, Ottawa; The Science Museum, London; 'The National Museum of American History of the Smithsonian Institution, Washington; and the National Air and Space Museum, also part of the Smithsonian. By definition, the major focus of their collections is national, although when they build exhibits, they seek examples of significant artifacts from beyond their borders. Several other museums have smaller computing collections; for example, a computer museum in Bozeman, MT and The Computer Museum of America in Orange County, CA. Other museums have a few computer objects. Several nonprofit research institutions have computer-related collections and museums that relate to their own history; for example, The Computer Museum at Livermore and the Los Alamos Museum.
FORUM ON THE HISTORYOF COMPUTING
785
GWEN BELL
Some universities maintain exhibits of locally developed computers such as the Mark I at Harvard, ENIAC at the University of Pennsylvania, components of the ABC at Iowa State University, representative parts of the various Manchester University computers, and parts of TX-2 at the MIT Museum. A few companies have corporate collections, and some maintain galleries open to the public. These include Cray Research, Digital Equipment Corporation, Fujitsu, IBM, Intel, and Wang Laboratories. IBM has an extensive collection, which they exhibit at the IBM Galleries at various times. Unisys has, for the most part, given its collection to museums and kept very little. Maintaining a corporate collection is governed by the corporation; they have no public contract to preserve their history. Budgets for these collections can be cut instantaneously, and, if no one is around to get the materials at the correct time, they are dumped.
CRITERIA FOR COLLECTING ARTIFACTS Collecting criteria is fundamentally the same for all institutions. These criteria are not always spelled out, but they represent the practice of many curators. In the larger museums, where computing is only one of the many collections,justification for each addition must [be made to an acquisition committee. The rationale is generally to show evidence that the object being acquired is a "first," is a unique artifact, or was the standard of its era. For example, the Smithsonian and the Computer Museum both have exhibits and collections on the UNIVAC I (a first) and the IBM 360 (a standard). I.
Firsts are identified as technologically innovative, for example, the first integrated circuit, the first transistorized computer, the first core memory. As the justification becomes finer grained and less clear, questions regarding the acquisitions grow; for example, the first 256K memory chip or the first two-button mouse.
2. Classics are the standard devices of any era as evidenced by widespread adoption and use. Examples include the IBM 360, PDP-S, and Apple II. Museums are particularly interested in examples of"classics," as they often want to exhibit a generic example to illustrate social and economic impacts. 3. Dinosaurs and dead ends help illustrate the point that technology does not advance in a straight line. Failed technologies often have important lessons for the future that are critical to helping future generations understand technical problems. Reasons for failure include technical, social, and economic problems. Examples include the IBM System 3, 90-column punched cards, the Dvorak keyboard, and 12-bit computers. In each case, the precise understanding of why the technology failed, its "story," is critical to any institution making a decision for acquisition. Often curators do not have the time to undertake this research, so it is up to the donor to make a strong case. 4. Icons are critical to collect. These are objects that are often not technologically interesting in and of themselves, but they evoke an era or a set of phenomena. Very few artifacts become icons, and when they do, everyone knows it. Examples include Archie Bunker's chair and, for the computer graphics community, "the teapot." 5. Other kinds of objects that are collected are: • A clone that reflects an important dimension that should not be lost. Although many clones are made, few should probably enter any permanent collection.
786
CHAPTER XVl
PAPER: THE ROLE OF MUSEUMS IN COLLECTING COMPUTERS
• A part of a series which, although unimportant in itself, relates to a collecting area of the institution. For example, all the machines designed by Seymour Cray or all the attempts at parallel structures. • An object that represents a particular country's development of computing. • An artifact that has an interesting feature. • An object that is the best representative that can be acquired under the circumstances. The Computer Museum also collects items specifically for particular exhibitions and for educational purposes. In the latter case, these are "spares" that can be shared with other institutions or used for teaching.
COLLECTIONS AT THE COMPUTER MUSEUM The Computer Museum is unique in that it is both nonprofit and international in scope. As outlined in the Museum's application for nonprofit status in 1981 and as carried out in practice, the collections of the Museum are guided by the taxonomy of computing as defined in Bell and Newell, Computer Structures: Readings and Examples (1972). The collection focuses on the material technology of computing hardware and associated documentation. The documents that are collected include manuals, books, photographs, films, videos, CDs, and ephemera such as buttons, models, and advertising materials. These documents lend unity to the artifact collection. Although the same criteria that apply to hardware artifacts also apply to these items, the accessioning process is generally less formal because such items are often less rare, can easily be copied, or suitable substitutes can be found. Figure 16.1 shows the integration of several of these collections. For the Amdahl 470/6, serial number 10002, the artifact is listed as item X436.84. Additional listings include a photograph, two manuals, and two sets of schematics. Further down the page is an entry for a videotape of a lecture by Gene Amdahl, item VT51.83 which mentions the 470.
THE USE OF THE MUSEUM'S COMPUTER COLLECTIONS As yet, the Computer Museum collection is not used for serious primary research. In many cases, this is because the inventors are themselves available. For the most part, the photographs are used for illustrations by the trade press and by authors of technical books. The manuals and artifacts are used by researchers investigating "prior art" to establish patent rights. The Museum staff uses all aspects of the collection in creating exhibits. For example, several artifacts were used to add richness and depth to the recent Tools and Toys exhibit.
RESPONSIBILITIES OF COLLECTING Problems and major costs begin after an item is acquired. Therefore, institutions take extreme care in selection for acquisition. If an entire collection is given to an institution with no strings attached, then, upon review, the institution may acquire some items, dispose of others in a variety of ways, and even "age" a few to see whether they should be acquired. Once acquired, an object is--and should be--difficult to get rid of. Deaccession has to be a well thought out process. When an object is accepted by a nonprofit institution, the donor rightly can claim
FORUM ON THE HISTORY OF COMPUTING
787
GWEN BELL
16.1 The ComputerMuseum--Sample Catalog Page. FIGURE
Amdahl Comz)uter Corporation Amdlahl 470
Computing Systems Physical Planning Manual #Gi004.0.04A (1981) 59[A342] Cable diagrams and Console Documentation schematics (1974) [A342] V/5, V6 Computing Systems, Illustrated Parts-Catalog (1980) [AB42] Computing System Machine Reference Manual #GI014.0-12A (1981) 35[A342] 470/V5-I Computing 26[A342]
S y s t e m M a c h i n e R e f e r e n c e Manual
470V/6 C o m p u t i n g
System
#G1012.0
01A
(1979)
1975 X436.84
S# 10002. Amdahl V/6, No.2, was initially installed at the U n i v e r s i t y of Michigan, Ann Arbor, in 1975. The first system was i n s t a l l e d at NASA. At M i c h i g a n it was u p g r a d e d to a V/6-II, a change in b u f f e r size. In 1979 the system was sold to A m e r i c a n C y a n a m i d in New Jersey, where it remained until August of 1984. Gift of Major Computer, Inc. Photograph: Dr. Gene Amdahl with a "mock up" of the Amdahl 470V/6 introduced in June 1975. [Amdahl, Gene] Computing System Machine Reference Manual 470V/6 & 470V/6-II #Mi047. 0-01A (1979) 2[A342] Inside the Amdahl 470V/6-II 5[A342] System BLCALDS, C-Unit, Buffer schematics [A98] System BLCALDS Unlabeled schematics [A342] Amdahl 580
Technical Executive
I n t r o d u c t i o n (1980) 25[A342] S u m m a r y (1980) 8[A342
a tax deduction for the value of that item, and the institution can lose its nonprofit status if it does not keep the item.
W H A T YOU CAN DO TO PRESERVE HISTORIC MATERIALS • If you see an important artifact, call a collecting institution immediately; don't wait one day.
788
•
If someone says, "I'm throwing this out," and you think it is an important object, get a stay of execution until you can speak with a collecting institution, and try to save it.
•
If an individual or a noncollecting corporation insists on keeping what appears to be an important item, make sure that it is clearly identified, arrange for its future donation to an institution, and, in the meantime, see that good care is taken of it.
•
If you think an object should be saved, make the case to preserve it as strongly as you can and with as much authority as you can muster.
CHAPTER XVl
PAPER: THE ANNALS OF THE HISTORY OF COMPUTING AND OTHER JOURNALS
THE ANNALS OF THE HISTORY OF COMPUTING AND OTHER JOURNALS
Bernard A. Galler EECS Department The University of Michigan Ann Arbor. MI 48109-2122
The history of computing is recorded in many places. The Annals of the History of Computing is the only journal dedicated to that purpose, and its origins and concerns occupy the bulk of this article. The closing section, including an extensive bibliography, surveys other publications where this history is also recorded. The Annals of the History of Computing was founded in 1978, and a number of lessons have been learned since then about publishing contemporary history. The field of computers and computing is very young and very dynamic. A journal which tries to record its history has unique opportunities, as the creators of the history are still on the scene. On the other hand, there are few disinterested observers around, and "history" can become very personal. Moreover, authors of the papers for the journal are generally not historians. The Annals was founded by the American Federation of Information Processing Societies (AFIPS) when it became clear that the members of AFIPS--societies such as ACM, IEEE, and DPMA--were not actively involved in recording the history of the field. There had been a series of oral interviews sponsored by AFIPS and the Smithsonian, but the pioneers were getting older, and our discipline's early history was potentially slipping away. Moreover, those of us who had been around in the early days weren't going to miss the opportunity to pass on to our successors--who were mainly young people--the excitement of discovery that we had experienced. We wanted a readable journal that would record the history, a task which would not be easy. Too much detail in the spirit of establishing the record would make the material less readable. Too little detail would make it only a series of anecdotes. Moreover, it was important to encourage the remembrances of the people who lived through those exciting times, along with the historical analyses by those who came after, and who in many cases would be trained as historians to do the analysis professionally. The remembrances of those who lived through periods of decision will help future analysts understand why those decisions were made, even though there may well be conflicting eye-witness accounts! We decided that this journal would welcome all who came to it seriously (or humorously, but with taste!), and would include all the styles and purposes mentioned. There was room in this house for all. After a couple of years of preparation, we were ready to publish the first few issues, starting in July 1979, It turned out that there were several people who had written serious articles (and in the case of Brian Randell, an excellent bibliography), and who needed a place to publish their work. They furnished the seed material for the Annals. Others were encouraged by this work to write about their own experience, and successes and failures. We also encouraged people in other countries and other disciplines to summarize and organize the history of computing in their countries and in their disciplines, such as in graphics and weather prediction. We also sought and received articles on the socioeconomics of the computing field itself, such as an analysis of advertising about computers, to understand the view the public had of computers and computing. Today, in 1993, with Volume 15 being published, the Annals is established as the place to publish history material about computers and computing. We welcome new authors and old authors. To be FORUM ON THE HISTORY OF COMPUTING
789
BERNARD A. GALLER
sure, there are other publications in the history of computing field. There is an excellent series of books published by MIT Press, another series of important reprintings by the Charles Babbage Foundation, a series of proceedings of ACM conferences, and so on. These are complemented by the archival collections of the Charles Babbage Institute, and the Computer Museum. In what follows, however, we discuss some of the issues faced by authors and publishers, primarily through the eyes of the Annals.
SCOPE OFINTEREST TheAnnals originally had a policy of requiring that events being recorded had occurred at least 15 years before the date of publication. The purpose of this is to ensure that the author (and the readers) have some perspective on those events. Thus, although some urged that we publish the history of the personal computer almost as soon as it was invented, it didn't seem wise to do so at the time. It is probably just about the right time now to do that. Hopefully, there are sources of historical material and interested writers who will undertake that task. Of course, if the material is from that long ago, how does an author remember it? It starts with an awareness of the need to record the history of the field. That leads to saving the key ingredients, the important and the nostalgic, from which the past can be reconstituted. We all have old stuff, and that of our friends, on which to draw. It gets easier with practice!
THE FUTURE? What about predictions of the future? That has always been the province of the science fiction writer, but one could imagine a serious article on the possible directions in which trends of the past might evolve into the future. Or a study of how one might learn from the past to think about the future. If we had tried to predict the present state of our technology, our environment, and our computing community 30 years ago, how far off would we have been, and why? The problem is sometimes that people are hesitant to "stick their necks out." A properly labeled predictive article can stimulate discussion, without much exposure. Who else would have a better prediction?
SUBJECT MATTER What is relevant to the study of the history of computing? One of the most interesting articles published in the Annals covered advertising in the computer field over the years. The role of people relative to the computer, the role of women, and other sociological and political subjects can often be understood better when cartoons, and advertising, and other nonconventional forms of publication are brought together and studied from an historical point of view. The Charles Babbage Institute staff has done several studies of different corporations' business records. What else would be relevant that historians might be overlooking now? It is important to take advantage of the variety of fields of expertise of people in computing, to enlist them in the service of the history of computing! Each brings a different perspective, and each is welcome.
HISTORIOGRAPHY The writing of history is a subject of interest in its own right. Of course, the Annals wasn't created to teach people how to write about history, but we did include a few articles of this kind. They are helpful to both writers and readers, in terms of the pitfalls to watch out for in writing and reading about historical events. We can all learn from those who understand it best. 790
CHAPTER XVI
PAPER: THE ANNALS OF THE HISTORY OF COMPUTING AND OTHER JOURNALS
Some examples of articles in the Annals about the writing of history are: • "Works and Tools," by Peter Drucker, Vol. 4, No. 4, pp. 342-347. • "The History of Computing in the History of Technology," by Michael S. Mahoney, Vol. 10, No. 2, pp. 113-125. • "Some Approaches to, and Illustrations of, Programming Languages History," by Jean E. Sammet, Voi. 13, No. l, pp. 33-50. • "Guidelines for the Documentation of Segments of the History of Computing," ed. by J.A.N. Lee, Vol. 13, No. 1, pp. 51-62.
WRITING STYLES Should a journal have a uniform writing style? Does it make articles easier to read? Or do you lose the unique expressiveness that each author brings to the subject? We learned a lesson in the early days of the Annals. One author withdrew his article when we tried, perhaps too hard, to help with his English. He was a European who was sure that he knew English better than our editor, and he was not about to let us tell him how to write. Were we wise to try so hard to not let him look foolish? Another (American) author insisted on his particular notation for the subject matter he was writing about. We decided that, in that case, we would not insist on a more standard notation; he was worth it? Over the years, we relaxed more and more in favor of offering help to authors, but trying to preserve their individuality of writing style. This can be a very delicate issue? We would hope that authors would welcome help with their styles, but would keep that unique flavor that only they can bring. It is a cooperative effort all the way through the process.
HISTORICAL STANDARDS For a conference, such as the first History of Programming Languages Conference (HOPL) in 1979, very strict standards were set, in terms of historical accuracy and completeness. Help was provided to authors by historians and by experts specifically designated for each paper. Should that much support be provided for authors of articles aimed at the Annals? It would be very desirable, of course, but quite expensive. A great deal of help and care is provided, to be sure, through the refereeing process, but some reliance has been placed on the section of the journal called "Comments, Queries, and Debate." This is an avenue that is not available to a conference, but can be useful in an on-going journal. Here a reader can take issue with an author, and a dialogue can be established between them, which itself becomes part of the historical record. One striking example of this occurred with the publication of the article on the ENIAC by Alice and Arthur Burks. We solicited comments from 19 people associated with the ENIAC project, and published their responses in the same issue of the Annals, as well as others afterwards. Many of those responses are quite revealing about relationships among the participants, at the time, and now? One person called and threatened to sue the authors and the editor-in-chief if the article was published. Fortunately, while the article was published, there was no lawsuit. Unfortunately, although that person was invited to write his own version of the events for the Annals, he never did. But the debate contributed to the history, and it helped elucidate as much as possible of the true history of the ENIAC, whatever that is. The related references (all from the Annals) are: • "ENIAC: First General-Purpose Electronic Computer," Vol. 3, No. 4, pp. 310-399. • "Mauchly: Unpublished Remarks," ed., Henry S. Tropp, Vol. 4, No. 3, pp. 245-256. FORUM ON THE HISTORY OF COMPUTING
791
BERNARD A. GALLER
• "Comment on ENIAC Article," by Byron E. Phelps, Vol. 4, No. 3, pp. 284-287. • "John Mauchly's Early Years," by Kathleen R. Mauchly, Vol. 6, No. 2, pp. 116--138.
AUTHORS AS PARTICIPANTS This leads to the question as to how disinterested or unbiased a participant can be in writing about an event or an artifact. Clearly each author brings a personal perspective to a writing. That in itself is worth recording, however distorted others might perceive it to be. Actually, that is what historians inevitably have had to deal with, as most of the records they uncover about antiquity were personal recordings in their day. It is only when a number of contemporary writings come to light that we begin to have perspective and understanding of past events. The difference here is that we are watching those different accounts of the same event appear serially in time, instead of unearthing them more or less at the same time. At least we have the opportunity to make them generally available for comment while we are here to continue to question them. It is interesting to note that the ENIAC controversy continues to this day. The excellent series of television programs on the history of computing that appeared on PBS in 1992 did not mention Atanasoff for some reason, although most historians will agree that he had an important role in the argument about the first general-purpose electronic computer. Arthur and Alice Burks have written to the Ann Arbor News (and perhaps other publications) about this, raising the issue as to whether there was some deliberate bias in creating the television series. That might make an interesting study.
REPRINTS? A question that the editors of the Annals wrestled with over the years, was how many articles that had appeared earlier, to include in the journal. A number of principles evolved over time in this regard. First, any article or report that was readily available to the readers should not reappear in the Annals, unless there was some special reason to bring it together with some collection of other items. On the other hand, items that were of historical interest and were not readily available were possible candidates, but whenever possible the author would be asked to write a preface putting the original item in perspective, given the hindsight of the present. Mina Rees was especially helpful in this regard, with several articles about the early days of government support for computing. There was a danger, of course, of too much reliance on reprinted material, which can be deadly for the readers' interest. A general principle was established, at least for the earlier volumes, that no more than 20 percent of the historical material in any one issue would consist of reprinted articles. That seems to have been a reasonable guideline.
ANECDOTES There is a special place in history for anecdotes. This is the folklore that carries so much of our values, but isn't formal enough or large enough in some sense to be worthy of being written up as an article. It is very important, however, to catch the humor and the stories that come through in the form of anecdotes. The Anecdotes section of the Annals has served us well. Hopefully people will continue to contribute this folklore so it can be preserved for our successors.
792
CHAPTER XVI
PAPER: THE ANNALS OF THE HISTORY OF COMPUTING AND OTHER JOURNALS
WHO SHOULD REVIEW HISTORICAL ARTICLES? When an article is submitted for publication, who should referee it? Other participants? Totally disinterested experts? Historians? Actually, it wouldn't hurt to include all of the above. That is about what is being done for the A C M S I G P L A N HOPL-II conference, in April, 1993. Whether a journal can do that much isn't clear, but as indicated, hopefully the Comments, Queries, and Debate part of the journal can help correct oversights and biases that are not caught and clarified during the refereeing process. These are some lessons that have been learned. We hope that all of us can continue to contribute to the historical substance of our field, as well as to its recording.
OTHER PUBLICATIONS We are fortunate that a number of journals quite often publish articles dealing with the history of computing. Of course, the Annals is the leading journal in this regard, being dedicated specifically to that purpose. But other journals should be recognized as contributing to the historical record. There are two particularly valuable resources for locating articles and books on the history of computing, and from which one can glean a great deal of information about journals:
A Bibliographic Guide to the History of Computing, Computers, and the Information Processing Industry, compiled by James W. Cortada, and published by Greenwood Press, Westport, CT, in 1990. "An Annotated Bibliography on the Origins of Computers," compiled by Brian Randell, Annals of the History of Computing, Vol. 1, No. 2, pp. 101-207. Listed below is a portion of Cortada's bibliography, dealing with periodicals in the field. A scan of the Randell listing, however, reveals several other journals that have rather frequently included historical material on computing:
American Mathematical Monthly Communications of the Assoc. for Computing Machinery (ACM) IEEE Computer IEEE Spectrum
Nature Science Scientific American Technology & Culture
(The portion of the Cortada Bibliographic Guide referred to above is the following.)
PERIODICALS 1 259 Abacus (1982-1988). This contained numerous articles on the history of computing. 260 Association for Computing Machinery. Bibliography of Current Computing Literature (New York: ACM, 1969-1975). These seven volumes contain thousands of titles on computers, applications, programming, data processing, and other related topics.
Reproduced with permission of Greenwood Publishing Group, Inc., Westport, CT, from A Bibliographic Guide to the History of Computing, Computers, and the h!]ormation Prt~'essingIndustry, compiled by James W. Cortada, Copyright 1990 by James W. Cortada, pp. 41-44. (The numbers in the left margin represent the sequence of the entries in his bibliography.)
FORUM ON THE HISTORY OF COMPUTING
793
BERNARD A. GALLER
261 Association for Computing Machinery. Comprehensive Bibliography of Computing Literature. 1966-1967. New York, ACM, 1967-1968. These two volumes represent a variant of numerous bibliographies published by ACM of current technical publications on data processing. 262 Association for Computing Machinery. Computing Reviews. New York: ACM. 1977. These two volumes are similar in scope to No. 261. 259 Association for Computing Machinery. Computing Reviews. Permuted (kwic) Index to Computing Reviews. 1960--1963. (New York: ACM, 1964). A second volume coveting 1964-1965 was published in late 1965.
264 Association for Computing Machinery Journal (1954-Present). This is the main publication of the ACM and often where the first formal explanation of a new technology or programming language appeared. 265
Association for Computing Machinery. ACM Transactions on Mathematical Software (1975-Present).
This is a technical journal, reflecting the significant amount of activity present in the area of software development. 268
Charles Babbage Institute Newsletter (1979-Present).
This quarterly is a major source of information on historical activities. For details it is the best quick reference. Charles Babbage Institute, 103 Walter Library, University of Minnesota, Minneapolis, Minnesota 55455 (USA). 269
Computer Journal (1958-Present).
This British journal is the organ of the British Computer Society and is a technical publication. 278 IEEE Center For the History of Electrical Engineenng. Newsletter (I 982-Present). This contains news about IEEE activities, news about research on the history of electricity, computing, and other related fields. It publishes a bibliography and articles on key archival collections. 280 Mathematical Tables and Other Aids to Computation (1943-1960). This was the most important source of articles dealing with computer science in the 1940s and very early 1950s. It served as the primary publication outlet for many technical articles of the period. In total 14 volumes of issues were published. 283
Springer International and American Federation of Information Processing Societies. Annals of the
History of Computing (1979-Present). This is the single most important source of material on the history of information processing, particularly on its technology. It also contains book reviews, bibliographies, obituaries, and other useful information. For details write to Spnnger-Verlag, 44 Hartz Way, Secaucus, N. J. 07094 (USA). [Annals of the History of
Computing is now published by the IEEE Computer Society.] 284
Think (1935-Present).
This is IBM's employee magazine. It contains articles on the company's major activities, operations in various countries, and biographies of key executives, it is published monthly. 285
Williams, M.R. "History of Computation," CIPS Review (1980-Present).
This is a two-page column appearing since 1980 on all aspects of the industry's history. 794
CHAPTER XVl
PAPER: AN EFFECTIVE HISTORY CONFERENCE
AN EFFECTIVE HISTORY CONFERENCE Jean E. Sammet R O. Box 30038
Bethesda,MD 20824 INTRODUCTION In order to hold an effective computing history conference it is first necessary to understand why the problems of doing so are different from holding any other type of computing conference. I particularly contrast this with a conference reporting on current work. I will not list problems that are common to all conferences (e.g., getting material done on time, preparing publicity). Note that, although this information is based primarily on experience with programming language history conferences, the points are general for any history conference dealing with computing. These notes begin with a listing of problems that arise when organizing a computing history conference, offer some suggestions for solutions to these problems, and conclude with a list of examples of previous conferences and conference sessions on the history of computing.
PROBLEMS IN HOLDING A COMPUTING HISTORY CONFERENCE 1. Deciding the scope of the conference a. Will it cover specific events (e.g., development of a programming language or an operating system or a computer)? b. Will it cover broad themes (e.g., use of computers to do nonnumerical mathematics, personal computers, artificial intelligence)? c. What is an appropriate "past" time scale for the subjects covered by the conference (e.g., 5 years, 10 years, 25 years)? (Note that the computer field has moved so quickly that 5 years can be a very long time for some developments!) d. Will written papers be required from potential participants, or will (only) talks be sufficient? (In the following questions, the concept of "papers" can generally be replaced by "talks".) e. Aside from the time scale, what are the criteria for identifying topics for appropriate papers (e.g., current use, major use at some time, significance, publications)? f.
Should the papers be all invited, or all submitted, or a combination (i.e., some of each)?
g. Should the basic flavor be that of a "reunion" of people with a common background for some historical event or activity, or should it be more general and/or higher quality? h. Is this conference "one-of-a-kind," or part of a series? Is some type of follow-on conference anticipated, even if not a whole series? 2. Forming a program committee All conferences must recruit people with suitable background for the program committee. However, in the case of a history conference it is generally harder to persuade qualified individuals to participate in an activity that may have less value to their professional stature than participating in a conference dealing with more mainstream issues.
FORUM ON THE HISTORY OF COMPUTING
795
JEAN E. SAMMET
The types of individuals who should be considered for inclusion in the program committee are the following: specialists in the subject of the conference, people with formal training in at least the history of science and preferably with some experience in the history of computing, individuals who were direct contributors to the subject of the conference. (Care must be taken with the latter group to tread the fine line between possibly excluding a significant paper because the logical person to write it is on the program committee, or alternatively allowing such a submission but with proper safeguards against a favorable bias from the remainder of the program committee. The sponsoring organization might have specific policies dealing with this issue.) . Difficulty in getting people to prepare good papers--whether invited or submitted a. Authors tend to be more interested in doing their current work than in resurrecting their past. Academic people may not get much "tenure credit" for such papers, and industrial people have difficulty in getting their manager's approval to spend time on preparing such a paper. b. Some senior/older people who are crucial to documenting the history may be physically or mentally unable to make the effort, to prepare a good paper, and/or may lack support (e.g., secretary, access to files). c. The basic (and hence old) material needed to prepare good papers may be difficult to find, or nonexistent. d. Even after solving problems (a), (b), and (c), the author probably has had no experience with history and may not have any idea how to write a good history paper. 4. Difficulty in getting people to attend Most technical individuals--and their managers or granting agencies---do not believe that history can help them in their current work. . Difficulty in deciding what type of permanent material to produce for the conference attendees and also for the final general community interested in history. (The result of a computer history conference should itself be a part of the history of computing.) a. Written papers may not be sufficient to provide a record of the historical material being covered. Audio/visual records may also be needed. b. If papers are issued as a "preprint" conference proceedings, it may be difficult to get the authors to revise/improve their papers for some type of final book. c. Cost of audio/visual recording is extremely high.
SOME SUGGESTED SOLUTIONS 1. In deciding the scope, it is desirable to determine either (i) what area of the computing field the organizers want to document or (ii) what audience should be attracted. (These are certainly not mutually exclusive, but it may be necessary to prioritize them in solving other problems.) If the answer is (i) then it is just up to the organizers. If the emphasis is to be on the audience (i.e., (ii)), then it is probably true that general themes (rather than specific items) may be more attractive. The most appropriate time scale depends on the subjects being covered. For a programming language or an operating system it probably requires 8-10 years to make sure that the specific item is really of value. (For example, consider this time scale as applied to Ada and Unix.) For 796
CHAPTER XVl
PAPER: AN EFFECTIVE HISTORY CONFERENCE
a more theme-oriented topic, a minimum of 5 years is certainly needed, and the 8-10 year criterion is better. In selecting invited versus submitted papers, it really depends on whether the scope is on specific topics or on broad themes. If on specific topics, then the organizers are probably better off with people who were direct participants in the activity, and thus need to issue an invitation. (It is of course preferable to invite "key" participants but they may not be available and so it may be necessary/appropriate to invite people who were more junior in the development in order to get some first-hand information.) If the scope is on a broad theme then any qualified person could write a paper, and hence submitted papers are equally appropriate. However, for the reason indicated in (3a), it might be very hard for potential authors to find/take the time to write--and submit for refereeing--a history paper that might be rejected. 2. The best way to persuade someone--particularly a key participant--to write a paper is to persuade him/her that he/she will be able to document--for perpetuity---~is/her view of the history involved, by doing such a paper. Such a paper--with its conclusions and advice--might last much longer than the actual technical development being described. Unless the underlying historical material is expected to be available to a reasonable extent, there is no point in having a paper written, as it will probably consist primarily of anecdotes rather than detailed historical information/analysis. To encourage authors to prepare good papers, try to use all the following techniques: • provide questions related to the conference subject to give the author an idea of the type of information to be included in the paper, • allow time for (and require) several drafts of the paper, • provide program committee intellectual support (e.g., comment on interi~n drafts), • have a consulting historian to make sure that the necessary historical information is being reasonably conveyed and to give guidance to the authors. 3. To improve attendance, it is useful to point out how knowledge of the past might help people do a current job. Solutions to old problems may become obsolete as technology changes, but then may become relevant again with more changes in technology. A good illustration of this is the • dedicated use of a computer by a single individual for as much as an hour or two---and associated support software followed by •
time-shanng with many individuals using a single computer at the same time (because the computer was too expensive to provide dedicated use to a single person) followed by a return to
• dedicated use of a computer by a single individual for indefinite periods of time (with a personal computer on each individual's desk and available support software). Perhaps even a session to discuss this---either in philosophy or with specific examples--can be included in the program. 4. For a permanent record, the ideal is to get papers prepared and issued as preprints, and then revised for a permanent book. However, if this can't be done then it is probably better to get the final papers after the conference. The main disadvantage to this is that the authors will procrastinate because the date is not as firm as when the paper must appear in a conference proceedings to be handed out at the conference.
FORUM ON THE HISTORY OF COMPUTING
797
JEAN E. SAMMET
EXAMPLES OF HISTORICAL CONFERENCES/SESSIONS The first significant historical conference on computing was the one held in Los Alamos in 1976. The results are in the book edited by Metropolis et al. shown in the Reference List. The organizers invited people they deemed appropriate to discuss certain issues, but did little or nothing to ensure the quality of the papers. They used a very short time scale prior to the meeting, and hence, there were people they initially invited who couldn't participate because of prior commitments (myself being one of them). The first HOPL conference is documented in Wexelblat (editor) shown in the Reference List. That conference used most of the "solutions" described, and they--together with additional experience gained since then--are being applied to HOPL-II. For a number of years AFIPS held "Pioneer Days," in conjunction with the National Computer Conference. These were generally afternoon sessions focusing on a specific topic (e.g., BASIC, MARK I at Harvard, COBOL, UNIVAC I, FORTRAN). For several years these sessions were tied to key anniversary dates. The organizers invited several people to make presentations. In some cases there were papers or notes available for distribution to the attendees but in many cases there was no documentation provided, and there generally was no permanent record developed. There was, generally, little or no quality control over the presentations. Because there was great informality about the organization and preparation (relative to a full-fledged conference), the sessions were often fascinating to participate in (as I did for COBOL), or attend (as I did for the others). From the audience viewpoint they often conveyed the flavor of a college reunion! In addition to the ACM SIGPLAN History of Programming Languages (HOPL) Conference in 1978, there were three history conferences held under general ACM auspices--interactive systems, scientific computing, biomedical computing. In my personal opinion, the quality of the preparation, organization, and written material for those three conferences was poor. Even allowing for my own bias, the HOPL conference is a model but the others are not. The books resulting from these four conferences, as well as the Los Alamos conference mentioned earlier, are shown in the reference list. REFERENCES
[Blum, 1990]Blum,Bruce1.,and Duncan, Karcn,Eds.,A Hiswryof Medical lnfi~rmatics,Reading,MA: ACM Press/AddisonWesley, 1990. [Goldberg,1988]Goldberg,Adele,Ed.,A Historyof PersonalWorkstations,Reading,MA: ACMPress/Addison-Wesley,1988 [Metropolis, 1980] Metropolis, Howlett,and Rota, A History of Computing in the Twentieth Century, New York:Academic Press, ! 980. [Nash, 1990] Nash, Stephen G., Ed., A History of Scientific Computing, Reading, Mass., ACM Press/Addison-Wesley Publishing Co., 1990. [Wexelblat, 1981] Wexelblat,RichardL., Ed., History of Programming Languages, New York:ACM MonographSeries/Academic Press, 1981.
798
CHAPTER XVl
PAPER: UNIVERSITY COURSES
UNIVERSITY COURSES
Martin Campbell-Kelly Dept. of Computer Science University of Warwick Coventry CV4 7AL, UK
ABSTRACT This paper describes the rationales for teaching university courses on the history of computing. The range and scope of typical courses are described in terms of their syllabuses and contents, teaching methods and resources, and eoursework and assessment. Finally, the criticism that the history of computing is too "intemalist" is discussed.
INTRODUCTION: WHY TEACH THE HISTORY OF COMPUTING? In this paper I shall mainly address the topic of teaching a history of computing course to computer science undergraduates. Many universities teach courses with a title such as "Computers and Society," but although these courses often include a good deal of elementary historical material, they are not primarily about history• Again, many universities offer courses on the history of technology in which the history of computing could (indeed should) form a component. While I am sure that most computer science undergraduates would benefit from both computers and society courses and history of technology courses, I see these as being complementary to a full-scale course on the history of computing. The typical history of computing course is taught to a computer science undergraduate in much the same spirit that a history of mathematics course is taught to a mathematics student, a history of physics course to a physics student, or a business history course to a business studies undergraduate. Courses of this type, particularly when taught in the student's final year, can take advantage of two or more years of specialised learning and, therefore, will not in general be accessible to people outside the discipline. Such courses are commonly criticized for being too "internalist"--that is, of interest only to subject specialists and irrelevant to the wider community. I will come back to this point later. For the novice teacher about to start a course on the history of computing, however, there is something to be said for erring on the side of internalism and caution before attempting to launch a deeply historical course. As the distinguished historian Geoffrey Elton advises: •.. the professional scholar teaching others will do best if he stays within his professional competence; he may by all means try to enlighten his pupils about humanity at large, but he will be really successful only if he employs the techniques of his craft in the elucidation of the subject matter of his teaching. [Elton 1969, p. 187] It is all too easy for the professional historian to intimidate the newcomer. I recommend anyone entering the field to read Elton's The Practice of History originally published in 1967, but still in print after numerous impressions. Elton's important message is to welcome newcomers to history, and to help them avoid the common pitfalls. Any lecturer promoting a history of computing course is bound to have to justify its place in an already overcrowded curriculum. This is not a new problem, and not one that is peculiar to computer science. The civil engineer and historian Henry Petroski [1991] recently wrote an inspirational article in the American Scientist in which he justified the practice of teaching history in engineering courses. Petroski began by citing the results of a questionnaire completed by Duke University engineering FORUM ON THE HISTORYOF COMPUTING
799
MARTIN CAMPBELL-KELLY
graduates from the 1950s. The graduates were asked (without any prompting) to list the courses that "proved to be most useful in their careers." For these senior engineers, overwhelmingly the most useful course turned out to be a history course they had taken 40 years ago. Petroski surmised that most of the technical courses taken by these students of the 1950s had long been forgotten because they had been taught in "an impersonal manner, providing little, if any, historical or biographical background to the state of the an or its developers." By contrast, the history course had attempted to "make apparent the interrelationships of things and people, of structures and environments, of machines and war, of technology and culture, of engineering and society." The history course enabled the students to integrate their isolated technical studies and to begin to understand the philosophy of engineering. Petroski's arguments translate very readily to the history of computing. The typical computer science undergraduate of today sees the world through an astonishingly narrow window: the student knows very little about computing before 1980, he or she often has a strong orientation toward the supply-side of computing, is unaware of the economics of computers or software, and is ignorant of the organizations that use them. A good history of computing course can do a great deal to widen this window. If that were all, it would be enough, but the study of the history of computing adds further value. There can be no question that a knowledge of the past can inform the present. As Fred Gruenberger put it so eloquently in the first issue of the Annals of the History of Computing in 1979: It seems that every single thing we know today about computing had to be learned--and relearned--the same painful and expensive way. It may just be that simple re-reading of history once or twice a year can provide us with insight, and it is insight that we desperately need. [Gruenberger 1979, p. 49] A course on the history of computing also exposes the student to a new and unfamiliar academic discipline--history. History teaches objectivity; it teaches the use and abuse of evidence; and it teaches the need to question received wisdom. For example, I find that before coming on to my third-year history course, many of my students have absorbed shockingly derisive opinions of FORTRAN and COBOL. But once they have understood the context in which these languages were developed, and something of the economics of innovation and the social construction of technology, they come to realise that there is a good deal more to a programming language than its syntax. Finally, a history of computing course gives students the opportunity and challenge of producing an extended piece of written work--often for the first time since coming to university.
SYLLABUSES In order to get a better feel for the content of the history of computing courses currently being taught, last year I made a concerted effort to make contact with people who are currently teaching such courses. Altogether I learned of about a dozen courses world-wide, and I expect there are at least as many again that I do not know about. Several of the organizers of these courses were kind enough to send me copies of their syllabuses, examples of coursework assignments, and specimen examination questions. The discussion that follows is heavily based on these responses, although inevitably there is something of a small-sample problem in drawing broad conclusions from what is clearly still a little-taught subject. It is clear from the syllabuses I examined that there is a commonly accepted "core" of about 10 topics that appear in virtually all the courses (Table 16.1). Generally, these topics are taught in chronological sequence, though each topic tends to be pursued to its end. And of course, any attempt at a strict chronology breaks down when discussing aspects and applications of computing, such as programming languages or artificial intelligence, that range over a number of decades. 800
CHAPTER XVI
PAPER: UNIVERSITY COURSES
TABLE 16.1 Topics in the Historyof Computing.
10
Pre-history (e.g., numbersystems, the developmentof algorithms, logic and language, calculating instruments, etc.) Babhage's CalculatingEngines Hollerith, IBM, and office machinery Mechanical Calculators (e.g., differential analysers, the Harvard Mark I and other relay calculators,etc.) Electronic Calculators (ABC, war-timedevelopments:ENIAC,Colossus) The Stored-ProgramConceptand EDVAC The PioneerPhase (e.g., UNIVAC,Whirlwind,early industry) Commercialization(the later computer industry, System/360.giant machines,etc.) Aspects and Applicationsof Computing(e.g., architecture, programminglanguages,softwareengineering, AI, networks, etc.) Personal Computing
In all the courses, the development of the stored-program concept in 1945 is regarded as the central event of the history of computing: it is the pivotal development to which the first half of the course leads, and from which the second half of the course springs. Courses typically spend approximately half the course on pre-1945 events and a half on post-1945, although there are exceptions. Although the courses have this core material in common, the treatment by individual lecturers varies greatly. Of necessity, each lecturer tailors his or her course to the specific background of the students, and to the lecturer's own technical and historical background, and interests. For example, one course devoted about a quarter of the time to the prehistory of computing, whereas other courses gave it only a token mention. Some lecturers with a strong specialist knowledge---of, say, computer architecture or software--have biased their courses in this direction by including several lectures on topics such as high-speed computing or software engineering. Clearly the criticism of internalism applies most strongly in these cases, but these criticisms are easily answered provided the specific developments are informed by a general background of the history of technology. A number of courses have attempted to avoid portraying the development of computing as a chain of unstoppable technological progress, by relating developments to such phenomena as World War II, the Cold War, or the Space Race. This has the effect of bringing in the wider context of science and technology policy, as well as making the course more accessible to noncomputer scientists. A much smaller number of courses interpreted the history of computing more as the history of information processing, and avoided discursion into specific technological details. These courses tended to be much richer in business, economic and social history, less supply-side oriented, and did not require heavy technical prerequisites. Perhaps the emergence of the personal computer shows the most variation in treatment. Several courses eschew the topic entirely--as perhaps being too modern, although the PC is now well within the purview of the "ten-year rule. ''2 But it may also be a reflection on the poor state of the secondary
Almost since the dawn of interest in the history of computing in the late 1970s there has been an understandingthat one shouldavoid writinghistoryaboutevents morerecentthan 10 yearsago, becausethere has been insufficienttime to develop a proper perspective. Althoughthis is a wise injunction for the most part, one consequenceis that almost the only people to write about the historyof the personal computer have beenjournalists strongeron hyperbolethan history. FORUM ON THE HISTORY OF COMPUTING
801
MARTIN CAMPBELL-KELLY
literature; for although there is a vast literature on the development of the personal computer, its quality is generally execrable.
TEACHING METHODS, TEXTBOOKS, AND MATERIALS All the courses were reading based, with lectures being used to introduce the study topics and to pace students through the course. There were typically 30 hours of lectures on the courses, and there were from as few as a dozen to well over 50 students on the courses. Some courses included seminars giving an opportunity for students to make individual presentations, but this appears to be a vanishing luxury in the face of declining staff-student ratios. No single textbook covers all the material taught on any course. For the more technologically oriented courses, by far the most popular textbook was Mike Williams's A History of Computing Technology [ 1985b]. This excellent book was originally written as a text to support Williams's history of computing course at Calgary University [Williams 1985a], and covers the prehistory of computing up to System/360. Unfortunately Williams's book is currently out of print and this promises a headache for courses that make heavy use of it. Another popular text is Computing Before Computers, edited by William Aspray [1990a], which includes contributed chapters from several pioneers in teaching the history of computing. Unfortunately this text takes events only as far as the invention of the stored-program concept, and so covers only the first half of any course. Another popular book is Herman Goldstine's The Computer: From Pascal to von Neumann [1973], which has the merit of being available as an inexpensive paperback but is now showing signs of age. Finally, one should mention Brian Randell's pioneering Origins of Digital Computers--first published in 1973, and now in its third edition [Randeli 1982]. This book consists of a collection of key papers on the development of computing; although the organization and introduction of the material is exemplary, it is exclusively devoted to computer technology, and is somewhat impenetrable for the average undergraduate. In the absence of a single textbook, all course organizers have adopted the strategy of supplementing or replacing a textbook with a selection of readings. These fall into three categories: reprints of primary sources (e.g., extracts from von Neumann's EDVAC Report [ 1945]), historical articles (e.g., papers from the Annals of the History of Computing or Technology and Culture), and chapters from historical monographs. There is an economic problem (not to say a copyright problem) in distributing photocopied handouts to large classes, so that some course organizers have deposited photocopied materials for in-library reading and placed monographs on shelf-reserve. In fact although the textbook problem is difficult, the wider literature of the history of computing has blossomed remarkably in the last decade, and there are now at least two dozen good monographs on the history of computing. One can mention such highlights as Nancy Stern's From ENIAC to UNIVAC [1981], Paul Ceruzzi's Reckoners [1983], and the superb histories of IBM's computers [Bashe 1985; Pugh 1991]. The history of programming languages has also been particularly well treated in the impeccably produced proceedings of the first History of Programming Languages conference [Wexelblat 1981]; and one must pay tribute to Jean Sammet's pioneering Programming Languages: History and Fundamentals which was first published at the remarkably early date of 1969. There are also now several excellent biographies of key figures in the history of computing, such as Austrian's Herman Hollerith [1982], Hodges's Alan Turing [1983], and Aspray's von Neumann [ 1990b]. In the broader contexts of the information society and policy arenas one can single out James Beniger's The Control Revolution [1986], and Kenneth Flamm's Targeting the Computer [ 1987]. One should also mention the contribution of the MIT Press History of Computing Series, and the Charles Babbage Institute Reprint Series for the History of Computing, now totalling 10 and 16 volumes, respectively. Clearly a well-stocked library is the sine qua non of a successful course in the 802
CHAPTER XVl
PAPER: UNIVERSITYCOURSES
history of computing. The book-review section of the Annals of the History of Computing is the best single place for keeping up-to-date on this rapidly growing literature. Organizers of history of computing courses are evidently conscious of the need to motivate and retain their students, and many have gone to considerable efforts to enliven their courses with visual aids, outside speakers, and other novelties. There is a wealth of visual material in the published literature from which lecturers have prepared slides, and some of the science museums have produced slide sets of their artifacts. Examples of movie films include the 1946 newsreel of the ENIAC, the film of the EDSAC [Cambridge University 1951], the John von Neumann movie [AMA 1966], and promotional films of many first-generation computers. There appears to be no simple way, other than the informal grapevine, of tracking down this material. A number of course organizers use artifacts or simulations to illustrate early calculating technologies. Relatively easy to find artifacts include abacii, slide rules, mathematical tables, Comptometers and Brunsvigas, punched cards, and wiring boards; computer artifacts include electronic tubes and discrete transistor boards, core memory planes, and recording media. In the absence of artifacts, it is possible to simulate early computers: for example, at Calgary University, Mike Williams enables students to program a 1950s LPG-30 via a simulation program, to avoid wear-and-tear on an actual LPG-30 [Williams 1985a]; and at Warwick and Cambridge Universities, we use an EDSAC simulator that runs on a Macintosh personal computer [Campbell-Kelly 1992]. Where geographically possible, museum visits are an alternative to the ownership of artifacts. For example, at Warwick, we were hosted for a day last year by the London Science Museum, who generously organized a series of demonstrations that tied in with the course. Most notable was a demonstration of Babbage's Difference Engine No. 2 by the engineers who constructed it. The engineers took an obvious pleasure in fielding questions from such knowledgeable and enthusiastic visitors. C O U R S E W O R K AND ASSESSMENT The term paper or essay, and end-of-session examination, were the predominant means of assessment on all the courses. Written work poses difficulties for nonhumanities students, whose writing skills are rusty or nonexistent, and lecturers are sensitive to this problem. One strategy for ramping up writing skills has been to set a relatively undemanding first assessment, such as a 500-word book review or a biographical sketch. A lot of attention was paid to developing students' knowledge of scholarly apparatus and their ability to use library resources. They were taught, formally or informally, how to structure essays and marshal their arguments; how to quote effectively and accurately; to understand the nature of plagiarism; to make proper use of footnotes; and to cite references in a consistent style. Students were generally referred to some such authority as the Chicago Manual of Style. The typical assessment was 2000-3000 words in length, and students were invariably offered a wide range of topics, or even a topic of their own devising. Besides making the grading of dozens of essays less tedious, the wide range of topics gives each student a chance of finding a topic that is personally interesting, and--at least as important--reduces the competition for single copies of library books. Topics ranged from the highly technological through to broadly based business and economic history. Typical assignments were: 1. The Invention and Development of the Positional Number System (Calgary) 2. The History of IBM since the 1940s (UMBC, Maryland) 3. The Controversy over the Invention of the Stored-Program Concept (Warwick)
FORUM ON THE HISTORYOF COMPUTING
803
MARTIN CAMPBELL-KELLY
4. John von Neumann: His Life and Contributions to Computers (several universities) 5. The Evolution of a Programming Language (American University) The consensus was that students should be required to produce at least one piece of written work. However, for the truly reluctant writer, a programming exercise was sometimes permitted--such as constructing a Turing Machine simulator, or programming a simulated computer. As well as providing training in scholarship, the coursework forces the student to study at least one topic in real depth. All the courses were additionally assessed by an end-of-session or take-home examination. Questions were similar in spirit to the essay topics, but generally more focused to discourage discursive answers. (Examples: "Describe, and show the importance of, the various steps in the search for memory from the 1940s to the 1980s"--UBC, Maryland; "Describe the main stages leading to the widespread acceptance of high-level programming, and explain why this acceptance took so long to achieve" --Warwick.)
CRITIQUE Let it be said: N o t everyone approves of history of computing courses. For example, Mike Mahoney of Princeton University told me, in a private communication, that he preferred to embed the subject in a larger course on the history of technology. As he rightly observes, "Computing has its own parthenogenic myth of springing full-grown from the heads of Turing and von Neumann, and history would do well to work against it." As Mahoney intimates, the main criticism of the history of computing is that it is too internalist; that the history of computing is a private history, uninformed by sound methodology, and of little relevance to the wider historical community. The same criticism can, of course, be made of the history of mathematics or the history of physics. In fact, with the honourable exception of Mahoney, I find little evidence that large numbers of historians of technology are rushing to assimilate computing into their courses. So, if the history of computing is to be taught at all, it is likely to be done by enthusiastic academics with a mission to teach the subject: computer scientists with little formal historical training; and a few historians with a modest knowledge of computing. In fact, I would argue--not least to stimulate debate at this forum--that the history of computing is a special case, and not really like the history of mathematics or physics at all. Computing is the dominant technology of the second half of the twentieth century, which pervades all aspects of economic life. In this, it is much more akin to business history (say). No one who has read Chandler's magisterial Visible Hand [1977] can be left thinking that business history is narrow or internalist. At the moment there exists no great synthetic work in the history of computing of comparable stature, although James Beniger's Control Revolution [1986] shows clearly the vast canvas on which the history of computing will ultimately be painted. When it arrives, the great synthetic work on the history of computing will have to draw in full measure from the history of technology, the history of science, business and economic history, and social history. At the present time, the subject is firmly anchored to the history of technology, but increasingly it is drawing on business history (e.g., to explain the development of the computer industry) and the history of science (e.g., to understand the development of algorithms, computability, and artificial intelligence). Of course, it is a very tall order to expect a teacher of the history of computing to be expert in all these different historical genres. But we should all be aware of them, and as the literature develops we should speedily incorporate it into our courses. For all of us, the development of that literature is a fundamental brake on the development of history of computing courses. For example, at the present
804
CHAPTER XVI
PAPER: UNIVERSITY COURSES
time most of us wisely refrain from dabbling in social history. Yet the phenomenon of the computer hacker and the emergence of the personal computer cry out for the attention of the social historian; for the moment we must be patient and give our students the best guidance we can.
ACKNOWLEDGMENTS 1 am most grateful to the following who supplied me with information about their courses and/or commented on a draft of this paper: Tim Bergin, Corrado Bonfanti, Colin Burke, Paul Ceruzzi, John Fauvel, Jan Lee, Mike Mahoney, Judy O'Neill, Bob Rosin, Steve Russ, Jean Sammet, James Tomayko, Arthur Norberg, Mike Williams, and Roy Wilson.
REFERENCES [Aspray, 1990a] Aspray, William F., Ed., Computing Before Computers, Ames: Iowa State University Press, 1990. [Aspmy, 1990b] Aspray, William E, John wm Neumann and the Origins qfModern Computing, Cambridge, Ma: MIT Press, 1990. lAMA, 1966] American Mathematical Association, John yon Neumann, 16 mm. fire, sound, B/W, 63 min, 1966. [Bashe, 1985] Bashe, Charles etal., IBM~ Early Computers, Cambridge, Ma: MIT Press, 1985. [Beniger, 1986] Beniger, James R., The Control Revolution: Technological and Economic Origins of the Information Society, Harvard University Press, 1986. [Bonfanti, 1993] Bonfanti, Corrado, A Course on the History ¢~flnformatics at the University of Bari (Italy), typescript, Jan. 1993. [Cambridge University, 1951] Cambridge University Computing Laboratory, The EDSAC Film, 16 mm. film, sound, colour, 10 rain., 1951 and 1976. [Campbell-Kelly, 1992] CamphelI-Kelly, M., Edsac: A Tutorial Guide to the Warwick University EDSAC Simulator, University of Warwick, 1992. [Ceruzzi, 1983] Ceruzzi, Paul E., Reckoners: The Prehistory of the Digital Computer J~om Relays to the Stored Porgram Concept, 1935----45, West Port, CT: Greenwood Press, 1983. [Chandler, 1971] Chandler, Alfred D., The Visible Hand, Harvard University Press, 1971. [Elton, 1969] Elton, G. R., The Practice of History, Glasgow: Collins-Fontana, 1969. First published ! 967, University of Sydney Press. [Flamm, 1987] Flamm, Kenneth, Targeting the Computer, Washington, DC: Brookings Institution, 1987. [Austrian, 1982] Austrian, G. Herman Hollerith: Forgotten Giant of Data Processing, New York: Columbia University Press, 1982. [Goldstine, 1972] Goldstine, Herman H., The Computer: From Pascal to yon Neumann, Princeton University Press, 1972. [Greuenberger, 1979] Greuenberger, F. J., The history of the JONNIAC, Annals of the History of Computing, Vol. 1, pp. 49-64, Jul. 1979. [Hodges, 1983] Hodges, Andrew, Alan Turing: The Enigma, London: Burnett Books, 1983. [Petroski,, 1991] Petroski, Henry, In context, American Scientist, Vol. 79, May-June 1991, pp. 202-204. [Pugh, 1991] Pugh, Emerson W., IBM's 360 and Early 370 Systems, Cambridge, MA: MIT Press, 1991. [Randeil, 1982] Randell, Brian, The Origins of Digital Computers, 3rd. ed., Berlin and New York: Springer Verlag, 1982. [Samrnet, 1969] Sammet, Jean E., Programming Languages: History and Fundamentals, Englewood Cliffs, NJ: Prentice-Hall, 1969. [Stem, 1981] Stern, Nancy B., From ENIACto UNIVAC,Bedford, MA: Digital Press, 1981. [von Neumann, 1945] yon Neumann, John, First Draft of a Report on the EDVAC, June 1945; reprinted in Papersof John van Neumannon Computingand ComputerTheory,W. F. Aspmy and A. W. Barks, Eds., Charles Babbage Institute Reprint Series for the History of Computing, Vol. 12, Cambridge, MA: MIT Press, 1986. [Wexelblat, 198 I] Wexelblat, Richard L., Ed., History offProgrammingLanguages,Academic Press, 198 !. [Williams, 1985a] Williams, Michael R., A course in the history of computation, Annals r~ftheHistory of Computing,Vol. 7, July 1985, pp. 241-244. [Williams, 1985b] Williams, Michael R., A History of ComputingTechnology,Englewood Cliffs NJ: Prentice-Hall, 1985.
FORUM ON THE HISTORY OF COMPUTING
805
MICHAEL MARCOT'T'Y
DOCUMENTING PROJECTS WITH HISTORY IN MIND
Michae/ Marcotly 1581 Witherbee Troy, Michigan 48084 Tel: 313-646-9812
Three fundamental questions must be addressed when documenting a project with history in mind: 1. How do we know what is going to be an "historically significant" project? 2. What documents need to be retained? 3. How should documents be retained? The following notes reflect my personal perspective. I look forward to discussing them with Forum attendees and to learning additional insights. 1. How do we know what is going to be an "historically significant" project? Every project is significant, and deserves to be documented from the beginning in that way. Only time will tell whether it has historic significance and even then it will depend on point of view--work group, company, discipline, and so on. In any case, I believe that this is an irrelevant question. I will argue that maintaining documentation, as though the project will be historic, makes good sense from general principles of computer science; it certainly does from the point of view of software engineering. Behind every project should be a database of information about that project. In other words, document every project well for the sake of the project itself. Then, if the documentation is also needed for historical purposes, it will be available. 2. What documents need to be retained? a. Probably the most important class of material records the reason why things were done. Why was the project undertaken in the first place? Why was the particular design chosen? This will include contextual information such as other known similar parallel projects, discussion with others, and other outside influences. Why was the particular hardware configuration chosen? Why was the particular programming language chosen? b. Almost as important as recording the reason why things were done, is to record why other things were NOT done. This means preserving copies of ideas or suggestions that were considered but rejected, along with the reasons for the rejection. c. Material that records the expectations of the project's initiators, workers, and expected clientele. d. Names of people involved on the project and their responsibilities. This list should include clients, instigators, senior managers, as well as participants. Also recorded should be changes in personnel, in all these areas, over the life of the project. This list is likely to make it easier to ask questions in the future. e. Specifications--together with reference material that explains the notation. f.
806
Scheduled project milestones, forecasted and achieved. It is also necessary to record "unscheduled events" and the reasons (or at least the rationalizations) why milestones were missed or late. CHAPTER XVl
PAPER: DOCUMENTING PROJECTS WITH HISTORY IN MIND
g. Copies of mandated technical standards, both corporate and external, together with company and project manuals of style for both documentation and programs. h. All project publications, particularly including early versions. i. Description of the standard procedures used by the project for the maintenance of the project's database. j.
Description of the processes used for validation and verification of the project's work. Included here are the acceptance tests and a record of their performance.
k. Records of how, and why, the specifications for the project changed during the life of the project, including what changes were made after the first version of the project was released. i. Major deliverables, together with client and management reactions to them. 3. How should the documents be retained? This will include a discussion of what to retain and what to discard. A discussion of the appropriate media: paper, machine readable, photographic, video recording, will be included.
FORUM ON THE HISTORY OF COMPUTING
807
J.A.N. LEE
ISSUES IN THE WRITING OF CONTEMPORARY HISTORY
J.A.N. Lee Editor-in-Chief, IEEE Annals of the History of Computing Department of Computer Science Virginia Tech Blacksburg VA 24061-0106 e-mail: janlee @ vtcsl.cs.vt.edu
There are several factors that influence one's interest in, and the potential for writing a paper in, the area of contemporary history. In the beginning is the mere curiosity to learn of one's technological forefathers and their contributions to the present-day science. Such a curiosity may initially be fulfilled by examining the technical literature of the subject, such as may be found in an annotated bibliography, or in the list of a pioneer's publications. However, technical papers, as may be published in the journals of the ACM and the IEEE Computer Society, are the record of the successes of research and development, but they usually contain little of the background or environment that spawned the activity, nor an assessment of the potential impact of the element on future developments. Historical writing then has three responsibilities: To rediscover and document the environment in which the activity or discovery occurred, and to assess the influence of the environment on the action and its "downstream" impact; To recover the stories of the false starts, the failed attempts, and the unsuccessful trials that channeled the activity into its successful actions; and To evaluate the impact of the activity or event in the light of more recent developments. History that is a mere chronology of events or actions is of little interest or value to the present day scientist or student. The memoirs of pioneers are often little more than a liturgy of their high points, and they are afraid to "toot their horns," or evaluate their impact, when their contributions, viewed in the light of today's technology, appear to be less significant. Although journals such as the Annals will accept, and even encourage, pioneers to record their memoirs, these should be looked on only as the starting points for further scholarly work. It is the responsibility of the modern computer historian to put the work of our pioneers in perspective, to apply to history the same scholarly standards as would be expected of technical papers in technical journals. As a service to the field, a scholarly history provides insights and views of our past that can often be used today. In many ways our technology is an onion to which we add additional layers with each passing (technological) generation. The core can be very simple and straightforward, but we add complications in the name of "ease of use" or "user friendliness" that mask the real nub of an idea. In today's teaching we too often start at an intermediate point of development and ignore the simpler solutions to a problem. Historical writing provides the pointers back to reveal solutions that were rejected and that may now be applicable in the newer world of (say) massively parallel computation, or expert systems. The pointers also provide a path to the foundations on which "modern" ideas are built. Educationally, we need to think carefully of where to start on the road of development and to decide consciously whether we can afford to ignore the past, and often the simpler times. We can visualize the "perceived complexity versus time-since-origination" relationship of a concept as being represented by a parabola. In the beginning, the perceived level of complexity of a concept is high, as the supporting materials are sparse, untried, and often unrecognized. As the idea 806
CHAPTER XVl
PAPER: ISSUES IN THE WRITING OF CONTEMPORARY HISTORY
gains a foothold, new authors provide their interpretations, and the perceived complexity diminishes to the point where the applicability of the concept to the practical world is recognized. The first implementation probably represents the point at which the complexity is lowest. As time progresses, layers of"improvements" are added to the object and its core concepts disappear behind a morass of add-ons and so the complexity increases again, and the visibility of the basic idea fades. It is the responsibility of the historian to provide a map of this developmental cycle, and to provide cross-sections of its structure, in order to allow the student to decide where his or her application can find a useful foothold. Guidelines, such as those provided to the authors in the HOPL-II Conference, provide an outline of the questions to be answered and the topics to be considered in developing an historical article (see Appendix B). (An edited version of the the HOPL-II author guidelines appeared in IEEE Annals of the History of Computing [Vol. 13, No. I, pp. 51--62].
FORUM ON THE HISTORY OF COMPUTING
809
DAVID ALLISON
Forum Closing Panel
Panel Chair: Robert F. Rosin
ROBERT F. ROSIN: To those of you who were not with us this afternoon: welcome to the Forum on the History of Computing, which is part of, and prelude to, the ACM SIGPLAN Second History of Programming Languages Conference. This is the concluding event in the forum. It is a panel discussion on "The challenge of public displays about the history of computing." There will be an opportunity to ask questions of the panelists after their presentations. There should be cards available for you on which to write your questions. I suspect that each of us is a museum visitor, some more frequent than others. I also suspect that each of us has attended at least one museum exhibit that includes artifacts related to the history of computing, perhaps at one of the outstanding institutions represented by our panelists. I'll introduce each panelist prior to his presentation. Each panelist will make a presentation and then afterwards will deal with questions. David K. Allison is Curator of Information Technology and Society at the Smithsonian Institution's National Museum of American History and acting Associate Director of the Department of History and Science Technology. Dr. Allison studied at Purdue University, Saint Johns College, the University of Bordeaux and Princeton University, where he earned a Ph.D. in History in 1980, specializing in the history of American science. Prior to joining the Smithsonian staff in 1987, he served as historian with the U.S. Department of Energy as Historian of Navy Laboratories. Dr. Allison's responsibilities at the National Museum of American History include overseeing its collection of computers and computer-related artifacts, documents, images, and media. He also serves as liaison between the Smithsonian and the Annals of the History of Computing. He was chief curator of the permanent exhibition, "The Information Age: People Information and Technology," which opened in May 1990. This 14,000 square foot display surveys the history of information technology and its relations with American society, from the telegraph to the present. With over 50 computerized displays, it is the most interactive exhibition in the Smithsonian Institution. DAVID ALLISON: In setting this session up, Bob posed to us several questions related to the challenge of public displays on the history of computing. In my presentation, I am going to go through those questions and provide my answer to them. The other panelist will give a slightly different slant on the subject. Just by way of introduction, I want to indicate that the largest number of people who find out about the history of computing, probably do so through museum displays. We have had over four million people come to "Information Age" since it opened in 1990. So it is a very important interface with the public.
810
CHAPTER
FORUM CLOSING PANEL
The first question that we wanted to address was, "What is it that makes exhibits successful?" In all forms of museum display, there needs to be a balance between traditional types of case displays, settings and interactive displays, and computer displays. I will be showing you some slides from "Information Age" in a few minutes to give you some examples from that exhibit to make this point. But the temptation of interactive displays should not blind us to the success of other types of museum presentations. There are several ways to use interactive exhibits. One important way is a straight narration in a more interactive form. A video display or video selector that allows a visitor to come and choose the video information he or she wants to see, is very valuable. It often gives people an opportunity to see equipment in operation. This can also be done in a menu-driven computer interactive display. A second technique is allowing exploration of many topics through branching menus. A third form that we don't use as much at the Smithsonian as they do at the Computer Museum, for example, is providing an opportunity to learn some computer skills through interactives. This can involve playing games through interactives, exploring different ways of using software, etc. Unquestionably, when the subject is computers, the use of interactive displays is very attractive. The second question that Bob posed is, "How are computer exhibits different from other traditional displays?" One of the challenges is the limited effectiveness of computer artifact presentations to convey your messages. This gets more and more true as you come closer to the present. As you look at computer displays, or chips, or plain white boxes that seem not to vary from one generation to another, or one manufacturer to another, the story is not told by the artifacts in the way that it is, for example, with machinery of the 19th century. You need to think about ways to bring out the message of three dimensional objects in new and exciting ways. The technique that we relied on most in the Smithsonian's "Information Age" was to focus on applications. Our visitors, who are coming to a history museum not a computer museum, want to know why computers or other information technologies were important. What difference have they made to history? Answering this question means showing the application of this technology to large scale social, political, and other kinds of problems. One of the greatest challenges in interactive displays, which Bob pointed out, is the difficulty in keeping the displays up with the technology. For example, in the "Information Age" we use the IBM InfoWindow system, which IBM no longer services, so we understand the problem of keeping up. There is no easy answer to this question. But, there are techniques that you can follow. A modular planning approach is certainly one good strategy. We use modular planning for the hardware and the software. This means using technology bases that allow you to switch things in and out. Often, museums are tempted to use special-purpose code, because it can offer the cheapest solution. But when the software engineer or the software developer is gone, so is the knowledge of the application. We try to stay away from that in the "Information Age" and follow industry standards, with standardized software components. That has made it easier to switch and move up through generations. Museums that are always trying to cut costs at the front end usually pay the price in the future. Most important, is not trying to upgrade everything that you are doing in an exhibition at once. Plan an exhibition so that you know some of the things will remain static for a very long time, including some interactives. Leave another portion of your exhibits for updating, meeting visitor expectations for showing the most modern technology. Finally, was the question, "Should there be more exhibits about software?" Software is a topic of great interest to this conference. How much should we say about that in the general public museums?
FORUM ON THE HISTORY OF COMPUTING
811
DAVID ALLISON
It is important to look at the subject in two ways. On the one hand, you can see software and software development as a subject. On the other, you can see it as a tool for other applications. Software as a subject, the development of software, the programmer's life, and those kinds of things is of limited interest to the general public. It has a place in our displays, but that place needs to be put in a larger context. We have one exhibition unit that I will show you in our slides, on the subject of software. It's broad in compass. In the Museum of American History that is all that we could afford. On the other hand, software as a tool is a larger subject. Visitors learn about software in relation to its applications in many areas of society. Another way to do better in displays about software, is through computer interactives. We were struggling for better ways to use them. With the advent of better video animation and simulation, we can bring out more of the dynamics of software in a way that visitors can understand. Finally, I think a focus on the human side of programmers and how they interact with society around them, is a way that we can bring out more of the software message. Now, I'll give you a several examples about these points from the "Information Age." (SLIDE 1) This is the introduction to the very beginning of "Information Age." It shows scenes from today's information society. Here, we also introduce the use of information technology with a bar code scanner. There is an individualized bar code on each brochure that people pick up. We can make a personalized record of their visit as they go through the exhibition. This allows people to interact with information technology and also allows us to keep some statistics on them as they go through the display. (SLIDE 2) In using information technology in "Information Age" we wanted to use different ways that people learn. This shows some of them. It is a mixture of the artifactual presentation and interactive presentation. The Hollerith machine is in the background. In the foreground we have interactive displays. You can scan your bar code to record what you are doing there. You enter information about yourself and see what your life might have been like in 1890, at the time of the 1890 census, when the Hollerith machine was first used. Our goal was to connect your story as an individual with our story in the exhibition Over to the right-hand side is a video monitor. It is one of our video selectors where you choose one of four video clips about the displays around you. One of the selections is about social security system processing in the 1930s. It, in turn, relates to the scene in the middle of the floor, where a woman is doing social security processing. So, we use different techniques to bring the story to the public and show both the human side and the technical side.
SLIDE
812
1
SLIDE
2
CHAPTER
FORUM CLOSING PANEL
SLIDE
3
SLIDE
4
(SLIDE 3) This scene is on board a combat information center in World War II. It is an example of how we try to use life-size displays. Our general goal was connecting the story of people, information, and technology. Here is a way that we are doing that, with a dramatic presentation. (SLIDE 4) This is our presentation about software. In the foreground are flowcharts, a bit on Grace Hopper, and Jean Sammet's image of the "Tower of Babel" of early programming languages. In the background we carry the story of software from plug wires up to floppy disks. On the back wall are scenes of programmers at work. We also have examples of coding of various eras. In the middle are some examples of manuals and tools. This is a brief display, but it shows some of the tools, some of the applications, and some reflections of software development over time. We talked about including interactives at this location, but frankly neither our fiscal budget nor our space budget would allow it. (SLIDE 5) Here was the scene from the Home Group Computer Club that we used to show the new social environment that led to the creation of early PC technology. In the scene, we have one of the early Apples and an Altair. On the right, we show some of the early developments at IBM, and elsewhere, to illustrate that they were interested in personal computers in the early days, but did not develop viable products. (SLIDE 6) Finally, this is a scene from our interactive gallery. Unquestionably, one of the reasons people come to computer displays is so they can get their hands on computers and do things. We had
SLIDE
5
FORUM ON THE HISTORYOF COMPUTING
SLIDE
6
813
PAUL CERUZZI
visitors from all segments of society from the homeless up to CEOs. Many of the school children, in particular, don't have an opportunity to work with computers at home or school and try new things, particularly advanced things. We try to provide a changing array of opportunities to do that in the Smithsonian. How do you keep something like this updated? It is a lot easier to keep a space like this updated because there is a modular plan. You can replace one computer or you can change an application with very little modification, compared to the static display that you saw earlier. I hope these illustrations have given you an idea of how we answered the earlier questions in our exhibition, "Information Age! People, Information, and Technology." ROSIN: Paul E. Ceruzzi is Curator of Aerospace Electronics and Computing at the Smithsonian Institution's National Air and Space Museum. Dr. Ceruzzi earned a B.A. at Yale University in 1970 and a Ph.D. in American Studies at the University of Kansas in 1981. He was a Fulbfight scholar at the Institute for the History of Science in Hamburg, Germany and he received a Charles Babbage Institute Research Fellowship in ! 979. Before joining the National Air and Space Museum, he taught history of technology at Clemson University. Dr. Ceruzzi's duties include research, writing, exhibits planning, artifact collecting, and public outreach activities concerned with the subject of computing machinery as it applies to the practice of air and space flight. He is the author of several books on the history of computing and related issues, and he served as a consultant on certain computer-related projects, most notably the BBC/PBS Television series, "The Machine that Changed the World," broadcast in this country last year. He also serves as Assistant Editor-in-Chief of the Annals of the
History of Computing. PAUL CERUZZI: I ' m a curator at the National Air and Space Museum, which is the most popular museum in the world or certainly in the US, some 8,000,000 visitors a year. Sometimes in a good year, that comes out to about 20,000 a day, the size of a small town per day coming through. The particular gallery that I worked on called"Beyond the Limits," which is up on the second floor, doesn't obviously get all twenty thousand, but it does get a very large crowd and certainly, the physical design of the gallery was a very important factor in terms of how to manage an enormous number of people coming through. Never mind the subtle questions of what are you going to tell them about programming languages. I'll get to that in a minute. But just physically getting them in and out without them feeling claustrophobic or getting hurt. There are serious issues that we struggle with. If you have any time left over then you start tackling the content. It is quite a challenge and there is nothing quite like going in there, as I do. I don't know whether I should feel guilty or not, but I do go in there. I take my badge off and I just wander around and look over people's shoulders to see whether or not they are enjoying themselves. Many times they are, not always. Sometimes you have kids say, "Oh this is so boring." But, when they do enjoy it, I feel good and I feel we have accomplished something. I had prepared some remarks about software and when I got your query, Bob, I kind of restructured it a little bit. I thought I would take some of the issues in somewhat reverse order, here. "Why do so few exhibits focus on software?" I guess that was one of the questions I have been struggling with. I think one of the obvious answers is that we can get philosophical here, which we don't want to get too much. But, by definition, "software is invisible, it is a soap bubble," I guess, is what Allen Perlis said. If you can put your hands on it, it isn't software anymore. A museum by contrast, in this age of DisneyWorld, and Hollywood, and virtual reality, and simulations, and everything else, a museum seems to be the last place on earth where you can see real things. There are fake frontier lands and things like that. There are fake airplanes in a lot of places, but the Air and Space Museum has real artifacts and we never want to lose that. Even though we have a very vigorous program of interactive programs and films, we have an Imax theater which is a huge crowd pleaser, all those things, but they 814
CHAPTER
PAPER: ISSUES IN THE WRITING OF CONTEMPORARY HISTORY
"mediate" between the reality and the visitor. One of the things that is so amazing about the Air and Space Museum is its opening main hall where we have these wonderful icons of the air and space age. The Wright Brothers' airplane, the Spirit of Saint Louis, the Apollo I I capsule, and there are almost no labels at all. If you can find them, they are very small. You just walk in and you are immediately confronted with the reality of an object. We have been criticized for that, because we don't provide context and we don't provide the political and social dimensions, and all that. Those are valid criticisms. Still, the popularity of that hall really says something. That there is something to be said for just direct experience with the three-dimensional artifact that has a place in history, and we never want to throw that out no matter how much we are conscious of the need to interpret things. In designing the "Beyond the Limits Gallery," I wrestled with these questions, not only the fact that a computer is not always that interesting to look at, although packaging is a very interesting question. Of course, those of you who are in the computer business know that successful packaging can make a huge difference in the success or failure of a product. And it is no coincidence that Ken Olsen, when he was at Digital Equipment in the early years, took a very active role in the packaging of their minicomputers. In general, the current scene, the packaging,just does not really help you very much. It certainly doesn't give you a sense of what the power is of what is going on inside the computer. I want to tell a little story because it does fit into the theme of what we are getting at. During the research for this gallery, I had heard about the famous Mariner I hyphen, the missing hyphen in the guidance program that caused the spacecraft carrying Mariner I, which was intended to go to Venus, it caused it to crash into the Atlantic Ocean. Later found out the cause of the crash was a missing hyphen in the program. I tracked down the man who left out the hyphen from the program. He works for TRW in Los Angeles. I wasn't allowed inside the building, but we met in a hotel by the airport. He told me the story. He pulled out his wallet where he had the newspaper clipping from the New York Times that described it. Yes, it really did happen, but no, it didn't get into the exhibit, "Beyond the Limits." I just couldn't figure out a way to explain this without writing a big, long story and you just don't do that in an exhibit. You don't write large reams of text. It did get into the catalog that goes with the exhibit. I assume that some people who visit the exhibit will buy the catalog. But, it just couldn't get in there. I tried and thought about it and have to admit, I failed, even though it is a wonderful story. There is a General in the Air Force, I forget his name now, but I participated in an interview with him a number of years ago where he showed a framed hyphen on his wall because he was involved with the program and I guess he keeps that as a memento. One of the things that I want to emphasize on getting back to the issue of software, is that for me, personally, it is a distinction, which, as important as it is to you, as important as it is to the organizing of this conference, as a professional historian trained in American studies and history of science and technology, I find that the distinction is somewhat less useful. I use as an analogy the generational model of hardware. It is a wonderful idea for computer engineers to talk about first or second generation; it just confuses the heck out of historians who try to tell the story of the history of computing. Dividing computing into hardware and software, I found, has caused more problems to me than it is worth. I try to avoid that in my writing and in my exhibit work and in anything else I do because, again, I ' m mindful of the public who are, and this from Strunk and White, who say, "90 percent of the time people are totally baffled." If that is true of writing, it is even more the case of exhibits. People are confused and they want some guidance. First of all, they are in a big crowded place and they don't have very much time. I try not to complexify things too much. Software is of course very critical to the working of the computer system and there I try to tie it in with the themes that are familiar to museum-goers who remember the classic halls of machinery like steam engines, railroads, and automobiles, and things like that, where you use a set of classic definitions of a machine as something where you channel forces of nature into a particular direction to do a specific thing, FORUM ON THE HISTORY OF COMPUTING
815
PAUL CERUZZI
whether it be literally through mechanisms, as in a steam locomotive, or through electricity or something. A computer does not fit that definition. The person who is on a production line making DOS clones, for example, doesn't know that the person who buys that computer is going to use it for this or for that. That moment comes when the software is loaded into the machine. But, having said that, again, what is important is what the machine is used for, what does it do? In order to consider that, you have got to consider the whole ensemble of hardware and software. I noticed something else. I have been looking recently into the OEM phenomenon being here in the Boston area, I have been doing a little research about that. I realized that OEM people did something very akin to developing software when they developed specialized pieces of hardware that they would build around something like a PDP8 minicomputer. They put hardware around it and then added customized software. The end result was a special-purpose machine that did some very specific jobs for a specific customer who really didn't know or care what was deep inside it. So again, you see the blurring of distinction. I like that blurring of distinction. The more of that I find, the better. The more that I can convey to the public, the notion of the computer being a way of channeling the forces of nature, what we can do with nature in a specific direction to solve a specific problem, the better, because I think the public can understand that. They can also understand that if you don't use the word, every machine has a software aspect to it. There are rules of how you use things: you don't press this button before you press that button. You don't put your car into reverse when you are going forward at 60 miles an hour, or something like that. Every machine has it. Why make an artificial distinction if it doesn't help you so much. Well, that has sort of been my philosophy. I also wanted to mention one other thing. Again, coming from a museum of technology where we have this long tradition that Mike Mahoney talked about, of things like Henry Ford's work, I am very fascinated about the way Henry Ford's experience with the mass production techniques for the model T, how he seems to have solved all the problems early in this century. It seemed like he had solved all the problems of human want and need by producing high quality products at low cost in large volume. Then what happened to Ford? The company almost went bankrupt because they could not adapt themselves flexibly to the changing conditions and the personal needs of the marketplace. Now, along comes a computer which, by definition, you can change by just reprogramming it. Of course, there is the sort of bugaboo, because reprogramming it seems to be so simple, but in fact, it isn't. If Professor Brooks speaks about no magic bullet, I think you all know how hard it is really to write programs that zero in like a laser beam on someone's specific problem. But, the point I want to make is that all of this that is so wrapped up in the energies of software development has a long tradition that goes back fight into the time of Henry Ford's struggles to keep the ModeI-T viable, and his competition with General Motors who were introducing annual model changes, and things like that. I will move on to some specifics about the way we designed the exhibit at the Air and Space Museum. I looked around the museum and looked at the crowds in particular and had long discussions with the designer--we were really sort of partners in all of this. We came up with some rules which are a little bit unorthodox, but I think they withstood the test of time. For me the interactive exhibits, which obviously revealed software as it does something. We kept them very short. Five minutes was about the maximum that we ever had. Three minutes was even better. We tried to have no keyboards, very direct interaction usually with a track ball or a touch screen where in real-time, something that you touched created an instantaneous reaction on the screen. It is no accident that by far the most popular interactive that we have is a flight simulator---one that we have taken from Microsoft but simplified a little bit, removed some of the more difficult things. We have some instructions but nobody reads them. In fact, to the extent that we put any text on the screen at all, I wouldn't say it is a waste because some people read it, but many people don't. Again, you have lots of visitors coming through. They want to get some kind of experience. Now, whether that is a meaningful experience, or not, r l l 816
CHAPTER
PAPER: ISSUES IN THE WRITING OF CONTEMPORARY HISTORY CQr: R O ~ SC~::',',A:IC
2
: SLIDE
1
4
';
I
~. . '. °. . . . .
0
°
J
SLIDE 2
defer to some other people about that. But, they do get a sense of what the computer can do. I know that this is not an orthodox way of looking at things, but I insisted on it rather rigidly and I think it has paid off in terms of the popularity of that exhibit. It has held up very well since 1989. It still continues to be popular. We were compelled to use, in 1989, to go with high-end work stations like Evans and Sutherland for the graphics capabilities. This led to all kinds of maintenance headaches. Especially when companies decided they could, or would, no longer support our application. So, over the years we have been slowly but gradually and inexorably rewriting everything for DOS. In fact, we don't even use Macintoshes if we can avoid it. Just DOS clones that you can buy cheaply and program them. We can program them in-house, and we control all, and we keep the cost down and we are flexible that way. We have had to sacrifice a little bit of the glitz, but for a museum like ours, that is not a problem because we make up for the glitz in some of the other things that we can do. Let's have the first slide. (SLIDE 1) I looked for something about software that I actually show in the exhibit. This is a piece of core rope. This is core rope that was prototyped for the way the Apollo guidance computer was programmed to go to the moon. They literally wove wire and if a wire went through the core, it was a binary one. If it went around the core, it was a zero.
SLIDE
3
FORUM ON THE HISTORY OF COMPUTING
SLIDE 4 817
OLIVER STRIMPEL
SLIDE $
SLIDE 6
(SLIDE 2) So, I do have one example of an artifact. Here comes the philosophical question. Is it software or is it hardware? It is a hardware realization in the core rope. How many people understand that subtlety, I really can't tell you. (SLIDES 3 and 4) Which would you rather see? You come to the Smithsonian with your kids or family, do you want to see what is pictured in slide 3 or slide 4? (SLIDE 3) I have to apologize. This is not yet on public display but it will be. An SR 71 designed by a man named Kelly Johnson who worked with a slide rule, by the way. Tells you what you can do with a slide rule. What we do try to show is the way the computer, especially computer graphics, has been used in aerospace. I am echoing what David said: we keep drilling the application of computers. (SLIDE 5) Shuttle reentry. It is popular. We have this on a Silicon Graphics workstation where visitors can manipulate this image. That is one of the very few that we haven't been able to port to a DOS machine yet. But, we probably will soon. Silicon Graphics has been working with us. But again, we have to go to them and ask for their help whenever we want to make changes to this program. We are trying to get as far away from that as we possibly can. (SLIDE 6) This slide shows another graphics application, in fluid dynamics. So to sum up, I think the Air and Space Museum is somewhat of a unique place where we have self-selected visitorship of people who already know that they are going to see high technology when they come in. So we don't have that problem to the extent that is a problem for other museums. We have a basic subject that is inherently exciting and we don't have to worry about making it more exciting, namely, air and spacecraft. We have ways of showing the applications. It allows me to think more about some of the philosophical implications. I may not have succeeded at, but at least, I am making a try. Oliver B. R. Strimpel is Executive Director of the Computer Museum in Boston. He spent his early years in India and Italy before earning degrees in the Sciences in Cambridge University and Sussex University, and a D.Phil. in theoretical astrophysics at Oxford in 1979. He was curator at the Science Museum of London where he helped set up major exhibits including "The Challenge of the Chip," before becoming the curator at The Computer Museum in 1984. Dr. Strimpel was responsible for The Computer Museum's most successful permanent exhibitions, "The Computer and the Image" and "Smart Machines." The more recent "Giant Walk Through Computer," which opened in 1990, was also Dr. Strimpel's idea. His leadership has moved The Computer Museum into the forefront of ROSIN:
818
CHAPTER
PAPER: ISSUES IN THE WRITING OF CONTEMPORARYHISTORY
interactive computer exhibit design, and the museum now exports exhibits to other museums and technology centers around the world. OLIVER STRIMPEL: David and Paul have said a lot of very interesting things about the challenges of building effective exhibits. I want to cast them in a slightly different way. You have heard a lot about the need to get the context of an exhibit across to people. Museums can communicate with people by letting them experince things first hand. We learn from books, television, other media, talking. (OVERHEAD SLIDE 1) But in museums you have a chance to experience things, whether it is an original artifact, something that is huge, or something that you can do. That is the first challenge of the public display about the history of computing. How do you make it into an experience? The second challenge of public displays is dealing with an audience composed of a huge array of different ages, knowledge, and interest in the subject. (OVERHEAD SLIDE 2) Museums like the Smithsonian and ours attract visitors from around the world. We are talking about people with dramatically different cultural backgrounds, as well. The second challenge is: How do you have something for everybody? The third challenge is something that Mike Mahoney talked about this morning and in a paper he wrote a while ago, which is the issue of how do you get people to think about history from the framework of the time and not by hindsight? Is everything leading inexorably to the present? Basically speaking, we find that our visitors are really looking for evidence to show that history was all leading up to the Apple Macintosh and the 486 PC. So, the big challenge is, how do you get them to think about it a little bit from the point of view from the people who were doing the work at the time? The final challenge that I want to refer to, is perhaps, the most obvious one, which is of showing original artifacts. That is one of the key ingredients of the museum experience. But, despite the recent nature of this history, these artifacts are sometimes incredibly elusive. As Gwen mentioned earlier, we had a very difficult time finding a UNIVAC I. We wanted to show in our exhibitions machines that come from other countries and, specifically, a lot of pioneering work that was done in England. In fact, our initial plan was to show the Manchester Mark I, but there isn't very much of it left. What there is, is treasured by the University of Manchester. The Smithsonian and The Computer Museum are perhaps best equipped in this country to deal with this challenge because we started collecting
TYPESOFTHINKING reflective experiential
AUDIENCE knowledge ~teres
I age
OVERHEAD SLIDE
1
FORUM ON THE HISTORYOF COMPUTING
OVERHEAD SLIDE
2
819
OLIVER STRIMPEL
before everyone else. But I don't envy the person who wants to develop a display about the history of computing in another place. The early artifacts are very scarce and those which are on display are not usually available for loan. How do we meet some of these challenges? One way which hasn't been talked about that much so far is the idea of making something work. One way to get an experience is to see a computer actually doing something resulting in motion. Quite a dramatic virtuoso effort in this direction is just being completed by the Science Museum in London, which recently reconstructed Babbage's Difference Engine #2 at a cost of about half a million dollars. That is on display in London now and has attracted very widespread interest. It is one of the few computing devices whose physical appearance reveals something about its purpose and how it actually functions. Pegasus is an early machine that the Science Museum has actually managed to get running. It is not on public display. Paul mentioned the PDP-1 which we have running at The Computer Museum, but it is not on display. (SLIDE 1) One machine that we did have on display at The Computer Museum for a while was a punched card machine. This is none other than Mike Mahoney punching his own card, just in case he can't remember what it was like! That was an exhibit that would make all of us who used punched cards in earnest run a mile from. But it was incredibly attractive with the children of the post-mainframe era. They have never used a punched card machine before. It moved, clicked, you could see the holes in it. It was a hands-on interactive exhibit, one of the most popular in The Computer Museum, believe it or not. A simple working punched card machine. (SLIDE 2) This slide shows another way to make machines work a video of them working. This is our Smart Machines theater, which is a collection of historic robots and computer-controlled devices. They are all labeled in front and come from many different places including Stanford, Carnegie Mellon, MIT, and Japan. Those of you who will come to the Museum tomorrow night will get a chance to see all of this. If you can't actually make a robot work, the next best thing is to show a video of it working. The other way to meet the challenge of giving a diverse public a real experience is to link it to a compelling application. David and Paul have talked a lot about very compelling applications. In Paul's case, the aerospace application is very gripping and really engages the public extremely successfully. The World War II application and robotics and other examples at the National Museum of American History also engage people very effectively.
SLIDE 1 Visitor exploring punch card installation at The Computer Museum in the 1980s. Credit: J. Wayman Williams
820
SLIDE 2 The Robot Theater in the Robots & Other Smart Machines T M Gallery. Credit: Marjorie Nichols
CHAPTER
PAPER: ISSUES IN THE WRITING OF CONTEMPORARY HISTORY
Milestone 4: the 1960's COMPUTINGMEANS BUSINESS
MILESTONECOMPONENTS Context-selting "tunnel" Vignette Social impact then Social impact now Hands-onexplanation of the technology Videos on: people: inventors, users technologies popular culture
OVERHEAD SLIDE 3
tunnel:
Beatles song Imagesof large office buildings
vignette:
IBM Syslem 360 insurance companyapplication
impact lhen:
airline reservations
impact now:
mass mailing,junk mail
didn't make it: PL/I, DvorakKeyboard, MOBIDIC, t 2-bit computers light pen, mini punched cards pitfalls: "Tell your own tale" of computer snafus OVERHEAD SLIDE 4
(OVERHEAD SLIDE 3) We took that approach too at The Computer Museum with our major exhibition of the history of computing called "Milestones of a Revolution," which we opened two years ago. We selected nine milestones from the entire history of computing. Each milestone had several components. I'll go through them to try and explain how they arose. They really arise directly in an attempt to meet the challenges that I mentioned earlier. First of all, the context-setting tunnel. This is an attempt to acclimatize visitors to each milestone before they came to the vignette depicting the milestone. Second, we didn't display artifacts on their own sitting on the carpet or in a case. We displayed them in a vignette complete with manikins and ephemera from the time. Then we had two themes in each one which were very explicit attempts to show the social impact of that particular milestone. Social impact thenwwhat impact it had on people at the time; and social impact n o w - - w h a t present-day application emerged from the milestone. The slide shows "hands-on explanation." The virtues of hands-on interactives have already been extolled, and they are very effective. We have used that technology here to try and give people a better sense either of technology itself, or what the technology was used for. Lastly, we have interactive video in each milestone. David said they found interactive video very successful in the "Information Age" exhibition. Each video station offers clips of the people, the inventors, the users, the technologies, and popular culture at the time. (OVERHEAD SLIDE 4) Let me give you an example of a vignette to show how we actually fleshed this out. In the case of the 1960s, we selected the IBM System 360 as the focus of that era. In the tunnel you can hear a Beatles' song as you approach the vignette. You can see images of large office buildings giving the feeling of the growth of big business. The vignette itself is of an IBM 360/30. This is a good example of the challenges of finding artifacts we didn't expect to meet in this particular vignette. We thought that there would be hundreds of IBM 360s around in good working order. In fact, we had one of our Board members from IBM who said, "No problem, I'll just look in the databases at IBM and look at the ones that we service." He looked through three separate databases, each of which had several sets of 360s that were supposed to be in the field. It turned out, in the end, that there was only one System 360 and it was still working--running in 1401 emulation mode. This was in 1990. Our assumption about the easy availability of a System 360 was wrong. We went to this company, which was a market research firm on Wall Street. IBM said to them, "Look, we will replace
FORUM ON THE HISTORY OF COMPUTING
821
OLIVER STRIMPEL
this for you and you will save in a month of maintenance, the entire cost of the new machine." It was with incredible difficulty that we managed to pry this last 360 out of them, just in time for the exhibit opening. To help visitors see the machine in context, we simulated an insurance company application. This is not a compelling application, but we were not able to think of very many compelling applications for machines in the '50s and '60s. The wider social impact of the day that we selected was airline reservation--the SABRE system--which was started at that time. We picked junk mail as a descendent phenomenon that stemmed directly from the kind of business data processing that really gained prominence in the 1960s with the 360. This is shown with a pile of junk mail that lights up behind a partially silvered mirror after the viewer presses a button. To try and meet the challenge of people's revisionist interpretation of technology's forward march to the PCs of today, we showed some technologies that didn't make it: PL/I, Dvorak keyboard, MOBIDIC which was the tractor trailer-sized mobile computer for the military in the 1960s, 12-bit computers that were supplanted by the move to the 8-bit byte standard, the light pen and the mini punched cards from the IBM System 3, which were an attempt to keep the punched card technology going beyond its day. We also have an interactive in which people can see tales of computer errors and write their own stories about the things that have happened to them in which computers have made mistakes. That is surprisingly popular. People all have some horror story to recount. (OVERHEAD SLIDE 5) The overhead shows the range of videos that we were able to assemble for this period. We try to show the technologies themselves using a humorous touch wherever possible. Life before timesharing is really about the hazards of dealing with punched cards. The main protagonist in one film is carrying large decks of cards which, predictably enough, get shuffled up when he stumbles. It is quite hilarious, as are some of the popular culture examples. The videos help bring it to life and help provide the context. (OVERHEAD SLIDE 6) For the 5-10 percent of the visitors who really want to know the details, we have a specifications sheet for each of the milestone machines. We also have a comparison in which I am afraid we might be slightly guilty of making the assumption that the IBM 360 was leading
"l'hc 1960's VIDEOS Technologies - A n n o u n c c m c n l o f thc IBM Systcm 360 - Apollo Guidance C o m p u t e r - Life before timesharing - Dartmouth d m c s h a r i n g - E R M A : automatic banking Peoole - T. J. Watson, Jr., o n automation - Union official on automation - Jerome Weisner, President o f MIT, on the thinking machines Poi3ular Culture - T V show: Monkees vs. Machine - "l~othpastc commercial - Digicomp: toy for Ihc computer age
OVERHEAD SLIDE
822
5
CHAPTER
PAPER: ISSUES IN THE WRITING OF CONTEMPORARY HISTORY
SPECIFICATIONS I w t ~ J m Iklln* ~
t~
~
I~ IST, ~ N l y
,hmmI~i'L Imtmm~ F
t m II**~t se m atl~*.It, j w
l~eee s h e
t,~ d lm,~
~
t~nal~,~
ty.~ ~
ew~
~¢ue,
~
maTtts,
OVERHEAD SLIDE 6
~eet.
SLIDE 3 IBM 360 installation (showing technician installing cabling for a new tape drive) in People and Computers: Milestones of a RevolutionTM exhibit. Credit: David Bohl
inexorably toward the PC. But everyone does ask, "How does this machine compare to a PC of today?" The answer is it was about five times as powerful, for a cost of $7,200 a month in i 965. (SLIDE 3) The slide shows the vignette--the 360 and the manikin putting the false floor cabling underneath. Another challenge of public display, if you approach it this way, is to make sure, if you build a manikin to put it far enough away from the school kids so they don't pull the head of the manikin off. We learned this the hard way. (SLIDE 4) In a slightly more recent era (1966-1967) the vignette application gets a little bit more compelling. Here we chose brain surgery, which really gets visitors' attention. The computer itself
SLIDE 4 Milestone exploring the use of Digital Equipment Corporation PDP-Se minicomputer in surgery (People and Computers). Credit: David Bohl FORUM ON THE HISTORY OF COMPUTING
SLIDE 5 COBOL display (People and Computers). Credit: David Bohl
823
OLIVER STRIMPEL
SOFIWARE operating systems [ programming languages ~
more experiential
applications
OVERHEADSLIDE 7 becomes less prominent physically and the application gets more prominent--and that is really one of the main changes that took place with the embedded minicomputer. (SLIDE 5) I want to talk a little about the challenges of software display. Our exhibits talked a lot about applications. They talked less about programming languages and even less about operating systems and systems software. The Milestones exhibit does have a milestone on the invention of high level programming languages in the late '50s. (OVERHEAD SLIDE 7) We focused on COBOL. When you press a button you can see how one simple COBOL expression codes for the same thing as that long list of machine-specific text that was assembly code for each of the IBM 709, UNIVAC I, and the RCA 501. The display conveys the purpose of portability and higher level programming languages as simpler means of expression. (SLIDES 6, 7) We also explain what a programming language is with an interactive station. Visitors write a little program to get this little car to go from the beginning of a maze to the end of the maze by turning fight or turning left. You would be surprised how many people actually get an introduction
SLIDE 6 Screen shots from interactive computer stations that address running a program and programming languages (People and Computers). Credit: Peter Yamasaki
824
SLIDE 7
CHAPTER
TRANSCRIPT OF QUESTION AND ANSWER SESSION
SLIDE 8 Viewinside The Walk-Through Computer.TM
SLIDE 9 Visitors inside The Walk-Through
Credit: Richard Fowler
Computer. TM Credit: Richard Fowler
to debugging as well as programming when they do this, even though it is a very simple task. At the end of the program the exhibit takes the instructions that they have just written and passes it into an animated meat grinder. Out comes the machine code. This is a way of making an abstract idea--the difference between high-level and low-level langauges--meaningful to the nonspecialist. (SLIDES 8, 9) The Museum also shows something about operating systems and programming, implicitly through the giant Walk-Through Computer, which is a two-story high model of a desk top computer. In the next slide, you can see inside the computer. The giant processor there is laid out in the foreground of the picture. Projected into the microprocessor is an animation showing what the computer is doing. It is running an application that visitors have used before they enter the large-scale computer, and inside they can actually see how the data gets passed around. So there is an implicit description of some aspects of systems programming and what happens with registers inside the microprocessor. I am very glad to say that on the occasion of the reception of this conference tomorrow evening, we are opening our first-ever exhibition of programming languages. My thanks to our Conference Program Chair, Jean Sammet, who is also a board member at The Computer Museum, who made this exhibition happen. I look forward to opening it with all of you tomorrow night.
TRANSCRIPT OF QUESTION AND ANSWER SESSION ROSIN: From DOUG ROSS (SofI'ech at MIT) to David Allison: Please define"cases," and "settings" as types of displays you said to mix. ALLISON: That is museum jargon. What we mean by cases are artifacts and images brought together for reasons of presenting a specific subject. They were not necessarily together in the time that they were developed. So, you may have a case on software where we bring together a manual from one place, a floppy disk from another, and you would explain them with labels and so on. A "setting" is where the presentation is, as something occurs, which is what you saw with Oliver's display about an FORUM ON THE HISTORY OF COMPUTING
825
TRANSCRIPTOF QUESTION AND ANSWER SESSION
office setting which includes a desk, a manikin, and other things to present a scene as it once existed. So those are the two types of displays that are generally mixable. ROSIN: From J.A.N. LEE directed to the entire panel: Isn't one of the major challenges the funding of exhibits? STRIMPEL: We were very fortunate at The Computer Museum to get major support from the National Endowment for the Humanities. Their only string was that we include humanities themes in the exhibit, which we wanted to do anyway. Martin Campbell-Kelly's pie diagram showed that the history of computing really does fall squarely across a number of different areas which includes humanities areas. One of the questions that we often get is, "Don't you get a lot of pressure from your funders to bias the content of the exhibition?" We are fortunate not to have experienced that. People are very respectful of the need for integrity and objectivity of display in a public institution. ALLISON: I don't think there is anything to say other than that the problem of funding exhibitions is universal. Almost any exhibition requires outside funding if it is going to be more than a single case. So that is true in exhibits about the Presidents, exhibits about anything. It requires some outside sponsorship, be it a foundation or a corporation, or anything. ROSIN: From FRED BROOKS to Paul Ceruzzi: Explain the context of the missing hyphen. What should the expression have been and what was it?
CERUZZI: I could say go read my book, but I can try to do it in a very brief time. It was not really a hyphen, it was a bar written over the letter "R" which means take the average value of something that was coming over a radio link that was widely fluctuating. The bar was left off, so instead of taking the average value it simply picked off whatever value happened to be coming down at that particular microsecond. That was widely fluctuating, so the rocket started [having problems], and the range safety officer ordered it destroyed. It was literally a bar. Of course, the other interesting thing is that it was not a FORTRAN program but it was in the equations which were then coded correctly by a coder. It wasn't FORTRAN; that has been wrongly reported in the literature. But I straightened it out. ROSIN: That question was just perfect for this kind of audience. It really highlights something that is reflected in all the other questions that I have received so far. Let me read them to you without asking you to answer them immediately. HELEN GIGLEY asked, in response to David Allison's remarks, but I am sure she'd direct this question to all the other speakers as well. "Do you have any ideas how to make such things as software or natural language processes more visible to the general public?" RALF BAYER from Motorola, asks, "How are the difficulties in presenting software in an exhibit related to the difficulties in presenting literature?" JOHN GUIDI asks, "Can you share with us any thoughts or ideas you might have that would present the software construction process? In addition to ideas that might work, what in your opinion should be avoided?" I am going to turn these questions over to the panel, but I want to put these in the context of a metaquestion. It occurred to me while listening to all of you that the title we used in framing this session, in fact, was very telling. It included a word that many of us in the computing field are very sensitive to, but I think I was ignorant of when I helped write the question. That is the word "public." All of us software folk, I suspect, have felt a certain amount of frustration, no matter when we began in this field and no matter where we are today, in trying to explain to people close to us what it is that we really do. What is software? I have a nephew who was once asked what his father does. His father is an attorney. And at the age of six he said, "My daddy makes A,B,C's." I suspect if anybody asked one of our kids at that age what we did, it might get the same answer, or "My m o m m y is typist," or
826
CHAPTER
TRANSCRIPT OF QUESTION AND ANSWER SESSION
something like that. I have never been able to explain to my dear ones really what it is I do when I think I am creating software. I sense that in all of these other questions. So, in a sense the question we are asking is not, "What can you people do in talking to the public to help them understand what we do," because you have told us pretty well that the public in general doesn't care what we do. The question I would ask all of you, and my apologies to the people who wrote these specific questions, is what do you suggest that we can do to help the public better understand software? CERUZZI: I wouldn't want to tell you what to do because you do what you do well enough or not well enough, without my advice. I am not really that presumptuous. The only thing I would do is reemphasize what I said earlier, that is, the distinction between software and hardware is probably confusing to the public. That is my personal opinion. Maybe the business that you are in is designing machines that perform work for people that make life better than without it. That is a Dick Rubinstein comment, "Using a computer should be easier than not using a computer." ROSIN: I have to go back to John Guidi's question which was very particular. He said, "Could you share with us any thoughts or ideas you might have about what would present the software construction process," which in fact is what a lot of us do. Not what the effect of software is, and not what the result is, but the process. This is at the root of all of these questions. ALLISON: The answer to that particular question, and also an answer to the more general question, can be found in what Oliver said, that the techniques that we use are: simplify, use analogies, make it visual, and make it experiential. We do that over and over again. How can you simplify it? Think of the analogy of moving that program that you showed--which was not really writing a software program, but think of an analogy that somebody does understand. If you can accomplish those things, you can begin to reach out to a public that you can't reach out to otherwise. Also, use techniques in areas that you know they are interested in and reach out through a relationship to a person, rather than to a program, and through a person and the person's need into the program, or something of that sort.
STRIMPEL: The process of constructing a program is something that is hard to make experiential, unless you actually do it. I would like to see the general public and children to have more access to people who do write programs for a living, perhaps sitting with them as apprentices. There is a lot of inexplicit knowledge, as Mike Mahoney said at the beginning of this conference--all kinds of things that are not in the manuals. I am not sure whether a museum display is the right place to actually deal with this topic. On Bob's question of what people like you can do to help explain these topics: I think that sitting on advisory committees and helping us make exhibits that attack the problem from many angles, as Jean has just done with us, is something that is a very tangible contribution. I would urge you all to help us think through the ideas. ROSIN: Let me go back to Helen's question. "Do you have any ideas on how to make such things as software or natural language processing more visible to the general public?" I think the emphasis there is on the processing of natural language. How can you make something that people cannot see, understandable to them? ALLISON: You have to figure out an analogy that they can visualize. To actually solve that specific problem would take some brainstorming. Interactive technologies and animation techniques are some of the great tools that are becoming more available and more affordable and can help to make this happen.
FORUM ON THE HISTORY OF COMPUTING
827
TRANSCRIPT OF QUESTION AND ANSWER SESSION
STRIMPEL: At The Computer Museum, our best effort in solving that problem was to make "The Walk-Through Computer" work both with the program outside that you use and then see the actual program being executed inside with the instructions being fetched from RAM, taken to the processor, executed, data being pulled from the disk. That was the best way we could think of to make it visible. Still, it is not three-dimensional and not as muscular as one would want but it is a step in the fight direction. ROSIN: I ' m going to present Ralf Bayer's question one more time. "How are the difficulties in presenting software in an exhibit related to the difficulties in presenting literature?"
CERUZZI: I ' m not sure that we ~ctually present literature in a museum context. Again, I want to emphasize that a museum is a special place because of the fact that it is where you see artifacts and you don't see words or other forms of communications. Of course you do see words, and you do see films and videos and other things like that. If that was your question, it is a very similar problem and I don't have an easy answer to that, nor can I say that experience that other museums have had in trying to present that, have really helped me very much in presenting software. ALLISON: Probably the best visualization of literature are movies good film that starts off with a very critical problem that software is a spacecraft into orbit or something like that. This could follow dramatically effective movie script. Such a presentation could be a something that we would be happy to show.
based on novels. I think that a used to solve would be putting the process step by step in a great addition to this field and
ROSIN: From RICH MILLER at S H C Systemhouse: Programming is the creation of "a list of instructions." Has that analogy ever worked? Does it go far enough? Oliver, I thought I saw that in several of your slides. STRIMPEL: Yes, we have tried to show that with the programming of a car station and there is another example in which visitors do a series of instructions that you will see when you see the new exhibition that will be unveiled at The Computer Museum. ROSIN: There are several suggestions we have now for solving the problem. For Oliver, has there been any user-testing results of kids and adults seeing the Walk-Through Computers? Did they get what you intended?
STRIMPEL: Yes,actually we have done summative evaluation--evaluating something that has been opened. We found that a surprisingly large number of people didn't realize they were inside a computer when they were inside. And once they were inside, we found something like 20--30 percent thought that the processor was the ribbon cable because it was brightly colored and looked interesting. The CPU itself is a drab grey piece of ceramic, albeit with a screen on it. We overlooked some very obvious things. We did find, however, in the history exhibit, "Milestones of a Revolution," that people actually spent quite a lot longer there than we expected. The average Computer Museum visit is about two hours, and people spend about twenty minutes inside the history exhibit. ALLISON: I think it is something that you don't think about too much if you are not in the museum business. I just want to make explicit--and Oliver referred to this earlier--that the kind of learning that we go after in museum displays is not necessarily conceptual understanding, it is more visual and experiential understanding. So if you ask a visitor, "What did you learn?" often you get a blank expression, because often people don't go to the museum to learn; they say they are going to the museum to s e e or do. They later reflect, or use that kind of information in other conceptual learning. But what they take away from the museum may be a set of images, it may be a feeling, it may be 828
CHAPTER
TRANSCRIPT OF QUESTION AND ANSWER SESSION
something else. That type of learning tends to be undervalued. But it is incredibly important in shaping what people are going to do in their careers and how they feel about things, how they think about things. It is very difficult to measure in a questionnaire something of that sort. But it is an important style of learning that museums are very effective at conveying. ROSIN: I can't resist the reaction to what Oliver said earlier about "dull grey boxes" and "bright ribbon cables." As a dull grey developer, I often felt that way about marketing people who wore brightly colored ribbons.
CERUZZI: I have had the experience since opening Beyond the Limits, of having many adults come up to me and say, "You know I have been working in the aerospace industry for 20 years, and I have been working on these electronic systems, and this is the first time in all my years that somebody has finally recognized what I do and given credit for it. Thank you." They just feel wonderful and it makes me feel great too. They felt undervalued all those years, because they didn't do the sexy stuff like the SR 71 wings or something like that. The message is getting out, but measuring it is kind of hard to do sometimes. ROSIN: I've got two comments to read and then a final question. In fact they really go along the theme that you were just mentioning Paul, I think. The first is a reaction from Fred Brooks to Helen's question: "Using a WYSIWYG editor makes natural language processing visible and little kids do it. (see Allen Kay's priceless video of the three-year-old teaching MacDraw). And here is another one from Charles Lindsey at Manchester, who says: "One way to show people what software is, is to have a real person who will develop short programs to order in real-time. I did this once. My colleagues thought I was crazy, but it worked. For example, I constructed a working 8-Queens in Pascal." And that really leads me to the last question, from R o s s HAMILTON at the University Warwick: "Is the task becoming easier as the children of the post-mainframe era are becoming the parents who bring their families to the museums?"
CERUZZI: It depends on how you define the task. We have children come in, who intuitively seem like they know what to do. I personally feel very strange about whether they are really getting the message that I thought I was trying to convey. That leads me to all kinds of questions about whether I am trying to convey the fight message. I am not sure that I can answer that either. It is kind of a tough one. Let me respond to the other question. This has been very seriously discussed in our museum about having people on the floor doing things, although we didn't mention specifically writing a program. It is a wonderful idea if you can get the money to pay for it. Yes, it is a great idea. I don't know about the others, but there have been many times I have given a tour for a VIP and by the time I'm finished with the tour there is a big crowd of people tagging along listening because they are finding it so fascinating to actually get some live explanation about what all this stuff means that they don't get from the labels. If we could do more of that, we would. But, it costs something. STR~il~EI,: From my perspective, I think that it has become easier to present some of this material to the public. Only a few years ago museums really had virtually no working computers. There was great trepidation: would the keyboards hold up? No one knew how to use a mouse. We were all working on workstations with minicomputers and I remember trying to keep a PDP/70 going to run a graphic display at the museum. It would stay up a few days. The logistical difficulties of keeping interactive exhibits going in museums has decreased dramatically, and as David said they are standardizing everything on PCs. With the convenience of PCs and Macs, we quickly forget the kinds of hassles we have all been through, bending over backwards to get one or two interactives to survive a few days in
FORUM ON THE HISTORY OF COMPUTING
829
TRANSCRIPT OF QUESTION AND ANSWER SESSION
a museum environment. Things really have changed dramatically in that respect. Whether they are really getting our message is now the challenge as we can move more on to the actual education agenda and get away from the logistical challenges. ALLISON: To reflect on what Paul said, the task is increasingly changing. When we did "Information Age" one of the big issues was the one of empowerment. There was a real sense of the separation of the haves and have nots in society. With the advent of automatic teller machines, computers at the library and a lot of things, the task is increasingly getting people to open up and be curious enough about computers. As Martin Campbell-Kelly said earlier, they do have a history and there are things beyond just using them that you need to be reflective about. If we were to plan "Information Age" today, I think, instead of trying to make everything as easy as possible, which was one of our goals, there might be something to be said for making it a little bit more difficult--and force people to be somewhat more reflective. So the task continually changes as we move forward in the information age. ROSIN: We began this afternoon with a talk from Mike Mahoney that set an agenda and put the history of computing in a broader context that some of us were, in fact, quite ignorant of. We had several overview presentations that showed us facets in the work of the history of computing, again, that many of us were ignorant of. These presentations certainly put things in categories that help make it easier for us to understand. Then we had an opportunity to discuss with some experts first hand--up close and personal--how those of us who are not involved might become more involved or might make our contributions more valuable. Then, finally this evening, I got an idea of the relationship between those of us who are professional computing people and those who are professional historians, and the difficulties in relating what we try to do to the general public. Finally, we learned how that public seems to be changing, just as the history of computing represents a changing environment. If we meet again in 15 years, we will see something very different.
830
CHAPTER
A What Makes History?
Michael S. Mahoney Program in History of Science Princeton University Consulting Historian, HOPL-II Conference As you look over the reviewer's and Program Committee's comments on your paper, you may be perplexed by admonitions in one form or another to "make it more historical". After all, you've been talking about the past, you've got the events and people in chronological order, you've related what happened. What more could be needed to make history? The answer is hard to pin down in a series of methodological precepts, as history is ultimately an art acquired by professional practice. But it may help you to understand our specific criticisms if I describe what we're looking for in general terms. Dick Hamming captured the essence of it in the title of his paper at the InternationalConference on the History of Computing held in Los Alamos in 1976; "We Would Know What They Thought When They Did It" (N. Metropolis, J. Howlett, G.C. Rota (Eds.)), A History of Computing in the Twentieth Century: A Collection of Essays [N.Y.: Academic Press, 1980, pp. 3-90]. He pleaded for a history of computing that pursued the contextual development of ideas, rather than merely listing names, dates, and places of "firsts." Moreover, he exhorted historians to go beyond the documents to "informed speculation" about the results of undocumented practice. What people actually did and what they thought they were doing may well not be accurately reflected in what they wrote and what they said they were thinking. His own experience had taught him that. Getting beyond the documentation to discover what people were thinking is no easy task, even when the people are still available to ask, or, when they themselves are doing the history. A story, perhaps apocryphal, about Jean Piaget shows why. The psychologist was standing outside one evening with a group of 11 year olds and called their attention to the newly risen moon, pointing out that it was appreciably higher in the sky than it had been at the same time the night before and wondenng why that was. The children were also puzzled, though in their case genuinely so. In his practiced way, Piaget led them to discover the relative motions of the earth, moon and sun and thus to arrive at an explanation. A month or two later, the same group was together under similar circumstances, and Piaget again posed his question. "That's easy to explain," said one boy, who proceeded to sketch out the motions that accounted for the phenomenon. 'What's remarkable," said Piaget, "How did you know that?" "Oh," the boy replied, "we've always known that!" Not only children, but people in general, and scientists in particular, quickly forget what it was like not to know now what they now know. That is, once you've solved a problem, especially when the solution involved a new approach, it's difficult to think about the problem in the old way. What was once unknown has become obvious. What once tested the ingenuity of the skilled practitioner is now "an exercise left for the student." The phenomenon affects not only the immediate past, but the distant past as well. When scientists study history, they often use their modem tools to determine what past work was "really about"; for example, the Babylonian mathematicians were "really" writing algorithms. But that is precisely what was not "really" happening. What was really happening was what was possible, indeed imaginable, in the intellectual environment of the time; aal
APPENDIX A
what was really happening was what the linguistic and conceptual framework then would allow. The framework of Babylonian mathematics had no place for a metamathematical notion such as algorithm. These considerations suggest the paradox inherent in the role of pioneers and participants in the history of computing, whether as active members of panels and workshops, as subjects of interviews, or as historians of their own work. On the one hand, they are our main source for knowing "what they thought when they did it," not only for their own efforts, but also that of their colleagues and contemporaries. On the other hand, it is they who reshaped our understanding by their discoveries, solutions, and inventions and who, as a result, may find it harder than most to recall just what they were thinking. Precisely because they helped to create the present, they are prone to identify it with their past work or to translate that work into current terminology. Doing so defeats the utility, or even the purpose, of their testimony. To the historian, the old way is crucial: it holds the roots of the new way. It does not illuminate history to say, "We were really doing X," where X stands for the current state of the art. Talking that way masks the very changes in conceptual structure that explain the development of X and that history aims at elucidating. It may well be that the roots of modern technique or theory lie in work done thirty or forty years ago. That can only become clear by tracing the growth of the tree determining its branching pattern, and identifying the points at which grafting has occurred. That requires, in turn, that the root be characterized in its own terms. When a pioneer talks about his or her work in the past, it is important for others to listen critically and be ready to say, "Now wait a second, we didn't put the question that way at the time, nor did we know the concept." It is important for the pioneer to develop the same sensitivity to changes in language over time, and which imply changes in conceptualization. Historically, a rose by another name may have a quite different smell. Having the solution can mask the original problem in several ways. One may forget there was a problem at all, or undervalue the urgency it had, projecting its current insignificance back to a time when it was not trifling at all, but rather a serious concern. One may reconstruct a different problem, overlooking the restructuring of subject brought about by the solution. One may ignore or undervalue alternative solutions that once looked attractive and could very well have taken development in a different direction. Historically, a "right" answer requires just as much explanation as a "wrong" answer, and both answers are equally interesting--and equally important. Several years ago 1 asked someone at Bell Labs responsible for maintaining software, what sort of documentation she would most like to have but did not. "I'd like to know why people didn't do things," she said. "In many cases when a problem arises, we look at the program and think we see another, better way of doing things. We spend six months pursuing that alternative only to discover that it won't work, and then we realize why the original team didn't choose it. We'd like to know that before we start." Something quite close to that holds for historians too. They want to know what the choices and possibilities were at a given time, why a particular one was adopted, and why the others were not. Good history, from the historian's point of view, always keeps the options in view at any given time. Getting the facts right is important, both the technical facts and the chronological facts. But the reasons for those facts are even more important, and the reasons often go well beyond the facts. When people come together on a project or for a meeting--when, indeed, they are creating a new enterprise--they bring with them their past experience and their current concerns, both as individuals and as members of institutions. In both cases, they have interests and commitments that transcend the problem at hand, yet determine its shape and the range of acceptable solutions. It is essential to know, in both the real and the idiomatic sense of the phrase, where they are coming from. In some cases, discretion, propriety of information, or just plain ignorance may preclude a definitive answer. Nonetheless, even when we can't know the answers, it is important to see the questions. They too form part of our understanding. If you cannot answer them now, at least you can alert future historians to them. What makes history? It's a matter of going back to the sources, of reading them in their own language, and of thinking one's way back into the problems and solutions as they looked then. It involves the imaginative exercise of suspending one's knowledge of how things turned out so as to recreate the possibilities still open at the time. In The Go-Between, Leslie Hartley remarked that "The past is a foreign country; they do things differently there." The historian must learn to be an observant tourist, alert to the differences that lie behind what seems familiar.
832
Call for Papers
The Second ACM SIGPLAN History of Programming Languages Conference (HOPL-II) Boston, Massachusetts, Spring 1993 In 1978, the first History of Programming Languages Conference covered the development and evolution of 13 specific computer programming languages, the people who participated in that work, and the context in which it was undertaken. Of particular interest was the combined presentation of both technical and administrative factors that influenced the development of these selected languages. That first conference included invited papers on the early giants of our field: ALGOL 60, APL, APT, BASIC, COBOL, FORTRAN, GPSS, JOSS, JOVIAL, LISP, PL/I, SiMULA, and SNOBOL. The original papers were published in ACM SIGPLANNotices, Vol. 13, No. 8, Aug. 1978. A book containing the papers, transcripts of the presentations, and much additional material was published in the ACM Monograph Series by Academic Press with the title History of Programming Languages, (Richard L. Wexelblat, Editor, 1981).
TOPICS FOR HOPL-II During the intervening years, much has happened in this field, and the HOPL-II Conference will address the history of those significant developments. Papers are solicited in the following categories: •
Histories of specific languages---the motivation, context, early development, evolution, people, and technical issues surrounding significant programming languages
•
Histories of language features and concepts--the development, introduction, and use of programming language idioms and constructs (e.g., concurrency control, encapsulation)
•
Histories ofclasses oflanguages-- issues underlying sets of languages that are designed around a common paradigm (e.g., functional, object-oriented, logic programming) or an application domain (e.g., civil engineering, graphics, simulation)
As with the first HOPL Conference, HOPL-II is intended to contribute to the historical record. To meet this goal, the Program Committee will work closely with prospective authors to help ensure that the papers are of a high quality.
833
APPENDIXB CRITERIA FOR SELECTION The Program Committee intends to apply the following criteria to selecting papers; it is necessary, but not sufficient, for the paper to be of historical interest. The word "use" applies to people other than the developer(s). A submission must satisfy both crteda within one category.
Early History of Specific Languages: 1. the language (or a derivative)has had significant influence on the theory or practice of computing 2. preliminary ideas about the language were documented by 1982, and the language was in use or being taught by 1985
Evolution of Languages: 1. the language meets the criteria for "Early History of Specific Languages" 2. there has been significant evolution of the language, as manifested by different versions of the language (e.g., derivatives, dialects, subsets, extensions) or by standards adopted either by different organizations or at different times
Language Features and Concepts: 1. the feature or concept (e.g., concurrency control, encapsulation) has had significant influence on the theory or practice of computing 2. preliminary ideas about the feature or concept were documented by ! 982
Classes of Languages: 1.
a.
for application-oriented languages, a set of languages in a specific application area must be recognizable as significant to people involved in that class of application (e.g., civil engineering, graphics, machine tool control, simulation)
b.
for paradigm-oriented languages, a paradigm defining a class of languages must be clearly regarded as significant (e.g., functional, object-oriented, logic programming)
2. preliminary ideas about a language in this class were documented by 1982, and a language in this class was in use or being taught by 1985 There is much to be learned from "instructive failures." Therefore, prospective authors are also encouraged to document concepts or features that may not have achieved widespread use, but are of historical interest.
834
CALL FOR PAPERS AND CONTENT GUIDELINES FOR AUTHORS
Second ACM SIGPLAN History of Programming Languages Conference (HOPL-II) CONTENT GUIDELINES FOR AUTHORS Thank you for expressing an interest in participating in the second History of Programming Languages Conference (HOPL-II). In 1978, the first History of Programming Languages Conference (HOPL-I) discussed the development and evolution of 13 specific computer programming languages, the people who participated in that work, and the context in which it was undertaken. In addition to considering histories of specific languages, HOPL-II will also address the histories of classes of languages, and of language features and constructs. The Call for Papers indicates more clearly the topics to be included in HOPL-II, and also specifies the criteria by which papers will be judged for selection. The main purpose of these guidelines is to help you develop the appropriate content for your contribution to HOPL-II. The questions herein point to the kind of information that people want to know about the history of some topic in programming languages. A set of questions is included for each of the four major areas to be covered by HOPL-II: •
early history of a specific language
•
later evolution of a specific language (usually a language treated in HOPL-I or elsewhere in HOPL-II)
•
history of a programming language concept or feature
•
history of a class of languages
The sets of questions overlap to some extent, especially for the first two and for the last two categories listed above. This guidelines document includes all four sets of questions, in the hope that having the other sets available may prove useful to you. Even within a single set, the same question, or very similar questions, may be asked in different contexts. Please draft your paper in light of these different emphases and contexts. Your paper should try to answer as many as possible of the questions in your topic area; it is understood that you might not be able to address every one of them. Because history can unfold in so many different ways, some of the questions are clearly irrelevant to your particular topic, or to your particular point of view. Or the information requested might be no longer available. But please remember that sometimes a negative comment is as useful as substantive information. Several questions are of the form "How did so-and-so affect whatever?"--it can be important for the historical record to assert that "it didn't." The question sets suggest the content, not the form, of your paper. (In particular, your paper should not be in question-and-answerformat.) The questions are organized into topics and subtopics for your convenienceduring your research; this structure is not meant as an outline for your paper. (Topics, subtopics, and questions are also numbered and lettered for convenience of reference.) Please feel free to use whatever form and style seems most appropriate and comfortable to you. The Call for Papers contains the criteria that will be used in the selections of papers. Please be sure to include within your paper a clear indicationof how the subject material satisfies the criteria. This informationcan certainly be provided indirectly as part of the overall text. (For instance, one of the criteria is dates; it suffices to include the dates as part of the historical narrative.) You might want to examine the proceedings of HOPL-I to see what earlier contributors did. (Of course, each of the papers at that conference dealt with the history of a specific language.) The reference is: History of Programming Languages, ed. Richard L. Wexelblat, Academic Press. 1981. The first History of Programming Languages conference established high technical and editorial standards. We trust that your contribution will help HOPL-II maintain or surpass these standards.
835
APPENDIX B
QUESTIONS ON THE EARLY HISTORY OF A LANGUAGE Background l.
Basic Facts about Project Organization and People a.
Under what organizational auspices was the language developed (e.g., name of company, department/division in the company, university?) Be as specific as possible about organizational subunits involved.
b.
Were there problems or conflicts within the organization in getting the project started? If so, please indicate what these were and how they were resolved.
c.
What was the source of funding (e.g., research grant, company R&D, company production units, government contract)?
d. Who were the people on the project and what was their relationship to the speaker (e.g., team members, subordinates)? To the largest extent possible, name all the people involved, including part-timers, and when each person joined the project and what each worked on. Indicate the technical experience and background of each participant.
2.
e.
Was the development done originally as a research project, as a development project, as a committee effort, as a one-person effort with some minor assistance, or ...?
f.
Was there a defined leader to the group? If so, what was his or her exact position and how did he or she get to be the leader? (e.g., appointed "from above," self-starter, volunteer, elected)?
g.
Was there a de facto leader different from the defined leader? If so, who defined this leader, i.e., was it some "higher authority" or the leader of the group, or ... ?
h.
Were there consultants from outside the project that had a formal connection to it? If so, who were they, how and why were they chosen, and how much help were they? Were there informal consultants? If so, please answer the same questions.
i.
Did the participants of the project view themselves primarily as language designers, or implementors, or eventual users? If there were some of each working on the project, indicate the split as much as possible. How did this internal view of the people involved affect the initial planning and organization of the project?
j.
Did the language designers know (or believe) they would also have the responsibility for implementing the first version? Whether the answer is yes or no, how much was the technical language design affected by this?
Costs and Schedules a.
Was there a budget providing a fixed upper limit on the costs? If so, how much money was to be allocated and in what ways? What external or internal factors led to the budget constraints? Was the money allocated formally divided between language design and actual implementation, and if so, indicate in what way?
b.
Was there a fixed deadline for completion and if so, what phases did it apply to?
c.
What is the best estimate for the amount of manpower involved (i.e., in man-years)? How much of what was for language design, for documentation, and for implementation?
d.
What is the best estimate of the costs until the first system was in the hands of the first users? If possible, show as much breakdown on this as possible.
e.
If there were cost and/or schedule constraints, how did that affect the language design and in what ways?
CALL FOR PAPERS AND CONTENT GUIDELINES FOR AUTHORS
3.
Basic Facts about Documentation a.
4.
In the planning stage, was there consideration of the need for documentation of the work as it progressed? If so, was it for internal communicationamong project members or external monitoring of the project by others, or both?
b.
What types of documentation were decided upon?
c.
To the largest extent possible, cite both dates and documents for the following (including internal papers which may not have been released outside of the project) by title, date, and author. Recycle wherever possible and appropriate. (In items cl, c4, c9, and c 10, indicate the level of formality of the specifications---e.g., English, formal notation--and what kind.) •
(cl) initial idea
•
(c2) first documentation of initial idea
•
(c3) preliminary specifications
•
(c4) "Final" specifications (i.e., those which were intended to be implemented
•
(c5) "Prototype" running(i.e., as thoroughly debugged as the state of the art permitted, but perhaps not all of the features were included)
•
(c6) "Full" language compiler (or interpreter) was running
•
(c7) Usage on real problems was done by the developers
•
(c8) Usage on real problems was done by people other than the developers
•
(c9) Documentation by formal methods
•
(clO) Paper(s) in professional journals or conference proceedings
•
(cll) Extension, modification and new versions
Languages and Systems Known at the Time a.
What specific languages were known to you and/or other members of the development group at the time the work started? Which others did any of you learn about as the work progressed? How much did you know about these and in what ways (e.g., as users, from having read unpublished and/or published papers, informal conversations)? (Please try to distinguish between what you as the writer knew and what the other members of the project knew.)
b. Were these languages considered as formal inputs which you were definitely supposed to consider in your own language development, or did they merely provide background? c.
How influenced were you by these languages? Put another way, how much did the prior language background of you and other members of the group influence the early language design? Whether the answer is "a lot" or "a little," why did these other languages have that level of influence? (This point may be more easily considered in Section 2 of Rationale of Content of Language.)
d.
Was there a primary source of inspiration for the language and if so, what was it? Was the language modeled after this (or any other predecessor or prototype)?
5. Intended Purposes and Users a.
For what application area was the language designed, i.e., what types of problems was it supposed to be used for? Be as specific as possible in describingthe application area; for example, was "business data processing" or "scientific applications" ever carefully defined? Was the apparent application area of some other language used as a model?
b.
For what types of users was the language intended (e.g., experienced programmers, mathematicians, business people, novice programmers)? Was there any conflict within the group on this? Were compromises made, and if so, were they for technical or nontechnical reasons?
837
APPENDIX B
c.
What equipment was the language intended to be implemented on? Wherever possible, cite specific machine by manufacturer and number, or alternatively, give the broad descriptions of the time period with examples (e.g., "COBOL was defined to be used on 'large' machines which at that time included UNIVAC I and I1, IBM 705.") Was machine independence a significant design goal, albeit within this class of machines? (See also Question (lb) in Rationale of the Content of the Language.)
d. What type of physical environment was envisioned for the use of this machine (e.g., stand-alone system, to be used under control of an operating system, batch or interactive, particular input-output equipment)? 6.
Source and Motivation a.
What (or who) was the real origin of the idea to develop this language?
b.
What was the primary motivation in developing the language (e.g., research, task assigned by management)?
Rationale of the Content of the Language These questions are intended to stimulate thought about various factors that affect almost any language design effort. Not all the questions are relevant for every language. They are intended to suggest areas that might be addressed in each paper. 1. Environmental Factors To what extent was the design of the language influenced by: a.
Program size: Was it explicitly though that programs written in the language would be large and/or written by more than one programmer? What features were explicitly included (or excluded) for this reason. If this factor wasn't considered, did it turn out to be a mistake?
b.
Program libraries: Were program libraries envisioned as necessary or desirable, and if so, how much provision was made for them?
c.
Portability: How important was the goal of machine independence? What features reflect concern for portability? How well was this goal attained? See also question (1) on Standardization and question (5c) under Background.
d.
User Background and Training: What features catered to the expected background of intended users? In retrospect, what features of the language proved to be difficult for programmers to use correctly, What features fell into disuse and why? How difficult did it prove to train users in the correct and effective use of the language, and was the difficulty a surprise? What changes in the language would have alleviated training problems? Were any proposed features rejected because it was felt users would not be able to use them correctly or appropriately?
e.
Object Code Efficiency: How did requirements for object code size and speed affect the language design? Were programs in the language expected to execute on large or small computers (i.e., was the size of object programs expected to pose a problem)? What design decisions were explicitly motivated by the concern (or lack of concern) for object code efficiency? Did these concerns turn out to be accurate and satisfied by the feature as designed? How was the design of features changed to make it easier to optimize object code?
f.
Object Computer Architecture: To what extent were features in the language dictated by the anticipated object computer, e.g., its work size, presence or lack of floating-point hardware, instruction set peculiarities, availability and use of index registers, etc.?
g. Compilation Environment: To what extent, if any, did concerns about compilation efficiency affect the design? Were features rejected or included primarily to make it easier to implement compilers for the language or to ensure that the compilers would execute quickly? In retrospect, how correct or incorrect do you feel these decisions were?
838
CALL FOR PAPERSAND CONTENT GUIDELINES FOR AUTHORS
h. Programming Ease: To what extent was ease of coding an important consideration and what features in the language reflect the relative importance of this goal? Did maintainabilityconsiderations affect any design decisions? Which ones? i.
Execution Environment:To what extent did the language design reflect its anticipated use in a batch as opposed to interactive program development (and use) environment?What features reflect these concerns?
j.
Character Set: How much attention was paid to the choice of a character set and what were the reasons for that decision? How much influence did the choice of the character set have on the syntax of the language?
k. Parallel Implementation: Were there implementations being developed at the same time as the later part of the language development? If so, was the language design hampered or influenced by this in any way? 1.
Standardization: In addition to (or possibly separate from) the issue of portability, what considerations were given to possible standardization? What types of standardization were considered, and what groups were involved and when?
2. Functions to be Programmed a.
How did the operations and data types in the language support the writing of particular kinds of algorithms in the language?
b.
What features might have been left out if a slightly different application area had been in mind?
c.
What features were considered essential to express properly the kinds of programs to be written in the language?
d.
What misconceptions about application requirements turned up that necessitated redesign of these application specific language features before the language was actually released?
3. Language Design Principles a.
What consideration, if any, was given to designing the language so programming errors could be detected at compile time? Was there consideration of problems of debugging? Were debugging facilities deliberately included in the language?
b. To what extent was the goal of keeping the language simple considered important and what kind of simplicity was considered most important? What did your group mean by simplicity?
4.
c.
What thought was given to make programs more understandable and how did these considerations influence the design? Was there conscious consideration of making programs in the language easy to read versus easy to write? If so, which did you choose and why?
d.
Did you consciously develop the data types first and then the operations, or did you use the opposite order, or did you try to develop both in parallel with appropriate iteration?
e.
To what extent did the design reflect a conscious philosophy of how languages should be designed (or bow programs should be developed), and what was this philosophy?
Language Definition a.
What techniques for defining languages were known to you? Did you use these or modify them, or did you develop new ones?
b. To what extent--if any--was the language itself influenced by the technique used for the definition? 5. Concepts about Other Languages a.
Were you consciously trying to introduce new concepts and if so, what were they? Do you feel that you succeeded?
b.
If you were not trying to introduce new concepts, what was the justification for introducing this new language? (Such justification might involve technical, political, or economical factors.)
839
APPENDIX B c.
To what extent did the design consciously borrow from previous language designs or attempt to correct perceived mistakes in other languages?
6. Influence of Nontechnical Factors a.
How did time and cost constraints (as described in the Background section) influence the technical design?
b.
How did the size and structure of the design group affect the technical design?
c.
Provide any other information you have pertaining to ways in which the technical language design was influenced or affected by nontechnical factors.
Aposteriori Evaluation i.
Meeting of objectives a.
How well do you think the language met its original objectives?
b.
How well do you feel the users seem to think the language met its objectives?
c.
As best you can tell, how well do you think the computing community as a whole thinks the objectives were met?
d.
How much impact did portability (i.e., machine independence) have on user acceptance?
e.
Did the objectives change over time from the original statement of them? If so, when and in what ways? See also question (2d) under Rationale of Content of Language and answer here if appropriate.
2. Contributions of Language a.
What is the biggest contribution (or several of them) made by this language? Was this one of the objectives? Was this contribution a technical or a nontechnical contribution, or both?
b.
What do you consider the best points of the language, even if they are not considered to be a contributionto the field (i.e., what are you proudest of about this language regardless of what anybody else thinks)?
c.
How many other people or groups decided to implement this language because of its inherent value?
d.
Did this language have any effect on the development of later hardware?
e.
Did this language spawn any "dialects"? Were they major or minor changes to the language definition? How significant did the dialects themselves become?
f.
In what way do you feel the computer field is better (or worse) off for having this language?
g.
What fundamental effects on the future of language design resulted from this language development (e.g., theoretical discoveries, new data types, new control structures)?
3. Mistakes or Desired Changes a.
840
What mistakes do you think were made in the design of the language? Were any of these able to be corrected in a later version of the language? If you feel several mistakes were made, list as many as possible with some indication of the severity of each.
b.
Even if not considered mistakes, what changes would you make if you could do it all over again?
c.
What have been the biggest changes made to the language (albeit probably by other people) since its early development? Were these changes items considered originally and dropped in the initial development, or were they truly later thoughts?
d.
Have changes been suggested but not adopted? If so, be as explicit as possible about what changes were suggested and why they were not adopted.
CALL FOR PAPERS AND CONTENT GUIDELINES FOR AUTHORS 4.
Problems a.
What were the biggest problems you had during the language design process? Did these affect the end result significantly?
b.
What are the biggest problems the users have had?
c.
What are the biggest problems the implementors have had? Were these deliberate, in the sense that a conscious decision was made to do something in the language design even if it made the implementation more difficult?
d. What trade-offs did you consciously make during the language design process? What trade-offs did you unconsciously make which you realize only later were actually trade-offs? e.
What compromises did you have to make to meet other constraints such as time or budget, or user demands or political factors?
Implications for Current and Future Languages i.
Direct Influence a. What language developments of today and the foreseeable future are being directly influenced by your language? Regardless of whether your answer is "none" or "many, such as...," please indicate the masons. b.
Is there anything in the experience of your language development which should influence current and future languages? If so, what is it? Put another way, in light of your experience, do you have advice for current and future language designers?
c.
Does your language have a long-range future? Regardless of whether your answer is yes or no, please indicate the reasons.
2. Indirect Influence a.
Are there indirect influences which your language is now having or can be expected to have in the near future? What, and why?
QUESTIONS ON THE EVOLUTION OF A PROGRAMMING LANGUAGE The principal objective of a contribution in this category is to present the history of a major language subsequent to its original development. In many cases, this entails extending the history of some language whose origins were treated in HOPL-I, or in another paper in HOPL-II. (You will be working with a member of the Program Committee, who will keep you informed of other relevant papers.) When a programming language is first developed, it is typically the work of an individual or a small, concentrated group. Later development of the language is often the result of an expanded, restaffed group, and perhaps additional individuals or groups outside the original organization. Similarly, while the original work is often focused on language design and implementation for a single environment, later developments are undertaken in a broader arena. When compared with questions about the early history of a language, these questions reflect this change in context. In particular, these questions are about a set of diverse development activities that surround the language, such as standardization, new implementations,significant publications, language-orientedgroups (SIGs and user groups). These questions are grouped into the same four broad categories that apply to papers on the origins of a language: •
Background
•
Rationale
841
APPENDIX B •
A posteriofi evaluation
•
Implications for current and future languages
However, the sub-categories and specific questions are different. The first question applies broadly to the language itself. It is intended to identify the particular developments and development activities that are the focus of the history paper. In contrast, you should address the remaining questions for each of the activities identified in that initial background section. You might also have significant information to contribute in response to questions raised about the early history of the language. Please examine the questions provided for authors of "early history" papers. Where appropriate, your contribution should make reference to related papers from HOPL-I or HOPL-II.
Background l.
Basic Facts about Activities, Organizations and People a. What are the categories of developments to be discussed (e.g., standardization, new implementations, significant publications) and what specific activities are reported on? (From this point on, each question is intended to apply independently to each development activity identified in question 1.1(a).)
2.
3.
b.
What organizations played principal roles in these developments? Identify them as precisely as possible: corporation and division, university and department, agency and office, etc. How were these organizations sponsored and funded?
c.
What, if any, was the nature of the cooperation or competition among these organizations?
d.
Who were the people involved in these developments? How were they related organizationally to each other and to the original developers for this language? Please be as specific as possible regarding names, titles, and dates.
e.
How did the roles of various individuals change during the course of the activity?
Costs and Schedules a.
What was the source and amount of funding for supporting the development? Was it adequate?
b.
What was its schedule, if any?
c.
What was the estimated human effort required to carry it out?
d.
What was the estimated cost for the development?
e.
What were the effects of cost and schedule constraints?
Basic Facts about Documentation a.
What are the significant publications arising from the development? For each provide: •
4.
842
a specific reference
•
names of authors (if not part of the reference)
•
intended audience (e.g., user, implementor)
•
format (e.g., manual, general trade book, standards document)
•
availability
Languages/Systems Known at the Time a.
What languages or systems other than the one in question had an effect on the development? In what ways did they affect the development?
b.
How did information about each of these languages or systems become available to the people it influenced?
CALL FOR PAPERSAND CONTENTGUIDELINES FOR AUTHORS 5. Intended Purposes and Users a.
What was the intended purpose of the development?
b. Were the results proprietary, for sale, freely distributed, etc.? c.
For whom were its results intended? How did this group of people differ from the originally intended set of users for this language?
d.
How did some intended target machine/operating system environment influence the development? How had this operating environmentchanged since the language was first developed?
6. Motivation a.
Who was the prime mover for the development?
b.
What was the underlying motivation for the development?
Rationale for the Content of the Development To the extent that it is appropriate, apply the "early history" questions in each of the following sub-categories to the activity being addressed. 1. Environment Factors a.
What were the effects on the development of concerns about program size, program libraries, portability, user background, object code efficiency, object computer architecture and speed, compilation environment, programming ease, execution environment, character set, parallel implementation, standardization?
b.
In what ways had the environment changed since the original development of the language?
2. Expected Applications of the Language a.
How did expected applications influence choice of operations and data types?
b. What features were essential to meet intended applications? 3.
Design Principles Applied to the Development a.
What, if any, was the underlying, consciously applied design philosophy?
b. What considerations were made for detecting and correcting errors in the results of the development?
4.
c.
What role did "simplicity" play, and what was meant by "simplicity"?
d.
What role did "understandability" play? Which was given higher priority, ease of reading or ease of writing, and why?
e.
Were certain aspects of language (e.g., data types, operations) considered more fundamental to the development than others? Why?
Language Definition a.
What language definition techniques were used in this development? To what extent was the result of the development influenced by these choices?
5. Concepts of Other Languages a.
To what extent was the introduction of new language concepts or features a part of this development?
b. In what ways did concepts from other languages influence this development? 6. Influence of Non-Technical Factors a.
What was the effect of other, similar developments on this one (e.g., overlapping standardization efforts)?
b. What was the effect of time and cost constraints on the development? c.
How did the size and structure of the development group affect results?
843
APPENDIX B
A Posteriori Evaluation 1. Meeting of Objeetives a.
How well did the development meet its objectives?
b.
How well did the users of its results feel the development met its objectives?
c.
What was the reaction of the computing community at large?
d.
How did portability of results impact their acceptance?
e.
Did the objectives of the development change over time? If so, when, how, and why?
2. Contributions of the Development a.
What were the biggest contributions of this development? Were they among the original objectives?
b. What do you consider its best features? lts worst? c.
How has this development affected other activities (e.g., development of other languages, dialects, language processors, standards, operating systems, computer hardware)? Which of these have become significant in their own fight?
d.
In what way is the computer field better/worse off for this development?
e.
What fundamental effects on programming language methodology have arisen from this development? (e.g., new data types, control structures, techniques for definition, for documentation, and for implementation of languages, application design strategies, theoretical discoveries)
3. Mistakes or Desired Changes a. What mistakes were made in the development?Were these mistakes corrected in later developments? b.
What changes would you now make if you could?
c.
What were the biggest changes made to the development results since they were first released? Had they been considered earlier and then dropped, or were they truly later thoughts?
d. What significant changes have been suggested but not adopted, and why? 4.
Problems a.
What were the major obstacles in carrying out the development?
b.
What were the major problems encountered by people who used its results: e.g., language users, designers, implementors, those who work on standards?
c.
What trade-offs were made during the development? Which were made consciously and which were recognized after the fact?
d.
What compromises were made to meet other constraints such as time, budget, user demand, and political factors?
e.
Which estimates (time, cost, effort, people) were farthest from reality? Why were they off?
f.
What application-specific features might better have been left out?
Implications for Current and Future Languages a. Which current and foreseeable developments are being directly or indirectly influenced by this development, and why? b.
844
Which results, if any, of this development have a long range future? Why?
CALL FOR PAPERSAND CONTENT GUIDELINES FOR AUTHORS
QUESTIONS ON THE HISTORY OF A LANGUAGE FEATURE OR CONCEPT The principal objective of a contribution in this category is to record the history of a programming language feature or concept. This question set has a quite different focus from the set dealing with the development of some particular language. A particular language feature or concept is incorporated in particular languages, so much of the information solicited is comparative. However, to the extent that you were party to the development of particular language(s) embodying this feature, it may be appropriate to be guided by the question set on the history of a single language. For simplicity, these questions usually refer to a "feature" rather than a "feature or concept."
Basic Background Information a.
Who invented or introduced this feature? What was their background? How did they come to use this background in their development?
b.
What are the important publications (e.g., papers, language manuals) about the feature? Please make a special point of identifying as many early publications as possible, including informal and internal documents.
The Nature of this Feature or Concept a.
What are the distinctive characteristics of this feature?
b.
What shortcomings of existing languages prompted the discovery and/or the introduction of this feature? What set of expressive or methodological problems did this feature address at the time of its introduction? How was the absence of this feature handled prior to its introduction?
c. d.
How did this feature enhance a programmer's ability to express the solution of a problem?
e.
What forces (e.g., theoretical concerns, market demand, error-proneness of alternative forms) supported the introduction and evolution of the feature?
f.
What external influences (e.g., changes in technology, new classes of problems, new classes of users) contributed to the need for this feature, or to its introduction and evolution?
g.
What other concepts were precursors of this concept? In which language(s) did they exist?
h.
In which language(s) was this feature introduced? Who introduced it? How did the people involved with it interact in the process, if more than one person was involved? (Particularly if you were involved with this development, please consult the question set on the history of a programming language for guidance on useful information to include.)
i.
What language(s) embody this feature? (Please be as inclusive as you can. However, it may be appropriate to concentrate on a few exemplars in comparisons.) In what ways are these languages similar or different in their incorporation of the feature? How does the feature manifest itself? Give examples.
Evolution a.
How did this feature evolve over time? What has it evolved into in languages currently in use?
b.
How did this feature interact with other features in the languages which embody it? How has this interaction influenced the evolution of this or other features? With what other language features is it most or least compatible?
845
APPENDIX C.
What obstacles (institutional, financial, psychological, political, temporal, technological, etc.) were encountered during the introduction and evolution of this feature? How did they affect it? How were they overcome?
d.
What is the present incarnation of the feature, if any? In which languages can it be found today?
e.
Were there competing or complementary concepts or features that conflicted with this one? If so, what was the nature of this conflict, and how was it resolved?
Evaluation a.
How well did the feature meet (or fail to meet) its expectations and goals? If it failed, why did it fail?
b.
How did specific implementations affect its acceptance?
c.
How was the feature received by those affected by it (e.g., programmers, problem solvers, managers)?
d. What other concepts or features were influenced by this one? e.
How did this concept contribute to software methodology?
QUESTIONS ON THE HISTORY OF A CLASS OF LANGUAGES The principal objective of a contribution in this category is to record the history of a class of languages. A class of languages is defined either by the application for which they were intended (e.g., simulation, graphics, machine tool control), or by a language paradigm (e.g., functional, data-flow, object-oriented). This set of questions has a quite different focus from the set that deals with the development of some particular language. Here the focus is on the distinctive characteristics of a set of languages, and much of the information solicited is comparative. To the extent that you were party to the development of particular language(s) in this class, it may be appropriate to be guided as well by the question set on the history of a single language. A particular language paradigm or application area often implies particular programming language features, or particular restrictions or extensions of language features. Please consult the question set on language features and concepts for guidance. Basic Information a.
What language paradigm or application area characterizes this class of languages?
b.
Which languages are in this class? (Please be as comprehensive as possible, including early experimental languages.)
c.
Did someone (or some group) invent this class of languages, or did it evolve? If invented, by whom? If it evolved, when and by whom was it perceived as being a distinct class? What was the background of these people, and how did they come to be involved in this class of languages?
d. What are the basic publications (e.g., papers, language manuals) about this language class or particular languages within this class? Please make a special point of identifying as many of the early publications as possible, including informal or internal documents. The Nature of this Class of Languages a. What are the distinctive attributes of this class of languages? How did these attributes affect the features that the languages' designers included or excluded? b. What, if any, class of algorithms inspired the emergence of this language class? What application area(s) were these languages intended to address? How were these applications dealt with prior to the introduction of languages in this class?
846
CALL FOR PAPERSAND CONTENT GUIDELINESFOR AUTHORS
c.
What expectations and goals did the community interested in this class of languages have in mind?
d. Describe the languages comprising the class. (Please discuss as many languages as you can. However, it may be appropdate to concentrate on a few exemplars.) What are the earliest languages in the class? In what ways are they similar? How do they differ? In particular, compare them with respect to * declarative constructs (types, etc); •
imperative constructs (statements);
•
flow of control;
•
program modularization constructs;
•
concurrency constructs;
•
input-output.
In which ways are the languages in the class similar or different with respect to meeting the goals of program maintainability, reliability, readability, portability, run-time efficiency?
Evolution a.
How did this class of languages evolve over time? How did later languages in the class differ from earlier languages? What were the reasons for the changes? In what ways can the later languages be considered superior or inferior to the earlier ones? (A later language could, of course, be superior in some respects and inferior in others: it may be useful to treat the nature of these trade-offs.) To what extent was upward compatibility a constraint?
b. To what extent did the languages in this class reflect external trends in programming language methodology (e.g., extension facilities, support for object-oriented programming, data abstraction, structured programming)? c.
To what extent did the languages in this class reflect external trends or developments in computer hardware and operating systems (e.g., special-purpose hardware, multi-processing, availability of cheap processors and memory)?
Evaluation
a.
How well has this class of languages met (or failed to meet) its expectations and goals?
b.
Has this class of languages proved to have applications beyond its original focus?
c.
In the application area(s) relevant to the class, what are the competing languages (e.g., general purpose languages with special libraries) outside the class? How successful are the languages in the class versus these competing languages?
d. How did the languages in this class influence trends in programming language methodology? e.
How did this class of languages influence trends or developments in computer hardware and operating systems?
f.
How has this class of languages influenced languages outside the class (e.g., by the latter incorporating characteristic features without adopting the undedying paradigm)?
847
C List of Attendees
Elizabeth Adams Ken R. Adcock Shail Aditya David Allison Richard Amick William Aspray Stephen Auerbach Mark Bartelt
Hood College AGC Corporation MIT National Museumof American History
IEEE HistoryCenter Wellington System,~Inc. Canadian Institutefor Theoretical Astrophysics Joel Bartlett DEC Friedrich Bauer Institae for lnformatik Ralf Bayer Motorola Gwen Bell The ComputerMu~um Thomas Bergin American University Kareo Bernstein SUNY at Stony Brook Andrew P. Black Digital EquipmentCorporation Andre B l a v i e r Informatique--CDC George Bosworth Digitalk Inc. James B o u h a n a Performaece International Frederick B r o o k s University of North Carolina Bruce Bruemrner Charles BabbageInstitute Peg Cahoon Digital EquipmentCorporation Martin Campbell-Kelly Universityof Warwick John Can" University of Pensylvania Frank Carrano University of Rhode Island Mark Carroll Universityof Delaware Paul Ceruzzi National Air & Space Musaum Cheryl Chang-Yit University of Delaware Richard Chapman Cornell University Srikrishnan Cbitoor University of Deleware Boleslaw Ciesielski ViewlogicSystemsInc. Bernard Cohen Harvard University Jacques Cohen Brandeis University Donald Colbure Crative Solutions,Inc. Alain Colmernaer Facult de Sciencesde Luminy Jay Conae Dereystification of Technology Consultant Philip Conrad Universityof Delaware Edward C o u n c i l Tireherfield Systems Paul Cousineae Worcester Polytech Carl Covell Oregon State University Lawrence Crowl Oregon State University Ann Curby Peritus SoftwareServices Dorothy W. C u r t i s MIT/LCS Pavel Curtis Xerox
1
Bates College Chuck D'Antonio Texas A&M Walter C. Daugherity MIT Laboratoryfor ComputerScience Mark Day MIT/LCS Jack Dennis T.U. Darmstadt Christine Detig Harvard University Allyn Dimock University of Massachusetts Richard Eckbouse Apple Computer, Inc. Sybil Ellery Consultant Arthur Evans Northeastern University Remy Evard The George University Michael Feldman Bellcore Stuart Feldman Ronald Fischer Ann Flenry M1T Media Lab John Federaro Marlboro College Mark Franeillon Bob FranLston Institute fur Compntersysteme Michael Fraez AT&T Bell Laboratories Chris Fra~r Bjorn Freernan-Benson Universityof Victoria Nortbeastarn University Natasha Fridman Indiana University Daniel Friedman Lucid Inc. Richard Gabriel University of Michigan Bernard Gullet Naval Rematch Labratory Helen M. Gigley Technion City Joseph Gil Northeastern University David Gladstein ParcPlace Systems Adele Goldberg (media) Nance Goldstein Carnegie Mellon University John Goodenough AT&T Bell Laboratories Rick Greer Universityof Arizona Medge Griswold University of Arizona Ralph Griswold Continental Insurance Henry E Guckes The JacksonLaboratory John Gnidi Schlumberger Laboratoryfor Scott Guthery Computer Science IBM Brunt Hallpern Digital EquipmentCoq~oration Dan Halbert MIT/LCS Michael Halbher E.O. Computer Andrew Hniey Universityof Warwick Ross Hamilton Syracu~ University Per Brinch Hae~n AT&T Bell Labs Charles Hayden Jocben Hayek
Editor's note: the affiliations are shown as those at the time of the Conference.
849
APPENDIX C Stephen Hinton Jan Rune Holmevik Christian Horn Chrisfiae Horn Corey Huber Randy Hu&son Deborah Hwang Jean Ichbiah Dave Johnson E. AndrewJohnson Jeremy Jones Peter Juhl Randy Kaplan Alan Kay Benjamin Keller Stan Kelly-Bootie Richard Kelsey Gregor KJczales Kim N. King Reinhard Kirchner Bjorn Kirkemd Herbert Klaeren Kate Klimukhian Robert Knapper Thomas Knoedler Andrew Koenig Philip Koopman Joanna Kulik Richard LeBlanc J.A.N, Lee Karen Lemone Michael Lewis Wei Li Charles Lindsey Barbara Liskov Joachim Laegger Joan Lukas Stavros Maerakis Peter Mager Michael Mahoney Michael Marcotty Thomas Marlowe Stephen Ma~ticola Robert E Mathis Michael McClennen W.M. McKeeman James McKenney Wendy McKnitt Brian Meek Andrew Mickel Elaine Milito James Miller Richard Miller Calvin Mooers Thomas Moog Charles Moore Thomas E. Morgan Joel Moses Steven Muchnick Richard Nanoe Jim Newkirk
850
Dataplex Coq~oration University of TmndheimCenter for Technologyand Society FH Furtwangen Fm~erConsulting Incorporated Intemetrics MIT Laboratoryfor ComputerScience JDI TechnologyInc. Open SoftwareFoundation Apple Computer Inc. AT&T Bell Labs Educational Testing Service Apple Computer Virginia Tech. Systems Research Center Unix Review Northeastern University Xerox Parc Georgia State University University of Kaisedautera University of Oslo University of Tubingen Northeastern University Institute for Defense Analyses ACM/SIGPLAN AT&T Bell ~ t o r i e s United Technologies MIT Laboratoryfor ComputerScience Georgia Tech VirginiaTech Worcester Polytechnic Institute, ComputerScience Department Bard College Nortbeastern University University of Manchester MIT Laboratoryfor ComputerScience ZIB Berlin University of Massaehusetts OSF Research Institute Perceptron TechnologyCorporation Princeton University General Motors ResearchLabs Seton Hall University Rutgers Unive~ty University of Michigan Digital Harvard Businer.xSchool University of Delaware Kings College MCAD ComputerCenter Digital EquipmentCorporation SHL Systemhouse TRAC Data Acquisitionfor Science and Engineering Computer Cowboys Brooklyn UnionGas MIT SunPro & Sun Labs Virginia Tech SystemsResearch Center
Cindy Norris Judy O'Neill Dino Oliva Terry Olkin Nate Osgood Kasper Osterbye Rajeev Pandey John Peters Lod Pollock Allan Price Robert Probasco Atanas Radenski Joe Ramey Norman Ramsey Elizabeth Rather Dan Resler Adam Rifkin Dennis Ritchie Robert Rosin Douglas Ross Bernie Rothmel Philippe Roussel Barbara Ryder Daniel Salomon Jean Sammet James Sasakl Thomas Schorsch Joachim Schrod Aaron Scidman YumikoSekiya Ravi Sethi Jean-Marie Szrat Vincent Sgro Andrew Shaw Richard Soley Ellen Sperms Raymie Stata Paul Steckler Guy Steele Jr. Selden L Stewart Gregory A. Stobbs Oliver Stdmpel Bjame Stroustrup Greg Sullivan Patricia Summers Jeffrey Satherland David Tarabar Robert Thau James Tomayko Prescott Turner Mary van Deusen Paul van Eykelen Mitchell Wand ChristopherWarack Peter Wegner Lori Weiss Paul Wexelblat Richard Wexelblat William Whitaker Stephen Wilcoxon Michael Williams N. Wirth
University of Delaware Charles Babbage Institute Northeastern University Oracle Corpomtiou MIT Aalborg University Oregon State University Practical Computing,Inc. University of Delaware ACM University of Idaho Southwest MinnesotaState University Texas Instruments Bellcore FORTH, Inc. Virginia Commonwealth University Caltech AT&T Bell Laboratories Enhanced Service Providers, Inc. SotTech/MIT GBC/ACM Elsa Software Rutgers University University of Manitoba ProgrammingLanguage Consultant University of Maryland Baltimore County U.S. Air Force Academy T.U. Darmstadt DEC--CRL NortheasternUniversity AT&T Bell Laboratories Informatique--CDC Rutgers University M1T MIT AI Lab Northeastern University Thinking MachinesCorporation NIST Harness, Dickey, and Pierce The ComputerMuseum AT&T Bell Labs Northeastern University Virginia Polytechnic Object Databases MIT Carnegie Mellon University Liant SoftwareCorporation IBM Northeastern University Northeastern University U.S. Air Force Academy Brown University Apple Computer University Massachusetts,Lowell Institute for Defense Analyses Colonel, USAF University of Delaware University of Calgary ETH Zurich
D Final Conference Program
CIVI S I G P L A
HOPL-II AMBRIOGE
199
The ACM SIGPLAN Second History of Programming Languages Conference (HOPL-II)
Final Conference Program
April 20-23 1993
Cambridge, Massachusetts USA
851
APPENDIX D
Conlemnce ~ m o e
Staff
J.A.N. Lee Vb'g/m/a ~ ~ Umd~,'~ty
l~Lt~ ud
i2ni~r'enr.. N o t e . Conhmmce Iocmlon
J a m L. 8ammet
C a m b r l d ~ Center M a r r i o ~ Two Cambridge C e n t s r C a m b r i d ~ , IdA 0 2 1 d USA pizme: (617) 494..6600 fax: (617) 494-0036
/Uclmt,d i..cklmm* On-sits
P~
reglMratlon
S. M s s w
i n t o i
Riduu,d L. Wuollflat Mary van Dommn //IM
trlmportatlon
Lemms W o m b Po/y~e/m/¢ l ~ m mddblm (m---ne.¢~
J a m u P. Bouhmm Dan 14albm,t
Pt,~mm asmmittm,
Wedne~hty Thursday Friday
ll:OOam- lO:~m 7 : 4 ~ m - ]O.'OOpm 7:4from- lO.'OOpm 7:46am - 12:00noon
T h e Cambridge Center Marriott is a abort taxi ride from Boston's Logan Ah'port~ The hotol ia adjae~mt to t h e Kendall Square subway igation, czt the MBTA ('1") Red I.,ine. Both H a r v a r d Square and downtown B~ston are j u s t two stops away. The airport is also acoeuihie via the T, though you m u s t change trains twice.
Jean E. 8ammet (CA,dr)
Mlel~l ~ Mahm~y* ( C o t ~ r # ~
Seho~roh~ reek~ienm
P,~mm~ U~mr~y itetm~ F. lge~n (~'erm~ e/m/r) ~ Pr~d,der& I ~ .
T h e n students were a w a r d e d scholarships to HOPL-II; t h e y were selected from a v e r y compe~/Uve set of appiicattous: Ross Hamilton
UniverRlty of Wcwwich J a n Rune Holmevik
Uni~rsity of Trondh~im
Js~ass
Stephen P. Mast/cola
B e m ~ d & O~Ilcr"
Rutgers Unlverelty Ibdeev Pande~r OreHon Stab~ Univermity
Helm M. N ~ / / ~
Virginia Poly~cbnic Inzt~tu~ and State Uni~rsity
M~.hul I F ~ . , s ~
P a t r i d a A. Summons Z,abomtoO,
Bnmt Hailpw'n"
IBM ~ d ~ Hud~n Im~,mctria *dudr e r a Ra.~w eemm/t~¢
852
R ~
U~lwr~y
R/chard L. W m l h l a t l~m for ~ Amdy~s
Th~kl
The National Science Foundafic~ (grant n u m b e r CCR-9208568) h a s provided support for t h e invited speakers as well a s four of the student scholarship recipients. S H L Systomhouse Inc. h a s provided support for one of the student scholsrehips.
FINAL CONFERENCE PROGRAM
Tmday Jqxl! 2O
Forum on the History of
Computing Forum Chair: Robm't F. Rodin £n/~need SevoLee ProoLder~, ln~.
4:S0 - 8:80pro /oeaJ/~ns go/~ anno~d
and eolleettng artHaet~ Gwe~ Bell Corn/Vet M ~ r o n
m a ~ , ~ ~ a/b~mooa ~ l o m L The e ~ l n ~ pan~l ~ i~ open to both Por~m and Main Program rqa,u u W . 2:90 - 2 : 4 8 p m ¥-Wi
I~u~
Doeum®ntiz,~ wuJ*ets Mie.bn~ Mareotty G~nGra/Mo~v~ Rmareh Laboratar/eJ
In tl'w history of
Wrl~Lng about the ~ d eomlmtlng Bernard A. Oaller Un~verB~ of Mich.~an J.A.N. Yirginla Polytechnic Inati.t~teand Stare Unioe~tty
¢~m~uung Mlehxel 8. Mahoney Pv,ince~on Unevenly
2:48 * 4:00pm =~_/e.,_sV-VH
~Ivltlss
and msour~s
In the
T e a e h i n g a b o u t the himtory d eomput/nlr Martin Campbell-Kelly On~oe~i~ of Warwleh ¢7310
hlat0ry of computing overvlew p ~ n t a t / o n a 1)o/and
Participating In the hhdory of computing /zoedleI emaH ~ d3aeuuians
av~zi~
Bruamm~'a' . A r t i f a m and m m m Gwm Bell Tkm . A n ~ i ~ a n d o t i S " J o u r u ~ B ~ u u ' d A. Caller Univer~y of Ulehi£an
8:00 - 9:80pro ~s/o~.wV-VH
thia s ~ a n ~ o m to beta Yor~m ~ Main ,W,,~",d)
The challenge of public dlsphwll about the history of computing ,pane! disemm~n David AIIiao~ National Mo~eum of American Hiator3 The 8mO.htonLan Intgitwtion
g~etlv* oonlbreneu J m n I~ 8 s m m ~
Paul CeruzJd .National Afr and 8paoe Ms~eum The Smtt~sonian Institution
Univwuit~ oom'~ Martin Campbelt-KeDy Onh,~,~dO, of WarwL~k (T]JO
OBver 8'U'impe] 2~e Compu.hrrMU~Urm
4~0 - 4 : S O p m brat
853
APPENDIX D
Wednesday April 21 9:30 - l l : 4 k m 111
Main Program P / ~ note: a//conf~ren~ ~u/nas will start promixly at the liatecl times.
1:15 - 3.~Spm
A//paper m~6o~ wlll be in ~don lll
A History o t A L G O L e8 C. H. U r ~ y Uni~rJity of Manchester (UIO
Opening session l n t r o d u c d o n s a d Welcome John ,q~ N. Lee (Conference Chair) Virginia Polytechnic Institute and Stats U ~ i ~ e r ~
R e v o i l ~ t l o ~ ~bout the Development of (irwitzd paper) N. Wirth E ~ H Zurich
W~i~mi~ Remarks Gwen Bell (ACM President) The Computer M u ~ u m WeloomJmqr ILemm'k8 Stuart Feldman (SIOPLAIV Chair) BeUeore ~N~ffStm ~ u m m m ~ ~ L0~llJt~(~8 Jean E. Sammet (Program Chair) Prq~ramm/JW LanS,ua~e ~n~u/tant
D/scunant: Andrew B. Mickel Minnmpo//e Co//ege of Art and D u ~ n 3:05 - 3:35pm
break
3:35-5~5pm
M o n i t o r s a n d C o n c u s ~ e n t Pameah A Personal
History
Per Brineh Hansen 8yract~te Un/wrw/~y
brat F r o m H O P L to HOPL-H: lS Yeant of l~'olP'am~;"_~ Lmqluqfe Deveiolmsent
Ada - The Project (invited paper) William A. Whittaker Co/onel USAF, Retired
JearJt~. Smmmlali~ Programming Language ConJultant M.~t-- Hhmwy (informal Michael S. Mahoney Princeton Unitwrmity
- l:lSpm
lunch
Paper sessions: questions and answers A question and anawer session will follow each paper pre~ntation. All quations must be submitted in writini to the collection monitors. Plea~ include your name and affiliation. All q~stionz will be included in the final proceedings, though tlw sptal~r may not have time to answtr them all.
854
Paper session Chair: Michael Feldman The George Wmdtington Uniwrsity
I.,mge l)e~llro u I)e,d p I~redeHek P. Brooks University of NortA Carolina
ll:4~tm
Paper session Chair: Jacquee Cohen Brandeis Univereity
D/settsmnt: John B. Goodenough Software £ n S ~ n e e r ~ InJfitute 6:45 - 9:45pm
Conhtrence reception The Computer Museum Museum Wharf Boston, MA
Free buses will provide transportation to and from the Museum. Tin first buses will be ready for loading on the Broadway side of the hotel at 6:15pm. B u m will shuttle between the hotel and the Museum until the end of the reception. 7
FINAL C O N F E R E N C E P R O G R A M
2:05 - 4:00pro
Thursday
Apr~
8:30 - lO:30em
~ Nsslon Chalr. Randy Hudson In~rm~r/cs
X m s t o r r d CLU Barbara Liskov M m u m c h ~ IrJt/tute of Techno/oey
' I ' ~ ]~,obation e / I A s p Guy L. Steele, Jr.
T h e Em'l,y H i s t o r y of' Bmalitslk (invited paper) Alan C. Kay Apple Computzr
Maehinu Corporation Richard P. Gabriel Lueld, Imx D~euuan~: John IVode~aro Frnnz In~
( i ~ l t ~ l paper) Alain Colmm'auor FacuPA d ~ ~cl~nen de Luminy Philippe Rousssl £1.aSofhoa~
D / ~ u s ~ n t : Adele Goldber'g Pure.P/ace 8ystemm 4:00 - 4:S0pm brink 4:30 - 6:101~n
l]:OOam
bruk ll:OOam
- 12:50pro
The Evolution o f F o r t h Elizabeth Rather FORTH, Inc. Donald R. Colburn Creative So/utt/ons, Inc. Charles H. Moore ComputGr Om~oys
Paps¢ 1 ~ 8 1 o n COmir: Tim Bergin American Urdversity A HhJ~ ot I } ~ ]~*,,t hubtion I~----,-~ L,m~aatlw ~,z,.h.,.d E. Narme Vlrsi~ia Poly~ehnie ln,titut~ and 8 ~ Onh~nlUy TSbo B e s l n n i n g s n d Development of PORMAC ( F O ~ u l a ~A~puisem Cma~) J M n g. 8ammet ~ r u a S e Con~ndta~ Diseu~uwm~: Joel Moses
Paper s e ~ l o n Chair.. Helen M. Gig]ey Nave,/Re~rch/,aboratory HJMory d the l e o n ~ramndmr LanEuage Ralph E. Griswold Un/~r./ty of.Arizona Ma¢l~ T. Griswold The Unit~r.ity of Arlzon~
INacu~sant: Jaoques Cohen B,.a,,~,~ U , ~ IO:SO -
Psper session Chair: Barbara Ryder Rutgers Uni~r~lty
7:00pm
8a/oe/V
Con1~'ence l~nquet ~ , e r . foUow,d by Informa4 entertabt/n6, stu~v-/~Jfrom lans,uace Oonference attendees w/tAout banquet t i e / ~ may ~tend ~ ~.ory ~ s / o n of the/~nquet, tst/ma~ed to s~rwt between 7:45 and 8pro.
MIT 12:150
- ~:06pcm
Imu~b
855
APPENDIX D
Fdday
M8in Program
Apr. 23 8:30.10:30ran
PW
talon
Ch~ix: Brent Haflpern IBM T h e D ~ d o ~ z m m t o~ the C Lmz~m~e (lrwl~d paper) Dermis I~tehie A T ~ T Bell Labora~ork~ A H / s t o r y o¢C++: I W / ~ . - I ~ I Bjarne ~t.rom~trup A T & T BellL s ~ w ~
D~emumnt (both papmO : Stuart, Fe~dm,~
10:30 -
ll:OOam
b~ ll:00am ~zdo~ Ill
- l:OOpm
Patrol W o n
Clml.r: Midme] 8. Mahoney Pr/nceto~ U~/vers/ty
Conferonce book: H/J/ory of Progmnm/ng La,,gu~.~,-U
Confer~m~ rqistwante will reeoive copies ot the HOPL-II papers in prvprint form at the conferenoe. However, a cmnple~ record ot the ~onfer~mee is planned ~ puMieatSmi in lgS4. The book, Hi~tory of l~mming Languaees-ll, will oaatatn mtitod versio~ ~ all tb~ papers and much addittonal new m a t ~ a ] , including: • Fred Brooks' keynote 8ddreu. • Transm.ip~ of the oral
pr~tlot~, di~.mun~' remarkJ, ~ l e ~ i ~ , the closing panel ~ i o n , and the stories told at the eonference banquet. • Material fi'om the Forum ml the History d Computing, includ/ng speakers' handouta, transm4pte presenbttions, and small-group discussion notes. • Speaker biographicl and photos. • Photoe taken at the conference. • A cmnprehmmive index. • Extens/ve s e ~ of helpful quest/mas for future authors w r i ~ about
the histary ot p r o l p - ~ t ~ = lanfpuqpm and othe~ fields.
P r o s ~ ' a s m i ~ L a ~ 0 u q W s : Does our Present Past H.a~ a Future?
By filling out • form now, you can u k to be noUfled as soon u H/arm'7
ALto C. Kay Dennis Rltchie William A. WhitaMor N. Wirth
avsilabl~ You will slso be el/gible for a discount. No prepayment is nece~mry, and you will be under no obligation. In addition, you csn now order discounted eopiem of the 1981 book History of Programming Lon~ual~, published as the fired proceedings e/~the first HOPL conference, held in 1978. A form for these order0 is included in your preprlnts; eopie8 offthe fba'm are also available at the conference desk.
I0
856
INDEX OF PROPER NAMES
A A-language, 239 A68C, 692 Abelson, Hal, 258 Abrahams, Paul W., 148, 207, 275 Ada, 17-18, 21-22, 42, 147, 156, 158, 160, 162-163, 265, 491,707 Ada 9x, 158 Ada Augusta, the Countess of Lovelace, 207 Adams, Norman, 251 Addyman, A. M., 107 AED-0, 49 AED-1,49 Agrawal, Sudhir, 715 Aho, AI, 729 Aiello, Jack, 474, 492 Aiken, Howard, 3 Alexander, Robert J., 603 ALGOL, 14, 16, 98, 239, 376, 383, 775 ALGOL 58, 20 ALGOL 60, 17, 20, 28, 30, 98, 137, 154, 197, 235, 332, 376--377, 438 ALGOL 68, 17, 20-22, 28, 98, 197, 340, 479, 675, 709 ALGOL W, 98, 333 ALGOL X, 98 ALGOLN, 32 ALGOLW, 35 ALGY, 436 Allen, John, 243 ALPAK, 437 Alphard, 272, 471,475, 481,492 ALTRAN, 430, 437 Amersinghe, Nimal, 492 Ammann, U., 105" Amoroso, Dr. Serafino, 183
Anderson, Christine, 216 Andrews, G., 155 Anger, A., 434 Annino, Joseph, 408 APL, 14, 16--17, 21-22, 270, 404, 604, 723 APT, 16--18, 21-22 Argus, 480, 482 Arthur, James D., 408 ASPOL, 400, 403 Aspray, William, 776 Assembler, 7 Atanasoff, John V., 792 Atkinson, Russ, 296, 478, 492 ATLAS, 17-18, 22 Auslander, Marc, 434 Awk, 605 B
B, 673 Babbage, Charles, 2, 207 Babcisky, Karel, 706 Bachhuber, Stephan R., 203 Backus, John, ! 9 Bahr, Knut, 449 Baker, Jim, 434 Balci, Osman, 408 Ball, Mike, 736 Balzer, 295 Barber, Jerry, 263 Barnett, Michael, 434 Baroness Wentworth, 208 Bashe, Charles, 776 BASIC, 16--18, 22, 291 Basic PDP-1 Lisp, 234 Basso, Pierre, 338 Battani, G6rard, 337 Bauer, Fritz, 2, 33, 43 Bawden, Alan, 254, 280 Bazzoli, Ren6, 337
BBN-Lisp, 235-236 BCPL, 604, 673, 701 Beale, Alan, 603 Bekic, Hans, 33, 54 Bell Labs, 437 Bell, Gwen, 2, 24 Bendix G-20, 383 Benson, Eric, 263 Bergin, Thomas J., x, xi, xiv, xv-xvi, 453 Berkeley, Edmund C., 780 Bemstein, A. J., 151 Berzins, Valdis, 492 BETA, 400 Bigbotte, John, 768 Birtwistle, Graham M., 404 Bishop, Judy, 154 Bishop, Peter, 295, 296 Blaauw, Gerrit, 6 Black, Fischer, 151,269 Bladen, Capt. Jim, 218 Blair, Fred, 248 Bleiweiss, Larry, 434 BLISS, 297, 604 BLISS-i 1,251 Blood, MmjjorBen, 183 Bloom, Tony, 492 Bobrow, Daniel, 235, 294, 434 Bochmann, G. V., 149 Bnehm, Barry, 175, 780 Bollt, S., 434 Bond, Elaine R., 434 Booeh, Grady, 739 Boom, Hendrik, 74 Bosack, Len, 290 BOSS (Burroughs Operational Systems Simulator), 397 Bouhana, James P., xvi Bourne, Steve, 58, 78, 692 Bowlden, Henry, xiii, 58
857
INDEX
Bowles, K., 105 Boyer, Roger, 336 Branquart, Paul, 41, 58 Brehault, Major, 183 Bright, Walter, 709 Bfinch Hansen, Per, 108, 12, 687 Brodie, Jim, 686 Brooks, Frederick E, Jr., 1,3, 19, 21, 25, 693, 756 Brooks, Rodney A., 253, 254 Bruck, Dag, 752 Bruynooghe, Maufice, 337 Bryan, Richard L., 254 Bryant, R. E., 148 Budd, Tim, xiii Burke, Glenn S., 244, 254 Burks, Arthur and Alice, 792 Burroughs Algol, 135 Bustard, D. W., 155 Butterfly PSL, 298 Buxton, John, 216 Buxton, John N., 393 C C, 14, 17-18, 21-22, 47, 137, 158, 161,200, 243, 265, 406, 480, 604, 699-700 C with Classes, 700 C++, 21,50, 157-158, 162, 406, 491, 699, 778 C-ATLAS, 22 C-SIMSCRIPT, 401 CSL 2, 378, 380 C-ATLAS, 22 C84, 716 Canaday, Rudd, 673 Cannon, Howard I., 246, 254 CAPS-ECSL, 402 Cargill, Tom, 712 Carl Hewitt's theory, 249 Carlson, William, 183 Carrette, George J., 254 CCNPascal, 151,159 Cedar/Mesa, 491 Ceyx, 258 Cg:, 617 CGOL, 287 Chaiiloux, J6r6me, 257 Chambers, Craig, 482 Charniak, Eugene, 293 CHILL, 22 Church, 295, 299 CINEMA, 406 Clark, Brian, 492 Clausen, Dr. Horst, 184 Clinger, Will, 258
858
CLISE 239 CLOS, 246, 266, 713 CLU, 471,481,491,711 CML, 404 CMS-2, 197 COBOL, 16-18, 21-22, 49, 98, 172, 197, 265, 399, 430, 445 COGO, 17 Cohen, Jacques, xi, 332 Cohen, Paul, 183 Coleman, D., 148 Colmeraner, Alain, xii, 332 COMIT, 292, 430, 604 Common LISP, 21,249, 264 Common Lisp Object System, 238 Common Objects, 266 CommonLoops, 266, 315 CommSpeak, 617 COMNET 11.5, 404 Concurrent C, 151,164 Concurrent Euclid, 151,163 Concurrent Pascal, 134 Conicon, 617 Corm, Rick, 221 Connection Machine Lisp, 298 Conniver, 250, 261,293 CONSIM, 404 Control Data 1604, 383 Conversational FORMAC, 449 CONVERT, 293 Conway, Richard W., 377, 393 Cool, 158 Cooper, CDR Jack D., 183 Coplien, Jim, 718 CORAL 66, 197 CORC, 392 Cornell List Processor (CLP), 392 Cortada, James, 793 COURSEWRITER, 17 Coutant, Cary A., 603 CPL, 692 Cressey, David, 293 CS-4, 197 CSL2, 396 CSP 11, 401 CSP/k, 151 CTSS, 386, 434 Currie, lan, 58 Cuttle, M. R., 180 Curtis, Dorothy, 492 Curtis, Pavel, 272 Cyert, Richard M., 393 D
Dahl, Ole-Johan, 131, 155,282, 377, 393,492, 733
Daniels, Bruce, 293 Danseran, Jules, 340 Data Systems Division, 430 Dausmann, M., 218 Davies, Julian, 295 Day, Mark, 765 DEC VMS, 14 DeLauer, Richard, 220 Delfosse, Claude M., 401 DELTA, 400 DeMichiel, Linda, 266 DEMOS, 404 Denelcor Fortran, 161 Denning, P J., 156 Dennis, J. B., 148 Dennis, Jack, 475, 492 DeRoze, Barry, 180 Deutsch, Peter, 234, 244, 294, 745 Devedll, Robert, 144, 159 Dewhurst, Steve, 719 Di Nitto, Samuel A., 183 DIBOL, 22 Diffie, Whit, 243 Dijkstra, Edsger, 33, 39, 99, 108, 123, 295 Dill, David, 254 DoD-I, 17 DRAFT, 402 DRAFT/FORTRAN, 402 DRAFT/GASP, 402 DRAFT/SIMON, 402 DRAFT/SIMULA, 402 Druffel, Larry, 215 DSD, 430 Duba, Bruce, 281 Duncan, C. W., Jr., 208 Duncan, Fraser, 33 Dunman, 149 Dussud, Patrick, 266 Dybvig, R. Kent, 258 Dylan, 320, 323 DYNAMO (DYNAmic MOdels), 389 E
Earl of Lytton, 209 Early ALTRAN, 437 Eaves, Laura, 719 Eckhouse, Richard, xvi ECL, 197, 286 ECSL (E.C.S.L), 396 ECSS, 401 Edison, 153, 156 EDSIM, 397 Eiffel, 718 ELI, 286, 474, 604
INDEX
Elder, J., 108 ELISP, 243 Ellis, Dave, 492 Ellis, Margaret, 742 Elzer, Dipl. Phys. Peter, i 84 Emerald, 151 Emmet, Mark B., 603 Enea, Horace, 287 Enslow, LTC Philip H., 194 Envos Common Lisp, 264 Euclid, 158, 197 EULER, 32 EuLisp, 257 Evans, Bob, 430 Evans, Thomas G., 234 Evey, R. J., 432 Excel, 7 Extended Pascal, 22 Extends, 261 EZ, 617 F
Fahlman, Scott E., 252, 254 Fano, R. M., 387 FAP, 387 Fateman, Richard J., 243, 254, 263 Feinberg, Neal, 254 Feldman, J. A., 156 Feldman, Michael, xi, xiv, 173 Feldman. Stu, 691,723 Felleisen, Matthi&~,281 Fellows, Jon, 146, 156 Fikes, Richard, 294 Fischer, Ronaid, 768 Fisher, David A., 175, 184 Fisher, Gerald, 219 Fisker, Richard, 62 Flamm, Kenneth, 776 Flavors, 252, 261,319 Flow Simulator, 394 Floyd, Robert, 335 Foderaro, John, 254, 263, 326 Fonorow, Owen R., 603 Ford, Henry, 774 FORDYN, 389 FORMAC, ! 7, 429 FORMAC 73, 449 Formula ALGOL, 430, 437 Forrester, Jay Wright, 389 FORTH, 17, 21 FORTRAN, 6, 14, 16-18, 20-22, 44, 98, i 54, i 60, 197, 265, 273, 338, 378, 430, 482, 673, 707, 775 FORTRAN II, 382 FORTRAN IV, 444
FORTRAN List Processing Language (FLPL), 321 Frames, 261 Franz Lisp, 253, 257, 263 Franzen, Wolfgang, 145 Fraser, Sandy, 715 Freiling, Mike, 296 Friedman, Daniel, 250, 319 Frost, Martin E., 261 Fuller, Sam, 245 G G, 617 Gabriel, Richard P., xiii, 243, 254 Galler, Bernard A., xi-xii, 696 Galley, Stu, 293 GAMMA, 400 Gargaro, Anthony, xiii, 219 Garwick, Jan V., 33, 34, 393 GASP (General Activity Simulation Program), 383 GASP 11, 397 GASP IV, 401 GASP VI, 402 GASP_PL/I, 402 GASPPI, 405 Gehani, Narain, xiii GEMS (General Electric Manufacturing Simulator), 377 General Purpose System Simulator (GPSS), 376 General Simulation Program, 378 Genesereth, Michael, 287 Gibson, Rick, x, xv-xvi Gigley, Helen M., xi Ginder Joseph, 254 GKS, 18 Goldberg, Adele, xiii, 511,590 Goldberg, Robert E., 603 Golden, Jeff, 239 Goldstein, Ted, 745 Goodenough, John, 214, 488 Goos, Gerhard, 33, 37, 218 Gordon, Geoffrey, 374 Gordon simulator, 376 Goren, Ralph, 290 Gorlen, Keith, 739 Gorn, Saul, 20 Gosper, Bill, 238 GPS K, 394 GPSS, 16-17, 21,372, 376 GPSS 1100, 400 GPSS V/6000, 400 GPSS/360, 394 GPSS/H, 400
GPSS/NORDEN, 399 GPSS/PC, 404 GPSS/UCC, 394, 400 Graef, N., 149 Green, Cordell, 341 Greenberger, Martin, 386 Greenblatt, Richard, 238, 254 Greene, Joseph, 220 Greif, Irene, 296 Greussay, Patrick, 244 Griesmer, James H., xiii, 453, 467 Grisoff, S. E, 432 Griss, Martin L., 242, 254 Griswold, Madge T., 599, 623 Griswold, Ralph E., 599, 622, 623 Grove, H. Mark, 180 Graen, R., 434 GSP (General Simulation Program), 374 Gudeman, David, 603 Guetzkow, Harold, 393 Guthrey, Scott, 329, 766, 768 Guttag, John, xiii, 491 Guzman, Adolfo, 318 H
Habermann, Nice, 103,492 Haddon, 152 Hagiya, Masami, 263 Hailpern, Brent, xi-xii, 453 HAL/S, 197 Halbert, Dan, xvi Hale, Roger, 296 Halfant, Matthew, 284 Halstead, Bert, 298 Hamilton, Ross, 2 Hamming, Dick, 24, 774, 831 Hansen, Walter J., 602 Hansen, Wilfred, 74 Hanson, David R., xiii, 602 Harris, Brian, 340 Hart, Timothy P., 234, 274 Hartheimer, Anne, 258 Hartley, Alice, 235 Hartley, Leslie, 26 Hartmann, A. C., 143, 157, 159 Harvard, 434 Harvard Lisp, 326 Haskell, 320 Hayden, Charles, 147, 157 Hearn, Anthony, 242,467 Hedrick, Charles L., 243, 254 Heidebrecht, B., 146 Heidorn, George E., 393,402 Heilmeier, George, 175 Heimbigner, D., 146, 158
859
INDEX
Henderson, Austin, 492 Henneman, William, 239 Hennessy, J., 158 Henriksen, James O., 400 Hensley, R. D. "Duke", 180 Her Royal Highness Queen Elizabeth 11, 195 Heron, Andrew P., 603 Hewitt, Carl, 475, 492 Hibbard, Peter, 30, 58, 78 High Elvish, g Hills, Robin, 393 Hirst, Janiee, xvi History of Programming Languages (HOPL 1), 376 Hixson, Harold G., 393 Hoare, C. A. R., xiii, 33, 98, 108, 124, 158, 194, 393, 475, 492 Hobhns, Thomas, 25 Holloway, Jack, 245 Holmevik, Jan Rune, 2 Holt, 151 Honeywell, 394 Hope, 320 Hopper, Grace, 19-20, 773 Homing, Jim, 491,492 Howard, 152 Hudson, Randy, xi-xii I
IBM, 376, 430 IBM 650, 2O IBM 1410, 383 IBM 1620, 383 IBM 704, 389 IBM 7070, 383 IBM 7074, 383 IBM 7080, 430 IBM 7090, 430, 445 IBM 7094, 383, 445 IBM PC, 406 IBM System/360, 445 IBM VM System, ! 4 1BSYS, 430 IBSYS/IBJOB, 442 lchbiab, Dr. Jean, xii, 195, 473, 687, 764 ICON, 21,600 Idol, 617 lngargiola, G., 159 lngerman, P. Z., 33, 34 INSIGHT, 407 lnsinga, Aron, 752 INTERACTIVE, 407 lnterlisp, 235 lnterlisp 370, 315
860
lnterlisp- 10, 241 lnterlisp-D, 241 lnterlispNAX, 244 IPL-V, 604 Ireland, Terry, 183 ISLisp, 320 IT, 20 Iverson, Ken, 14 J Jaeschke, Rex, 682 Jan'ell, Thomas H., 183 Jarvis, Pitt,, 245 JASE 397 Jeffery, Clinton L., 603 Jenks, Dick, 467 Jensen, Kathy, 100 Jet Propulsion Lab, 435 Joachim, T., 149 Johnson, Paul, 492--493 Johnson, Steve, 715 Jones, Greg, 778 Jones, Malcolm M., 386, 393, 397 Joseph, M., 159 JOSS, 16...-17,287 JOVIAL, 16--17 JOVIAL J-3B, 197 JOVIAL 1-73, 197 Joy, Bill, 327 Joyce, 153 Juhl, Peter, 752 K
Kaban, W., 284 Kabane, Robert, 183 Kabn, Ken, 296, 291 Kanoui, Henry, 334 Kaput, Deepak, 492 KAREL, 22 Kaubisch, 151 Kay, Alan C., xii, 25, 245, 775 Keedy, 152 Keene, Sonya, 266 Kelly-Bootie, S., 766 Kemeny, John, 19-20 Kempf, Jim, 266 Kenney, Robert, 434 Kemighan, Brian, 729, 775 Kerridge, J. M., 149, 160 Kessels, 152 Kiczales, Gregor, 266 Kidder, Tracy, 774 Killian, Earl A., 254 Kindler, Evzen, 393 Kittredge, Richard, 340 Kiviat, Philip J., xiii, 383, 395
Klaeren, Herbert, 767 Kleene, 280 Kligerman, 151 Knight, Thomas, 245 Knoble, H. D. (Skip), 449 Knuth, Donald E., 393 Knath's Metafont, 291 Knuttilla, Kim, 752 Koenig, Andrew, 720, 727 Kohlbecker, Eugene, 266, 281 Komorowski's QLOG, 291 Koopman, Phil, xiii Kopp, Major AI, 183 Korb, John T., 602 Kosinski, Paul, 492 Koster, Kees, 33, 57 Kotulski, 152 Kowalski, Robert, 332, 334 Krasnow, Howard S., 393 KRL (Knowledge Representation Language), 297 Krogdahl, Stein, 733 Kmijer, H. S. M., 149, 160 Krutar, 295 Kuhn, Thomas S., 774 Kuipers, Benjamin, 296 Kulp, John L., 254 Kunze, Fritz, 263 Kurtz, Tom, 20 Kyoto Common Lisp, 262 L Lachner, Arehie, 752 Lackner, Michael R., 393 Lamb, D., 218 Lampson, 151 Landin, Peter, 33, 41,250, 320 Laski, John N., 393 Laventhal, Mark, 492 Layer, Kevin, 327 Layton, Christopher, 195 Le Gloan, Htl~ne, 337 Le_Lisp, 244 Lea, Doug, 739 Lecarme, 103 Leda, 617 Lee, John A. N., ix-x, ! Lee, Peter, xiii Lehmer, 238 Lemone, Karen, xvi Lenkov, Dmitry, 747 Lesk, M. E., 680 Levin, Roy, 488 Licklider, I. C. R., 387, 393 Lindsey, C. H., 27, 33, 691 Linton, Mark, 739
INDEX
Lippman, Stan, 720 LIS, 197 Liskov, Barbara, 492 LISP, 7, 17, 22, 36, 234, 430, 438, 482, 708, 734 LISP 1.5, 17 Lisp 2, 235 Lisp, Fmnz, 243 Lisp-Machine Lisp, 235, 244, 252 Lisp/VM., 248 Lisp1.6, 243 Lisp360, 248 Lisp370, 248 Lister, 152 Little Smalltalk, 617 Little, Arthur D., 447 Llewellyn, Robert W., 389 Locanthi, Bart, 729 Logicon, 617 LOGLISP, 291 LOGO, 295 Logothetis, George, 720 L~Shr, 149 London, Tom, 681 LOOPS, 315 Lord Byron, 207 Loveland, Donald, 332 LTR, ! 97 Lubin, John E, 393 Lusk, E. L., 160, 161 Lynch, W. C., 161 M
M-460 Lisp, 283 Macintosh, 14 MacLisp, 235 Macrakis, Stavros, 328, 765 MacScheme, 258 MACSYMA, 17, 21,238, 283, 438, 451 MAD, 17 MADCAP, 17 Maddux, R. A., 148 Mager, Peter S., xvi Maghami, Habib, 146 Magic Paper, 438 Magma2, 617 Mahoney, Michael S., xi-xiii, xiv, xvi, I-2, 23, 453 Mailloux, Barry, 19-21,33...-34 Malagardis, Nicholos, 184 Manley, Lt. Col. John H., 183 MAPLE, 438, 451 Marciniak, Lt. Col. John, 183 Marcotty, Michael, xiv Markowitz, Harry, 21,377, 395
Marlowe, Tom, xiv Marrnier, E., 99, 108 Martin, Bill, 467 Mary Poppins Edition, 255 Masinter, Larry M., 254 Masticola, Stephen P., 2 Mathematica, 438, 451 Mathis, Robert E, 215, 265 MATHLAB, 438 MATHLAB 68, 438 MATHMATICA, 21 Matson, Todd, 296 Mattson, S. E., 149 Maxwell, William L., 393 McCarthy, John, 33, 35, 234, 254, 387 McClary, T. E., 180 McClure, R., 673 McConeghy, Robert, 603 McDermott, Drew, 293 Mcllroy, Doug, 673, 709, 778 McKeag, Mike, 134, 473 McKeeman, William, xiii McKnitt, Wendy, 767 McLennan, Marilyn, 296 McNeley, John L., 393 MDL, 238 Meek, Brian, 765 Meertens, Lambert, 58, 62 Meloni, Henry, 337 Mendolia, A. 1., 180 Memer, J. N., 33, 34 Mesa, 151,161,163,475,711 METEOR, 292 MicroPlanner, 261,293 Mikel, Andy, 107, 696, 767 Mikelsons, Martin, 248 Mills, H., 148 Minimal, 605 MINUTEMAN Software, 404 MIT, 386, 389, 434 Mitchell, Jim, 475, 492 Mitchell, William H., 603 ML, 320, 491,711 MLISE 287 MODSIM, 408 Modula, 151,156, 705 Modula-2, 109, 158, 163, 708 Modula-3, 158, 161,491,718 Modular, concurrent programming, 134 M¢ller-Nielsen, P., 150 Monitors, 122 Moo, Barbara, 720 Moon, David A., 238, 246, 254 Moore, Jay, 336 Moore, Jim, 294
MORAL, 197 Morgenstern, Oscar, 393 Morris, James H., 475, 492 Morris, R., 673 Morrison, Don, 254 Morse, Philip, 393 Moses, Joel, 238, 249, 439 Moss, Eliot, 4?8, 492 MS-DOS, ,406 Muddle, 238, 251,293 muLisp, 257 MULTICS operating system, 397 Multilisp, 298 MultiScheme, 298 MUMPS, 17-18, 21-22 Murphy, D. L., 235 MVS/360, 14 Myszewski, Matthew, 434 N
Nance, Richard, 768 Narayana, 151 Naur, Peter, 33, 37 Neal, D., 148 Nehmer, 151 Nelson, Greg, 491,492 Nelson, Peter, 686 Nestor, J., 218 Neve, Nick, 184 New Flavors, 266 Newell, Alan, 20, 21 NGPSS (Norden GPSS), 399 NIL, 243 Nilsen, Kelvin, 603 Nilsson, Nils, 294 Nishiham, Keith, 296 Norberg, Arthur, 776 Nori, K. V., 144 Nowlin, Jerry, 603 NPL (New Programming Language), 395, 445 Nutt, Roy, 20-21 Nygaard, Kristen, 155, 377, 764, 776 O O'Bagy, Janalee, 603 O'Neill, Judy, 776 Oberon, 109 Object Lisp, 266 Objective C, 741 Ockene, Arnold, 393 Oldfather, Panla, 395 Olsen, Ken, 2 Operating System Principles, 133 OPS-3, 386 OPS-4, 397
881
INDEX
OPS5, 22, 293 Orcutt, Guy H., 393 OS/360, 14, 446 OS/360 Job Control Language, 9 Overbeek, R. A., 160, 161 P
Palrne, Jacob, 194 PANCM, 22 Pandey, Rajeev, 2 Papert, Seymour, 295 Parayre, P. A., i 84 Parente, Robert J., 393 Parnas, David, 152, 194, 476 Parslow, R. D., 393 Pascal, 14, 17, 21-22, 43, 123, 154, 197, 284, 406, 479, 617, 684, 701 Pascal Phts, 151,163 Pascal-FC, 151 Pa~scale, 151 Pasero, Robert, 332 PASSIM, 407 Paul, Manfred, 33 PC DOS, 14 PDL/2, 197 PDP-1 Lisp, 234 PDP-10 MacLisp, 238 PDP-6 Lisp, 235 PEARL, 197 Peck, John, 33, 36 Pederson, N. Holm, 162 Pegden, C. Dennis, 405 Perdue, Cdspen, 272 Pereira, Feroando, xiii, 337 Perl, Sharon, 492, 605 Perlis, Alan, 20, 21,301,775 Perry, William J., 204 Pfister, Greg, 293 Piaget, Jean, 831 Pike, Rob, 686 PILOT, 17, 22 Pitman, Kent, 280 PL/I, 6, 14, 17-18,21-22,43, 135, 137, 197, 291,395, 437, 445, 474 PL/I GPSS, 403 PL/I subset, 22 PL/I-FORMAC, 438, 445 Planner, 250 Planner-70, 293 PLANNER-71,295 Planner-73, 296 PLASMA, 296 Plauger, P. J., 686, 775 Plum, Tom, 686
862
PLY, 151 PM, 437 Polstra, John, 603 POP-2, 246, 288 POPLOG, 290 Portable Standard Lisp (PSL), 242 Posner, David, 290 Powell, M. S., 149, 162 PPL (Polymorphic Programming Language), 287 Pratt, Vaughan, 287 Predala, 151 Presotto, Dave, 738 Price, Derek J. DeS., 775 Prince Philip, 195 Principato, Bob, 492 Pritsker, A. Alan B., 397, 403 Programming By Questionnaire (PBQ), 402 Project MAC, 436 Prolog, 17, 21,291,604 Prosser, Dave, 686 Pugh, Ilk Alexander L., 389, 393 Pyle, lan, 194
Ringstr6m, 151 Ritchie, Dennis M., 671,709 Robert, Jean, 184 Roberts, Edward B., 389 Roberts, Stephen D., 407 Robinson, Alan, 332 Rochester, Nathaniel, 430 Rose, Leonie, 718 Rosenberg, A., 434 Rosin, Robert E, xi, xiv, 453, 768, 778 Rosier, Larry, 686, 725 Ross, Douglas T., 33, 39, 393, 492, 766 Roth, Paul F., 397 Roubine, 147 Roussel, Philippe, 331 Roylance, Gerald, 284 RTL/2, 197 Rulifson, Jeff, 294 Rummier, LCDR David C., 183 Russell, Steve, 234, 285 Ryder, Barbara, xi-xii Ryniker II, Richard W., 248 S
Q Q-32 Lisp, 283 Q-GERT, 399 Q-systems, 332 Qlisp, 261,298 Quam, Lynn, 243 QUIKSCRIPT, 392 Quinn, C., 106 Quux, 301 R
RAND Corporation, 395 Randell, Brian, 33, 37, 7022 Ratfor, 606 Ravn, A. P., 149, 163 Raytheon, 435 RCA, 394 Real-time Euclid, 151 Rebus, 617 REDUCE, 242, 283, 438---439, 449 Rees, Jonathan, 251 Rees, Mina, 792 Reeve, Chris, 293 Reiser, John, 680 Reitman, Julian, 393 REXX, 605 Reynolds, C. W., 163 Reynolds, Carl, 430 Reynolds, John, 250, 492 Richards, Martin, 673, 757 Rifken, Adam, 765
S-1 Lisp, 251 S-I NIL, 253 Safe Ada, 160 SAIL, 288 SAINT (Systems Analysis for Integrated NetworLs of Tasks), 403 Samelson, Klaus, 20, 33, 35 Sammet, Jean E., ix, xi, xiv-xvi, 1,226, 235, 432 Saunders, Robert, 234 SB-Mod, 151 SCEPTRE, 17 Schaffert, Craig, 478, 479, 491,492 Schamber, Lt. Col. Joseph G., 183 Scheifler, Bob, 481,492--493 SCHEME, 22, 235,261 Scheme 31 I, 249, 251 Scheme, Chez, 258 Schemer, 250 Scherlis, William L., 253, 254, 290 Sch6n, Donald, 6 Schuman, Stephen, 58, 75 Schwarz, Jerry, xiii, 729 SCL, 604 SCOPE 3.3 operating system, 400 SCRATCHPAD, 248, 467 SCRATCHPAD/I, 439 Seegmiiller, Gerhard, 30, 33, 34 Seque, 617 SEQUEL, 18
INDEX
Sequence Diagram Simulator, 374 Sequential Pascal, 144 Sethi, Ravi, 684, 728 SEUS, 290 SHARE, 436, 775 Shaw, C. J., 20 Shaw, J. Cfiff, 20, 21 Shaw, Mary, 475, 492, 778 Sheppard Nelson, Sally, 404 Sheridan, Peter, 20, 21 Sbopiro, Jonathan, 715 Shrobo, Howie, 296 SICSAM, 437 SIMAN, 404, 406 SIMFACTORY 11.5, 404 SIML/I, 403 Simon, Herbert A., 20-21,393 Simone, 151 SIMPAC, 383, 392 SIMPAS, 406 SIMPL, 403 SIMPL/I, 403 SIMPL/I X, 403 SIMPLE, 389 SIMSCRIPT, 17, 21,377 SIMSCRIPT 1.5, 17, 378 SIMSCRIPT 11, 378, 394 SIMSCRIPT II.5, 17 SIMULA 67, 17,21,40, 131, 154-155, 158, 197, 295, 319, 372, 376, 394, 479, 699 SIMulation ANalysis for modeling, 406 Simulation Language for Alternative Modeling (SLAM), 404 SIN (Symbolic INtegration), 441 Sintzoff, Michel, 33, 41 Sisson, R. L., 393 Sketchpad, 775 Sklower, Keith, 327 SL5, 599 Slagle, 467 SLAM 11, 404 SLAM 11PC animation program, 405 SLAMSYSTEM®, 405 Smalltalk, 7, 21, 25, 158, 295, 479, 511,708 Smalltalk 71,319 Smalltalk 72, 319 Smalltalk 80, 17 Smith, Brian, 296 Smith, Christopher, 603 SML, 42 SNOBOL, i 7, 293, 599 SNOBOL4, 17, 599
Snyder, Alan, 320, 478, 492, 679 SOL, 386, 392 Solo system, 145 SP/k, 163 Special Interest Group (SIGSAM), 450 Spice Lisp, 252, 259 SPL/I, 197 SPS-i, 377 Squires, Steve, 183 Stallman, Richard M., 238, 254, 270 Standard Lisp, 242 Stanford Lisp 1.6, 283 Stannstrup, Jergen, 146, 150 Steel, T. B., Jr., 393 Steele, Barbara K., 254 Steele, Guy L., Jr., xiii, 238, 254, 687, 764 Stellin, Franqois, 340 Stepczyk, E, 146 Steward, Gilles, 340 Stieger, Richard, 296 Stoy, Joe, 492 Strachey, C., 692 Strachey, Christopher, 393 Stroustrup, Bjarne, 778 STRUDL, 22 Summers, Patricia, 2 Sussman, Gerald Jay, xiii, 249, 293 Swade, Dorin, 2 Symbolic Mathematical Laboratory, 438 SYMSAM, 438 SYSLISP, 242 SYSTEM/360, 394, 445 T T, 251 TABLOG, 291 TACPOL, 197 Taft, William Howard, IV, 220 Talcott, Carolyn, 290 TAO, 291,316 Teichrow, Daniel, 393 Teitelman, Warren, 239 TELOS, 288 Than, Robert, 696 The Architecture of Concurrent Programs, 146 Thompson, Ken, 672, 686, 757 Tiemann, Mike, 713 Tobey, Robert G., 431,432 Tocher, K. D., 374 Tolkien, J. R. R., 8 Tomash, Erwin, 2 Touretzky, Dave, 313
Trellis/Owl, 491 Trudel, Jean, 332 Tsujino, 151 Turing Plus, 151 Tudng, Alan, 2 Turski, W. M., 33 U UCI Lisp, 243 Uldch, John, 258 Ungar, Dave, 482 United Aircraft, 435 United Technologies, 20 UNIVAC, 400 Univac 1107, 377 Unix, 14 Uzgalis, Robert, 58, 62 V van Caneghem, Michel, 337 van der Meulen, Sietse, 38, 58 van der Poel, W. L., 14, 33, 34 van Deusen, Mary, xvi, 219 van Emden, Maarten, 335 van Roggen, Walter, 254 van Sant, Kathy, 296 van Vliet, Hans, 76 van Wijngaarden, Aad, 20, 30, 32, 33, 340 vanMelle, William, 254 VAX lntedisp, 243 VAX NIL, 244 Vaxima, 263 VHDL, 22 Vilot, Mike, 739 Vlisp, 244 yon Neumann, 241 Vossler, R., 146 VP/CSS time sharing system, 399 W Wada, Eiiti, 492 Waldinger, Richard, 294 Walker, John, 226 Walker, Kenneth, 603 Wallentine, V., 148, 163 Wampler, Stephen B., 603 Wand, Mitchell, 250 Ward, Judy, 720 Warren, David, 337 Washam, Ware, 405 Waters, Richards, 272 Webb, John, 194 Wegbreit, Ben, 286, 294 Wegman, Mark, 248 Wegner, Eberhard, 184
863
INDEX
Wegner, Peter, 778 Weinberg, Gerald M., 775 Weinreb, Daniel L., 2.54 Welsh, J, 106, 108, 151 Weschler, Allan C., 254 Wetberall, Philip, 184 Wett~tein, 152 Wexelblat, Richard L., ix, xi, xii, xvi Weyhranch, Richard, 290 Whiddetl, 151 Whitaker, William, xii White, Jon L., 238, 254 Wichmann, Brian, 194 Wilkinson, Nancy, 720 Williams, Michael R., x
884
Williams, Ted, 195 Wills, Cheyenne, 603 Winterstein, G., 218 Wirth, Niklans, xii, 33, 123, 151, 687, 691 Wirth/Hoare, 30, 32 Wise, Dave, 319 Woodger, Mike, 33, 37 Wulf, William, 218, 251,475, 492, 691 Y Yngve, 293 Yoneda, Nobuo, 33, 41
Yonizawa, Aki, 296 Yuasa, Taiichi, 262 Z Zernpolich, Bernard, 176, 183 Zepko, T., 164, 144 Zetalisp, 235, 256 Zicrnicki, Col. Robert, ! 83 Zilles, Stephen~ 434, 473, 475, 478-479, 492 Zippel, Richard, 254 Zubkoff, Leonard, 254 Zuse, Konrad, 2