1 Use and maintenance of ALGOL 60

In the February 1960 issue of the Communications of the ACM, a new department, ‘Algorithms’, was announced and it was dedicated to algorithms written in the ALGOL language.¹ Until the publication of the ALGOL 60 report in May 1960, the ALGOL language used in this department was IAL, after that, it was ALGOL 60. Later, ALGOL 60 was also used in several books and other journals like the Computer Journal, Numerische Mathematik, B.I.T., and ALGORYTHMY.²

For years, it was the main communication language for algorithms. Besides, it was also a popular language to teach programming at universities. As a result, whole generations of computer scientists grew up with ALGOL 60 and were influenced by ALGOL 60.

Although ALGOL 60 was the most used programming language for man-to-man communication, it was certainly not the most used algebraic programming language to instruct computers with. Unfortunately, there are no sources on the use of ALGOL 60 or, for that matter, on the use of any other programming language. Two observations can be made, however: ALGOL 60 was used more in Europe than in the USA and ALGOL 60 was more popular in academic circles than in industry.

In the early 1960s, the computing community in the USA was much more developed than in Europe. Consequently, there was already a large amount of programs written in certain languages. Switching to a new language without a trusted implementation and not backed by a computer manufacturer was almost impossible. Migration to a new language would mean retraining of experienced programmers and rewriting of working software.

In Europe, the computing community was strongly influenced by the American industry, especially by IBM. On the other hand, the development in computer science took place at universities and research centres and ALGOL was popular in these circles. Furthermore, the European computing industry was emerging and the legacy of already existing software was much smaller than in the USA. In Germany, the government stimulated the use of ALGOL by requiring an ALGOL implementation on every computer ordered by a university. Although the USA government did support COBOL for data-processing, it did not support a language for algebraic applications.³ Consequently, a new language like ALGOL 60 was able to gain more support in Europe than in the USA.

The popularity of ALGOL in universities and research centres can be explained by the nature of the ALGOL effort and its results. The ALGOL effort introduced the BNF and some new programming language concepts. Furthermore, it stimulated research on formal languages, programming languages, and translation techniques. In other words, the ALGOL effort was for a part an academic effort.

As said before, switching to ALGOL 60 was in industry not economically sound. There were more reasons why ALGOL was not accepted by industry, however. According to a survey on programming languages and processors from late 1962 there were many different ALGOL translators from different groups and companies.⁴ FORTRAN, on the other hand, had also many translators, almost all of them, however, were made by IBM.⁵ Hence, FORTRAN was conceived as a standard and ALGOL was not.

FORTRAN was pushed by IBM and IBM became the biggest computer manufacturer in the 1960s. At the RAND Symposium in 1961, the future of ALGOL was discussed. Bemer started the discussion with: ‘No reasonable mechanism for maintenance seems to exist. No one seems to be able to answer the basic question, “What is ALGOL?” I foresee a difficult time for ALGOL unless a revised maintenance procedure is devised. The language is too general and has too many ambiguities.’⁶ Galler added that ‘it just isn’t readable and people don’t read it.’⁷

The problem of the difficult notation in which ALGOL 60 was described would gradually disappear when the BNF became common knowledge among computer scientists. It was, on the other hand, an obstacle for many programmers to consider ALGOL 60 at all.

The problem of maintenance, however, was a more serious one. Soon after the publication of the ALGOL 60 report, it became clear that the report contained errors and ambiguities. Already in June 1960, Peter Naur wrote a letter to the authors of the ALGOL 60 report to propose four minor improvements.⁸ Unfortunately, only six authors of the report reacted and they did not agree with each other on the four changes.⁹

Meanwhile, the American ACM ALGOL subcommittee was transformed into the ALGOL Maintenance Group.¹⁰ They proposed that in Europe a similar maintenance group would be formed or that some Europeans would become members of the American Maintenance Group.¹¹ Bauer and Samelson were advocates of the latter option because they feared that two different groups would lead to two different languages.¹² Others, especially the Russians, wanted a separate European maintenance group.¹³ The Europeans held their discussions on the maintenance of ALGOL in the ALGOL Bulletin. The work of the American ALGOL Maintenance Group was also reported in that bulletin.

