Throughout this document various examples of statements and declarations appear without the semicolon which is always required for separating them. This is to avoid the implication that the semicolon is part of the statement or the declaration. In sentences, a comma or period may appear where a semicolon or other delimiter would be indicated in the context of a program.
Word delimiters rendered in bold-face type in the Algol report are herein indicated by underlining.
II. Language Restrictions
The compiler correctly handles programs written in Algol 60 subject to the following restrictions.
1. The use of an integer label as an actual parameter will cause an incorrect program to be compiled.
2. A GO TO statement with an undefined switch designator as the designational expression will cause incorrect operation of the final program.
3. Type restrictions:
(a) The exponentiation expression x ↑ y will have type real unless x is of type integer and y is a non-negative integer constant. This differs slightly from the definition in the Algol report but will generally cause no difficulty.
(b) In the construction
<if clause> <simple arithmetic expression>
else <arithmetic expression>
the arithmetic expressions must have the same type, or else an incorrect program will be compiled. For example, in the statement
x := if a < b then z else w
z and w should both be declared real or both integer.
(c) In a procedure call (procedure statement or function call) each actual parameter having an arithmetic value must have the same type as the corresponding formal parameter in the procedure declaration. The type of the formal parameter is that designated in the specification part if it appears there. If a formal parameter representing an arithmetic quantity does not appear in the specification part, it is assumed to be specified real. Full use of specifications is desirable for descriptive purposes and for optimization.
Caution. Restriction (c) is more likely to cause errors than the other restrictions. It is very easy to write P(1,2) when the parameters of P are specified real, but incorrect coding will result. The call P(1.0,2.0) works correctly.
4. Standard procedure names (see [section VI]) used as parameters in procedure calls will cause an incorrect program to be compiled. A call, therefore, such as
P(sin)
is incorrect. Note, however, that a call of the type
Q(sin(x))
causes no trouble. The case P(sin) can be programmed in another way. Make the declaration
real procedure sin 1 (t); real t;
sin 1 := sin(t).
The call
P(sin 1)
is then correct.
5. Arrays called by value are not handled. If an array identifier appears in the value part, an incorrect program will be compiled.
6. “Dynamic” own arrays are not handled. This means that all own arrays are treated as having constant subscript bounds; this constitutes one possible interpretation of the Algol 60 report. An own array may be declared with variable subscript bounds, but only one allocation of storage will be made, and if the bounds change, this will be ignored.
7. Recursive procedures are not handled. This restriction encompasses all cases of a function designator appearing in the actual parameter part of a call of the same function, unless that function is a standard function. Thus f(f(x)) is not permitted in general, but sin(sin(x)) is allowed.
III. Modes of Operation of the Compiler
There are two distinct modes of operation: ALGO and ALDAP.