SUBALGOL(ID:7279/sub002)Stanford extensions to BALGOLExtensions to BALGOL (which was an Algol 58 language) at Stanford 1960 Related languages
References: On the console of the Burroughs 220 at the Stanford University Computation Center is a sign which reads: "The purpose of computing is insight, not numbers." Despite this noble philosophy of Richard Hamming's, the Computation Center considers itself a problem-solving "factory," and although the goal of an efficient computing job shop is not an uncommon one, Computation Center Director George Forsythe feels that the Burroughs Algebraic Compiler (BALGOL) has allowed his center to achieve new lows in button-pushing. Stanford's 220 has a 10K memory, five tape units, and a one-in, two-out Cardatron card-handling subsystem. The Computation Center also has a 650, which sees limited use by those familiar with its language and who want to spend the time programming it. Pointing to the IN and OUT boxes outside the 220 room, Fcrsythe says, "This is our computing machine, as far as the students are concerned. That's all they need to know." The compiling speeds of the one-pass BALGOL compiler?50 to 100 ALGOL statements per minute, which generate an average of 500 machine-language instructions per minute-make it possible for the Center to run an average of about 120 BALGOL problems per working day, plus additional work. The top production figure for one day on BALGOL runs was 288 problems in 16 hours. According to Forsythe, some large-scale computers?20 to 30 times as fast internally as the 220-take three times as long to compile using FORTRAN. This is partly because their FORTRAN compiler?for even the simplest programs ?polishes and polishes . . . and thus requires two to three minutes for the simplest kind of problem. FOR a computation center like Stanford's?interested in hundreds of problems a day?this is not the solution, says Forsythe. "Our goal," he adds, "is to convert every student at Stanford?get them out of the stone age and into the computing age." The manner in which BALGOL has helped the Stanford Computation Center move towards this goal is reflected in the low "overhead"?18 seconds per problem. Of this, Forsythe points out, 11 seconds is for supervisory printout and could be eliminated. BALGOL is described by Forsythe as something between ALGOL 58 and ALGOL 60: "It has most of the important ALGOL features and might be called ALGOL 59. Its language is rich and flexible-you are not limited in what you can say. Too, it has the capacity of easily enlarging itself-of defining new ^entities which are easily incorporated into the language." Used with a "load-and-go" compiler, it features semiautomatic segmentation. This permits the main body of the program to become a master routine which controls operation sequence and the memory assignment of program segments. Approximately 95% of the Stanford programs for the 20 are written in BALGOL, with the remainder mostly written in BLEAP, a symbolic assembly language. Forsythe also points out that BALGOL is easy to teach. The Computation Center conducts 10-hour BALGOL programming courses which are offered in two-hour sessions over one school week. So far, about 10 such courses have been offered to some 300 students. The Computation Center also offered a special pre-school course to 50 members of the engineering faculty this fall. BALGOL has also found its way into Math. 136, a general introduction to programming. For this course, Forsythe is using the 220 as a grading machine for problems written in BALGOL. To his program deck, the student adds a card which calls in a grader program from magnetic tape. The grader provides the data for each case in turn, to the student's program, which provides the solutions. The solutions are evaluated by the grader, which then summarizes the students' scores for all cases, and prints out comments. Students usually get two to three-hour service. "The computer is an ideal teaching machine." says Forsythe. The grader program is based on that developed by Perils and Van Zoeren at Carnegie Institute of Technology. In addition to its use by students, BALGOL has played a key role in work being done by the members of the University's recently established Computer Science Division, of which Professor Forsythe is also the head. Professor John G. Herriot of the Computer Science Division is using BALGOL in his work on the solution of boundary value problems by methods of kernel function. This involves a great deal of calculation ... so much that Herriot considers the work impractical without computers and compilers such as BALGOL. Using the Burroughs compiler, he was able to do the analysis and programming over a period of three to four months, working on it part-time. . With the help of a graduate assistant, Herriot is also using BALGOL in the solution of polynomial equations. They are investigating in particular, with Professor Hans Maehly, the Laguerre method of solving polynomial equations. Also, a BALGOL procedure has been written for solving differential equations by the Adams method. This incorporates an automatic change of step size and flexible output, permitting the printout of points at any desired interval. Other work in progress includes finding particular solutions of more general partial differential equations than that of Laplace. "Here BALGOL has been especially helpful in translating equations to a program for the machine," says Herriot. John Welsch, Alan Shaw and James Vandergraft of the Computation Center have prepared magnetic tape handling routines for use with BALGOL. These include external procedures for reading, searching and writing on mag tape, and give the programmer a much larger memory with which to work. Welsch has completed a routine which allows a compiled program to be stored on magnetic tape for later running without recompiling. The Center has also developed an operating system which will allow programs to be compiled and run without operator intervention. A great deal of work is also being done on matrix problems?inversion and the determining of eigenvalues for both symmetrical and non-symmetrical matrices. This work will be published in the language of ALGOL 60. At one time, consideration was given to the possibility of a mechanical translation from BALGOL to ALGOL 60, but the translation is straight-forward enough so that this was deemed unnecessary. The Computation Center is also active in assisting other academic departments in their use of the Burroughs 220. The Medical School's Department of Psychiatry uses the computer in connection with its study of the learning process, especially as it is affected by removal of parts of the brain. Equipment operated by monkeys controls paper tape punches, on which monkey responses are recorded. The paper tape serves as input to the 220, which maintains an updated record of all experiments on magnetic tape. Wade Cole of the Computation Center admits this is a "simple-minded" use of a computer, but says, "It's a beginning in a field which has seen very little sophisticated use of computers." Working with Drs. J. G. Toole and J. von der Groeben of the Medical School's Department of Cardiology, Professor Forsythe has developed a program on the reduction of vector electrocardiograph data. Future medical school uses of the 220 include diagnosis, simulation, and on-line reduction of experimental data. The Computation Center has also collaborated with the Mechanical Engineering department on the numerical solution of non-linear partial differential equations for the laminar flow of an incompressible fluid. The 220 is also performing data reduction for radio-telescope signals generated in the University's radio science laboratories. Another data reduction task will involve the work of Alphonse Juilland of the department of Modern European Languages, in his studies of the relationships of the Romance Languages to Latin. Professor Juilland is investigating language structure from phonetic and lexicographical .standpoints, and will use the computer to record and compare the basic structural units of some 500,000 words of given Romance languages. Other uses of the 220 include a program being developed by Professor R. V. Oakford of Industrial Engineering for the optimal scheduling of high school classes, given the | available classrooms, courses, sections, and the number of students. The social sciences also make frequent use of the * 220 for various statistical work and data reduction. Finally, the 220 is used on the third shift by the First * National Bank of San Jose for 40 hours a week for demand, deposit accounting. According to Cole, "BALGOL has played a key role in permitting experts in various disciplines to communicate with the computer. It allows the problem sponsor to program the job himself in language with which he is familiar . . . and in the process helps remove the old communication barriers between the man with the problem and the man with the machine." Professor Forsythe adds, "BALGOL allows research to go on where it belongs." Equally important, of course, is the high-volume efficiency it brings to the closed shop operations. "The real payoff," says Forsythe, "is the ability to compile programs rapidly and to take out the errors in the source language." This latter is accomplished by the compiler, which flags violations of the rules of the language, and lists them without interruption of the compiling process. Thus a "linguistically correct" program can usually be achieved in two or three compilations. It is also possible to detect logical and other programmer errors through the addition of temporary output statements, which are easily added or removed, since the program is normally recompiled every time it is run. Additional monitoring facilities, dumps and traces have , ,, also been added to the compiler by Burroughs, which is bringing out a new edition this month. For Chief of Operations Al Collins, the value of BALGOL can be directly measured in dollars. "The Burroughs Algebraic Compiler is worth $10,000 a day," he , says. The estimate is based on the fact that the 220 is' in the compile mode four hours a day ... at a compiling rate of 500 instructions a minute, this represents 120,000 commands a day. "If only one out of five commands compiled is of value ?and that's a conservative estimate?this represents 24,-000- instructions, equivalent to the output of approximately 200 programmers, who represent a daily cost?including overhead?of $10,000. Another way of looking at it is that BALGOL commands cost approximately 8^ each, compared to $8.00 a machine-language command." "But no matter how you look at it," concludes Collins with a smile, "one thing is certain: a slow computer .and a fast compiler have combined to make this one happy shop." in Datamation 7(12) Dec 1961 view details As President of the Association for Computing Machinery I welcome you to this Conference on Programming Languages and Pragmatics. Many thanks are due to the System Development Corporation for sponsoring the conference. Even more thanks are due to the computer scientists around the world who created the subject of programming systems and brought, it to the point where it merits a third major conference of this type. You will recall that the first conference was held in Princeton in August, 1963 on the syntax of languages. A second conference on the semantics of languages was held in Vienna in September, 1964. And now this week's conference takes up the pragmatics of languages. I am glad that it is the meeting on pragmatics to which I am privileged to address a welcome, for I am fundamentally a user of computers. As a numerical analyst, I mostly want to get my work done and my problem solved. As a teacher of elementary programming in Stanford's Computer Science Department I am most concerned that the languages be practically usable to the learner, and that the systems permit me to use the computer to help the stu-dent. I hope that pragmatics deals with those questions! Let me be specific: The two most pleasant language systems for the general scientific user that I happen to know of are both in the ALGOL 58 family: they are the Michigan MAD system and the BALGOL system for the Burroughs 220 computer (later expanded at Stanford into SUBALGOL). Let me concentrate on BALGOL, which I know better. In addition to the general features of ALGOL which most of you know, the BALGOL system had two splendid features for a user like me: (1) The combination of language and compiler had Lhe accommodating property of "making do" in spite of programming errors. In presence of some stupid error, like the omission of a paren, the system did its best to remedy the error, write you a warning about it, and then go on to complete the compilation and enter execution. This usually meant that we could learn about the run-tim behavior of at least that part of our program which preceded syntactical error. This feature always struck me as a very reasonable and pragmatically satisfactory approach to the customer. I have been grieved to find that our ALGOL 60 compilers have not been able to supply this service. When I ask our people about it, they tell me that, ALGOL 60 isn't the kind of language you can do this with. If this is so, it seems to represent a large pragmatic deficiency in ALGOL 60. Is ALGOL 60 a language which can deal gracefully only with programming perfection, but collapses in the face of error? Whether the answer in yes or no, I hope you will put this property of accommodation to error into your list of useful characteristics for systems to have. (2) The other nice property of the BALGOL system was a twofold one. First, the compiler could be persuaded to generate a relocatable machine-language procedure from a BALGOL procedure declaration. (Mr. Roger Moore was the persuader.) Second, Burroughs furnished customers not just a compiler, but actually a compiler generator, so that we could at any time create a new compiler with any library for which we could furnish machine-language relocatable procedures. With these two features together, I could write teaching and grading programs in BALGOL separately for each problem. A small amount of operator work would enable these to be compiled into the compiler's library, where the students could have access to them in a most convenient way. I was quite disappointed to find that none of the compilers on our IBM 7090 or Burroughs B-5000 systems were able to duplicate this convenient feature, for various reasons I do not understand. I am not here to sell you the obsolete Burroughs 220 computer system. But I am trying to illustrate some good pragmatic properties of a certain system. Such a system was conceived by a team which surely had the user's point of view clearly in front of them. And I just happen to think that the computer user is a mighty important person, and a person who is all too easily forgotten in this world of systems experts. If computing is to become the public utility that so many of you speak of, then computer folk had better start emulating successful utilities people. Let me cite the Bell Telephone System as one successful utility, however you look at it. You will note that its changes are made gradually, after very substantial customer research and shake-down periods. You will note that the steps from research to operation are many, slow, and carefully controlled. I have heard it said that the Bell Telephone Laboratories has hundreds of people with thousands of ideas for changing the telephone system, and that any one of these people could utterly bankrupt the service, if he were left free to put his own research ideas into practice! So the Bell System has ways to keep the flow of research ideas orderly. Let us hope that computer scientists use their imaginations and devise all kinds of interesting things in their research. But let us also devote substantial research time to finding out what languages and systems are best suited to the men with the problems to be solved. And let us strive for decision processes which will permit us to adopt the best systems, and for enough orderliness to keep change gradual. Computing has become too important in our civilization to be aJlowed the privilege of disorder in its operational progress. I wish you the greatest of success in your conference on pragmatics! in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details |