The difference between the European and American approach to the maintenance of ALGOL is striking. In the USA, a formal maintenance group was founded almost directly after the publication of the ALGOL 60 report. The members were coming from the universities, industry and governmental research centres.¹⁴ Although not explicitly stated, the American ALGOL Maintenance Group tried also to be a substitute for a governing body behind ALGOL. One of the main problems for the acceptation of ALGOL in industry was the lack of one responsible and stable organisation behind ALGOL. Where FORTRAN had IBM, ALGOL had just a bunch of scientists from all over the world.

2 The move of responsibility for ALGOL to Working Group 2.1 of IFIP

During 1960 and 1961, many problems with ALGOL 60 were collected and discussed. In the ALGOL Bulletin number 14, Peter Naur included a questionaire on the status of maintenance.¹⁵ Although rather lengthy, there were three main points: ambiguities and obscurities, recommended subsets, and proposed extensions. In the June 1962 bulletin the results were published.¹⁶

During March 26 – 31 1962, a symposium on Symbolic Languages in Data Processing was held in Rome. A week earlier, the Working Group 2.1 on ALGOL was established as part of Technical Committee 2 (programming languages) of the International Federation of Information Processing Societies (IFIP). After the Rome symposium, on 2 and 3 April, eight of the authors of the ALGOL 60 report, some advisors and the chairman of the new founded Working Group 2.1, W.L. van der Poel, held a meeting to clean up the ALGOL 60 report. As the basis of this meeting the answers to the questionaire of 14 were used. The result of the meeting was the Revised Report on the Algorithmic Language ALGOL 60¹⁷ and the transfer of responsibility for ALGOL to this Working Group 2.1 of IFIP. ALGOL got ‘a new home’ as Daniel D. McCracken (1962) put it.¹⁸ With this move to IFIP, it seemed that the problem of the lack of a governing body behind ALGOL was solved. However, IFIP was not a strong organisation like IBM, but an international organisation of national computing centres without any budget of its own. ALGOL got its home, but it was yet far from home.

The meeting in Rome was not completely successful. First of all, not all problems with ALGOL 60 were resolved, five problems were left to be solved by Working Group 2.1. These problems were: side effects of functions, the call-by-name concept, static or dynamic own-concept, static or dynamic for-statement, and the conflict between specification and declaration.¹⁹ Second, other ambiguities and inconsistencies remained in the language. In 1965, Donald E. Knuth published A list of the remaining trouble spots in ALGOL 60²⁰ in the ALGOL Bulletin. This list contained ten ambiguities and twelve corrections. Later, in 1969, some extra corrections were added to the list.@Wood1969a Finally, not everyone agreed with the move to IFIP. Especially Peter Naur felt that he was wronged by this move.

Although Peter Naur was not present at Rome, he had sent the participants the answers to question 40 of the questionaire in ALGOL Bulletin 14. This question was to ‘indicate the order of preference of your group of the following bodies as far as the official adoption of clarifications, subsets, and extensions of ALGOL 60 is concerned.’²¹ Most people (17) wanted to stay with the current situation of the USA Maintenance Group and the ALGOL Bulletin as their first choice. Furthermore, only ten people wanted IFIP to take over and eight people wanted an ad hoc committee. As second choice, IFIP was even less popular ( 3 votes ).²² Based on these results, Naur could not support the move of ALGOL maintenance to IFIP.

Despite Naur’s objection, the IFIP Technical Committee established nonetheless a working group to take over responsibility for the ALGOL effort.²³ The chairman of Working Group 2.1, van der Poel, offered Naur the job of secretary of Working Group 2.1. Naur would only accept it if the more influential members of the effort like Bauer and Samelson would support him. They did not and accused Naur instead of being biased in his presentation of questionaire 14.²⁴ Peter Naur interpreted this as that ‘it is clear that the responsible bodies of IFIP, in establishing the Working Group, deliberately have chosen to ignore the existence of the ALGOL Bulletin and the information and opinions expressed in it.’²⁵ Peter Naur decided to stop with his work on the ALGOL Bulletin which would not be published again until 1964.

Unfortunately, Peter Naur was the only one reporting on these events, it is uncertain if his view corresponded with the view of the other authors of the ALGOL report or with members of the ALGOL effort. For sure, the six authors at the Rome meeting did not vote against a move to IFIP. In addition, six of the twelve authors of the ALGOL 60 report became member of Working Group 2.1, including Peter Naur.²⁶ It seemed that half of the authors were not interested in further involvement with ALGOL.

