Algol 58: an interim design. Followed by lots of discussions in the Algol Bulletin
Algol 60: result of an intensive 6 day design effort by a committee in Paris. A few revisions made; Algol 60 report published in CACM in Jan 1963.
The meetings were exhausting, interminable, and exhilarating. ... Progress was steady and the output, ALGOL 60, was more racehorse than camel. This language proved to be an object of stunning beauty. It was sufficiently perfect and complete so that ensuing implementations were able to append necessities, such as input-output, in the style of ALGOL 60 but their addition propagated no significant changes in the body of the original language.
The ALGOL 60 report (Nauer et al., 1960) was a fitting display for the language. Nicely organized, tantalizingly incomplete, slightly ambiguous, difficult to read, consistent in format, and brief, it was a perfect canvas for a language that possessed those same properties. Like the Bible, it was meant not merely to be read, but to be interpreted.
-- Alan Perlis, "The American Side of the Development of Algol," The History of Programming Languages
One of the debates: should recursion be allowed?
dynamic array bounds; lower and upper bounds; indefinite number of dimensions
Blocks define nested scopes:
foo, the name
xrefers to a different variable than in the global scope (see Implementation of Block Structured Languages)
Algol 60 (and Modula-2, Ada, etc) use lexical scoping.
Early Lisps, APL, etc. use dynamic scoping.
Unlike Fortran, binding of variable names to locations done at block entry time (in general, it can't be done statically)
Blocks for efficient storage management
xis allocated in the first block, then deallocated, and then the array
Compare with Fortran equivalence statement. The Algol solution is safe, clear, and provides no opportunity for clever abuse of the type system.
The bounds of array must be known at block entry time for example, in the declaration:
Except for procedures as parameters, Algol can be statically type checked. The report doesn't say, but a reasonable implementation will be strongly typed.
if-then-else: both statement and expression forms
switch statement -- supports a kind of computed goto; now obsolete (case statement is better)
parameter passing mechanisms: Algol 60 had call by name, call by value
(see Parameter Passing)
indentation style; semicolon to separate statements
Using the semicolon as a separator is much more error prone than using the semicolon as a statement terminator. (Ada takes the latter approach.) For example, the following Algol code is syntactically incorrect:
y:=5actually puts a null statement after the assignment, so that there are two statements after the "then", resulting in an error.)
3 levels of representation:
hardware representations could vary from implementation to implementation
(cf comma - decimal point controversy)
Approaches to the problem of words such as INTEGER or WHILE:
Examples: number of characters in an identifier, number of dimensions in an array, number of arguments to a function
Algol obeys this principle much better than does Fortran
dangling else problem
forloop evaluated once before executing the loop, or at the beginning of each loop execution? A literal reading of the Report implies that they are evaluated each time; but this is inefficient and unclear.
As an example of the problems that can arise from such ambiguity, in the DEC System 20 implementation of SIMULA we used to have, in this loop the upper bound was evaluated once:
Some other problems: OWN variables, SWITCH, side effects in functions
BNF developed to describe the syntax of Algol-60
labels, procedures, and strings are not first-class citizens in Algol 60
no I/O statements
In the USA, Burroughs supported Algol-60, but IBM supported FORTRAN
Algol-60 is extremely important language in the history of programming languages
Many successors: Pascal, Modula-2, Ada, Euclid, Mesa, Emerald, ...
Lots of good work done on lexical analysis, parsing, compilation techniques. for block-structured languages, etc; this is still relevant.
PL/I -- Swiss army knife language
kinds of extension: