Мы попали в FAQ. Вот письмо Робина:
I had a chance to peruse the web site again, and have included a link in the FAQ.
Here are some comments.
IBM’s PL/I-F compiler had two levels of optimisation.
The statement “Asynchronous modification of variables …
made optimisation extremely difficult.” is incorrect.
Signficant optimisation was possible even if ON statements
were included in the program. Of course, if no ON statements were included,
a high degree of optimisation was possible.
In general, ON statements were intended to trap such errors as fixed-point
overflow, floating-point overflow, subscript errors, etc, and by using the SNAP
option in the ON statement, the statement number in which the error occurred
was printed. The user could then continue execution from the next machine
instruction as if nothing had happened. This was entirely independent of any
optimisation. If the user also printed values of variables in the ON-unit
then, depending on the level of optimisation, the latest value(s) might not
This facility was extremely helpful, and compared to IBM’s FORTRAN
compilers, was far superior. (FORTRAN programs produced an
“indicative dump” and didn’t tell you where the error occurred.
Thus, in FORTRAN, more runs of the program were usually necessary
to determine where the error occurred, and why.)
Thus, the statement “Therefore, PL/1 could not replace Fortran” is
The Multics project was quite late in using a high-level language
to develop an OS. Burroughs used Algol for their systems (B5000
systems and later) from around 1960. On those systems,
there was no assembler ever written.
Nor was PL/I the first compiler to be developed in a compiled langage (1969).
Again, Burroughs used ALGOL from about 1960 for its various language