This early phase of the work of Working Group 2.1 was not very interesting. Not only opponents of IFIP and the ALGOL effort governed by the IFIP like Peter Naur²⁷ and Wirth²⁸, but also van der Poel²⁹, the chairman of Working Group 2.1 agreed on this. The Working Group produced only a subset of ALGOL 60 and a report on input-output procedures. These documents were another consequence of the maintenance started after the publication of the ALGOL 60 report. Recall that one of the goals of the ALGOL effort was to create a universal algorithmic language. Although the ALGOL language was designed to be machine independent, implementations were, of course, machine dependent. The problem was that almost no translator was complete. Furthermore, given the ambiguities in the report, not all implemented features could be guaranteed to work in the same way on every implementation. And, again, the lack of input-output procedures, which were needed in practical situations, enforced implementors to add extensions to the language.

To improve this situation, three approaches were taken: defining subsets, defining input-output procedures and standardisation of ALGOL 60. Unfortunately, there were different subsets defined: SMALGOL 61³⁰, the ALCOR group subset³¹, the ECMA subset³², and the IFIP subset³³. Also different input-output procedures were defined: one by Knuth, also known as Knuthput³⁴, and one by IFIP³⁵. Finally, there were also different standardisation efforts going on: by ISO, by IFIP, by ECMA, and by the ASA. These standardisation efforts were another aspect of creating a stable language and to make the language more acceptable in industry.

3 Creating a successor to ALGOL 60: On ALGOL X and Y

During the first half of the 1960s, maintenance of ALGOL meant solving ambiguities, removing errors, creating subsets and standardisation. Besides these aspects, there was always the wish for certain extensions to and improvements of the language. In 1964, Working Group 2.1 started with a new project: developing a new ALGOL. For the short time, there was ALGOL X and for the long time ALGOL Y. In practice, this difference was not so clear. Simple extensions of ALGOL 60 were clearly for ALGOL X, but for the more ambitious and often disputable features, the predicate ‘being for ALGOL Y’ meant often that it was to be reconsidered sometime in the future again. Most discussions in Working Group 2.1 were on ALGOL X, but ALGOL Y was never forgotten.³⁶

At the symposium on Symbolic Languages in Data Processing, March 1962 in Rome, a discussion was held on the necessity of extensions to ALGOL 60.³⁷ Most of the panel members wanted some kind of extension to ALGOL 60. These wishes ranged from input-output (I/O) procedures, symbol manipulation, cleaning up of the for statement, double precision numbers, more types, to the ability to define new types. Most of these extensions were requested because of experience gained in the two years of using ALGOL 60, that is, they were needed in practical situations. However, with these extensions, the language would become more a general purpose programming language than a language intended for algorithmic work only.

Even before this symposium, the need for extra types was expressed by R.W. Hockney in the June 1961 edition of the ALGOL Bulletin. He proposed the extension of ALGOL with the complex type and a more general array concept.³⁸ With these additions, ALGOL would be better suited to describe algorithms involving complex numbers, matrices and bit patterns.

Another, more interesting proposal was made by Niklaus Wirth in 1963. He proposed to generalise ALGOL by removing type declarations and by replacing procedure declarations by so called ‘quoted expressions’.³⁹ New variables were declared with the new operator and the type of the variables would be deduced at run time. In cases the deduced type would result in meaningless operations, the value was to be assigned.

Quotations were expressions or a list of statements enclosed by the ’’’ symbol, hence the name quotation. Quotations could be assigned to variables even with parameters between parenthesises. Where a quotation variable was used the contents of the quotation were replaced. Normal calls of these procedure-like variables resulted in call-by-value calls of the parameters. However, when one of the parameters was a quotation, it became effectively a call-by-name call.

In May 1964, F.G. Duncan revived the ALGOL Bulletin. In this “first” issue the open ends from the last issue were closed and a new project started. In a meeting of the Working Group 2.1 in March 1964 in Tutzing, ‘there was a considerable body of opinion in favour of developing a so-called “ALGOL X” by building extensions on to ALGOL 60. This extended language would provide both a long overdue short-term solution to existing difficulties and a useful tool in the development of the radically reconstructed future ALGOL ( the so-called “ALGOL Y”).’⁴⁰

Till May 1965, when draft proposals for ALGOL X were requested, and October 1965, when these drafts were presented, various proposals were made and discussed in the . Some proposals were simple or similar to other proposals, some were more interesting.

One of the interesting proposals was the case expression. C.A.R. Hoare made this proposal as a replacement for the switch in October 1964.⁴¹ There was an earlier proposal to remove the switch concept by Duncan and van Wijngaarden. They introduced the type label to enable arrays of labels which the same function as the switch.⁴² Hoare’s proposal, however, was more flexible in the sense that no array of labels had to be initialised first, nor the problems attached to labels had to be taken in account.

An example of Hoare’s case expression is case n-2 of (1-y/z else 1 + y/z else 1). Here the case-clause decides which expression of the list following the case-clause is executed. If this case expression is 1, then the first expression is executed. If it has value 2, the second expression is executed, etc. If the value of the case-clause is 0, negative, or exceeds the number of expressions, the whole case expression was undefined. In the example, only for n = 2, 3, or 4, the case expression has a non-undefined value, namely one of the expressions in the list following the case-clause.

Another proposal in the October 1964 issue of the ALGOL Bulletin was made by Peter Naur.⁴³ He focused on the problem of ALGOL 60 being too rigidly machine independent. Because of that, features of particular machines could not be used in the language. Naur wanted to introduce a special element, the Environment Enquiry, to give the programmer information about the characteristics of the particular implementation and machine the program is running on.

Programs can become machine independent by using machine dependent characteristics which influences the working of the program. For example, if there is not enough memory space, the program can decide to stop running. Another examples are the maximum and minimum integer values. In addition, Naur (1964) proposed the possibility to create new operators, or redefine operators, the string type, the problem of labels and switches, non-rectangular arrays, and the difference between operators and standard functions.

In the of November 1965, Gerhard Seegmüller published some of his proposals for ALGOL X. He, too, wanted more types: complex, character or string, bit and label. The for statement was cleaned up, that is, omit the step if it is 1. He introduced a new repetitive statement, the all statement. A variable in the all-clause would get assigned to all the consecutive values specified in the all-list, that is, a list with numbers, or expressions generating numbers.

He introduced (1965) also the reference variable as a generalisation of the call-by-name concept. To that end he invented the ref operator. The reference type can be used in combination with other types into a reference array, a reference integer, or a reference integer procedure. Procedures were adapted in such a way that the call-by-name parameter calling was replaced with the call-by-reference parameter calling. A special case of the last call-type was the call-by-procedure to enable the Jensen device.

In January 1966, Niklaus Wirth and Helmut Weber published their Euler language in the Communications of the ACM⁴⁴. This language was already discussed at the Princeton meeting of Working Group 2.1 in May 1965.⁴⁵ The article on Euler is about the way how to define a programming language, about an algorithm for syntactical analysis of phrase structure languages, and about the programming language Euler itself. Although the method of definition described by Wirth and Weber is interesting, it played a minor role in the ALGOL effort: the defining method invented by van Wijngaarden was used to describe ALGOL X, and eventually ALGOL 68. The various programming languages defined later by Wirth all used the BNF as the defining method.

The language itself⁴⁶ builds upon Wirth’s earlier generalisation of ALGOL⁴⁷ (1963). The rigid type concept of ALGOL 60 was replaced by a more general type concept. Variables did not have a special type, and the types of ALGOL 60 were supplemented with types reference, label, symbol, list, procedure and undefined. Types were assigned to variables and to procedures in a dynamic way.

The most interesting type introduced in Euler was the list type. It had to replace arrays, but it was more flexible than arrays: all kind of values can be assigned to list elements, even lists itself, so tree-like structures were possible. To manipulate lists, special operators were introduced and elements in the list could be accessed by an index number, starting at one.

Procedures were similar to the ‘quotations’ described earlier. Procedure texts could be assigned to variables and besides the call-by-value and call-by-name, the call-by-reference was also available. Every expression resulted in a value. In case of an assignment, it was the value of the expression on the right hand side. In case of an output-expression it was the value of the expression being outputted. There were only two kinds of declarations: a new variable was declared with the new keyword and labels with the label keyword.

In the November issue of the ALGOL Bulletin in 1965, C.A.R. Hoare made a proposal for record handling.⁴⁸ The possibility to create and use records improved a programming language enormously, it could now be applied to many more problem(area)s. Where records were initially invented for data processing, i.e. in COBOL, it was now proposed as a general programming language construct.

Every record belongs to one and only one record class defined by the programmer. Such a record class denotes a certain object existing in the “real world”. Every object has some properties, denoted by fields. A field is like a variable, and has a name and a type and can contain a value. Fields were declared in the declaration of the record class.

Besides properties, records can also contain relationships. To denote relationships, the type reference is introduced. In a record class definition, a field may be a reference to a record belonging to a certain record class and denotes the relationship between two records in terms of record classes. Furthermore, records can be created dynamically, that is, at run time by statements in the program.

Record fields are accessible by “functions” with the same name, which, applied to a record belonging to the record class, return the value of the field. So, given a record class containing the fields A and B and a record of that class named R, the value of field A of R is A(R)and it can be set by A(R) := value. Fields which are references, return a record, and repetitive application of fields is possible. thus A(B(R)) denotes the A value of the B value, which is a reference to record R of the same class.

In addition, two operations were defined: the destruction operator and the record class identifier as the constructor operator. Besides that, the null value was added to denote a reference to no record at all. He gave the following example⁴⁹:

record class person;
    begin
         integer date of birth;
         Boolean male;
         reference father, mother, youngest offspring, elder sibling(person)
    end;

reference Jack, Jill(person)

begin
    reference John(person);

    John := person; comment creates the record John
    date of birth(John) := today
    male(John) := true
    father(John) := Jack;
    mother(John) := Jill
    youngest offspring(John) := null
    elder sibbling(John) := youngest offspring(Jack);
    youngest offspring(Jack) := John
end

Hoare (1965) also gave some possible extensions to his record concept. The idea of procedure fields is interesting in the light of the concept of an object in object oriented programming. Another extension was the set concept. Instead of encoding a set with integers and write the program using these integers, Hoare proposed to give a set a name and list all the items. Thus would define the set suit with four items. Extra operators, like , should be added too.

In October 1965, Peter Naur proposed to change the way procedures were specified. Instead of procedure P(a, b, c); value b; integer a, b; real c; he wanted to write procedure P(integer a, integer value b, real c);.⁵⁰ The advantages were a better readability and less repetition of keywords.

The main line in these proposals is clear: ALGOL X would introduce some new types, type flexibility, records, a better iterative statement, no labels nor denotational expressions, a case expression, I/O, string handling, and for the rest it would be an improved version of ALGOL 60. Instead of a special-purpose programming language, the new language would be a general programming language suitable for a wide range of computational problems. The need for an algorithmic language in the late 1950s had evolved in the need of a general purpose programming language in the 1960s. Numerical applications were clearly not the only relevant applications any more.

4 The end of the ALGOL effort: the creation of ALGOL 68

4.1 Orthogonality versus pragmatism

In the previous section, the proposed extensions and changes to ALGOL 60 were discussed. These proposals where the basis for the development of ALGOL X. At the meeting of Working Group 2.1 at Princeton, May 1965, only one more or less complete proposal was available.⁵¹ The members of the group were then invited to create their own proposal for ALGOL X.⁵² In October 1965, the next meeting of the Working Group was held at Saint Pierre de Chartreuse and three proposals were presented.⁵³ Wirth’s (1966) Euler was combined with Hoare’s (1966) proposal for records and was the most feature complete proposal. Seegmüller’s proposal was, basically, an extension to Wirth’s (1963) earlier proposal and was not seen as a serious candidate.⁵⁴

The last proposal was Orthogonal design and description of a formal language⁵⁵ by van Wijngaarden. It was not really a proposal for a language, but a proposal for a better method to define programming languages. In this report, three new ideas were expressed.⁵⁶ First of all, a two-level grammar was used instead of the BNF. This grammar would later be known as vW-grammar or W-grammar. Second, van Wijngaarden proposed orthogonality, or in his own words: ‘As to the design of a language I should like to see the definition of a language as a Cartesian product of its concepts.’⁵⁷ Finally, the language defined was an expression-oriented language: there was no distinction between expressions and statements.

The result of this meeting was that a subcommittee was founded consisting of the four authors of proposals for ALGOL X. Together they would decide upon one final proposal for ALGOL X. However, it was also decided that the resulting language would be described in the notation invented by van Wijngaarden.⁵⁸ The subcommittee decided further that van Wijngaarden would write the proposal and would send it to the others for discussion.⁵⁹ In addition, another subcommittee was created to discuss I/O.⁶⁰

In April 1966, the subcommittee working on the new proposal held a meeting at Kootwijk where two proposals were presented. The proposal of van Wijngaarden was written using the accepted notation, but was not complete. The other proposal was written by Wirth and Hoare and would later be published in the Communications of the ACM as A Contribution to the Development of ALGOL⁶¹. Their proposal, although not written in the right notation, was felt to describe the right language.⁶² Unfortunately, Hoare and Wirth on the one hand, and Seegmüller and van Wijngaarden on the other hand could not decide upon one language acceptable by all. The orthogonality pushed by van Wijngaarden conflicted with the more pragmatic approach taken by Wirth and Hoare.⁶³ They wanted to create a language which could become ALGOL 66 and they felt that the language proposed by van Wijngaarden was too ambitious.⁶⁴

4.2 A contribution to the development of ALGOL

Wirth and Hoare decided to publish their proposal in the Communication of the ACM as A Contribution to the Development of ALGOL. The goals stated at the start of the article were: to give a presentation of where the ALGOL effort was heading for a broader public; be a document which could be used for experimental implementations; and describe problems for further extention.⁶⁵ The language was designed with four criteria in mind: it should be usable for programming computers; it should be usable usable as a communication language; it should be usable for teaching and research; and it should be as practical usable as possible.⁶⁶

The language described contained, with respect to ALGOL 60, new data types: complex, a long variant for both real and complex, sequences in the form of a sequence of bits (called bits) and a sequence of characters (called string). For these new types, appropriate operators and functions were defined too, like the concatenate operator for strings, the logical operators for bits, and type conversions. In addition, the language was strong typed: types of expressions were known at compile time.

Switches were replaced by the case expression. Labels became just labels, that is, place markers for use with the go to statement. All other forms of designational expressions were removed. The iterative statements were simplified and contained only the while and the for-step-until variants. Parameters to procedures are either value-parameters, or result-parameters. Arrays were slightly simplified. the record type was added including references to records as proposed by Hoare.

After this short introduction into the main features of the language, the authors gave some extensions: extra string operations, more flexible types, initial values and constants, array constructors (initial values for arrays), and more flexible handling of records, for example, the union denoting that a record reference variable may refer to records of all record classes in the union, or an is operator deciding if a record is of a certain record class.

Then the formal definition of the language defined using the BNF followed. In part three, the ‘proposed set of standard procedures’ or standard library was discussed. This library contained I/O, environment enquiries like in Naur’s (1964) proposal (making the programmer able to ask questions on the implementation and decide on certain features in the program, like the biggest integer), mathematical functions, like sin, pi, ln, exp, etc.

This document was the basis for the further development of languages by Wirth. In September 1966, Wirth reported in the ALGOL Bulletin that he was implementing the language on an IBM 360 at Stanford University.⁶⁷ While implementing he came across some problems and altered the language accordingly. Some syntactic sugar for arrays was introduced, like x[i, j] instead of x[i][j]. Strings became static, that is, they could not grow, and were declared being of a certain length. In the for statement, the step element may be omitted when one. Concurrency was added with the also keyword: S also T means that S and T are executed concurrently. Synchronisation of parallel processes was available via P and V operations invented by Dijkstra, Wirth (1966) called them on and off respectively.

4.3 The end and the ALGOL 68 report

Although the subcommittee could not agree upon one proposal, van Wijngaarden did create a new draft for the next meeting of Working Group 2.1 in Warshaw. Actually, the meeting was moved to October 1966 because Van Wijngaarden was unable to produce the draft in time.⁶⁸ At the meeting, the main question was if this draft could be accepted because it was written by only one member of the subcommittee. Wirth did not attend the meeting and resigned later form Working Group 2.1 alltogether. Hoare wanted to consider accepting the draft only if it was completed first; the results of the I/O subcommittee was not yet added to the draft of van Wijngaarden.@Lindsey1993a [10] Besides these more formal discussions, some technical matters were also treated. Some people wanted to restrict references to records only, the diagonal approach, which conflicted with the orthogonal approach taken. In this orthogonal approach references should be applicable to all objects, not only records. McCarthy proposed operator overloading and Samelson anonymous subroutines.⁶⁹

At the end of the meeting there was still no complete draft. It was decided that van Wijngaarden would edit alone the draft which would be complete at the next meeting in May. Van Wijngaarden thought that ‘the delay in producing the final version may not be very long’⁷⁰, however, it would be February 1968 before the draft, known as MR 93⁷¹, was ready. It ‘was the cause of much shock, horror and dissent, even (perhaps especially) amongst the membership of WG2.1. It was said that the new notation for the grammar and the excessive size of the document made it unreadable.’⁷²

Opposition agains the notation and the draft became louder, dropping the draft or adding a minority report became realistic options.⁷³ At the meeting in Münich, December 1968, the ultimate decision had to be made: drop it or accept it as ALGOL 68. Report on the Algorithmic Language ALGOL 68⁷⁴ was accepted and a minority report was published too, signed by almost half of all the members of Working Group 2.1.⁷⁵ stating that:

We regard the current Report on Algorithmic Language 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 its authors, “every word and every symbol matters” and by the extreme difficulty of achieving correctness.

(…)

We fail to see how the language proposed here is an 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 spirit with which the ALGOL effort started in the 1950s was broken. The ALGOL effort ended with a failure for some. Others, however valued the new language, especially after the publication of the revision in September 1973. The language was not used much in industry, although it was used in the academic world, but less than ALGOL 60 was. It is often regarded, however, that it influenced many languages which were developed later. The question is if the language itself was influential, or that the development of the language was influential.

In my definition, the ALGOL effort ends here with the publication of the ALGOL 68 report and the Minority Report. This does not mean that there were no further developments in Working Group 2.1 and the ALGOL Bulletin: as was the case with ALGOL 60, ALGOL 68 also had its maintenance period and the last ALGOL Bulletin was issued in 1988.

5 Conclusion

The question that should be asked is what was the importance of this period of maintenance and succession? Was it important, and if so, why? First of all, the maintenance of ALGOL 60 was necessary for ALGOL itself. It was necessary to become accepted in industry, although it did not work out very well.

Although ALGOL 60 was the most used programming language for man-to-man communication, it failed to truly become the universal algebraic programming language for man-to-machine communication due to the computational context of that time: the predominance of IBM pushing FORTRAN, the legacy of applications already created and used in the industry. ALGOL was a new untested language and, especially on the American market and outside universities, it could not win the fight with FORTRAN.

Second, the move to IFIP seemed a wise move for the ALGOL effort: the lack of a governing body was now solved. It was, however, too late to obtain a fundamental part of the market. As part of IFIP, Working Group 2.1 created some reports on subsets, I/O, and standardisation. These results were not very interesting and definitely not important for the field of programming languages or computer science.

The move to create a successor to ALGOL 60 in 1964, was much more important. The ALGOL effort became a platform where the best computer scientists of that day discussed programming languages. Many proposals were made and discussed, most of them boiling down to extra types, string handling, cleaning up the for statement, and other minor improvements. Major improvements were made by Hoare: the case expression which allowed the removal of designational expressions and part of the label concept. More important was his paper on record handling (1966).

With records came references and with references the call-by-name concept could be replaced with call-by-reference. Although records were not new, Hoare made them a general programming language concept. There were other proposals, on overloading and the ability to (re)define operators. Furthermore, the standard library became larger, containing not only mathematical functions, but also I/O, string handling, and casts.

There was clearly a move from a special-purpose language towards a general programming language. Unfortunately, Working Group 2.1 was not able to define the new language with agreement of all its members. The new language had to be defined in the notatation invented by van Wijngaarden, which turned out to result in a unreadable report. After much delay, the draft was presented and accepted by the Working Group, however, not without a Minority Report of almost half of the Working Group. In this report it was stated that they considered the new language a failure.

References