Re: PL/I nostalgia

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Monday, 23 April 2012 11:45


>It has always seemed to me that PL/I would have been more successful
>if the early compilers generated faster code (and ran faster, too).
>
>It might have been that too much of the above was adopted, along with
>other COBOL features, by PL/I. There are many things that other
>languages, such as Fortran, traditionally didn't let you do, because
>they might run too slow, but that PL/I allowed.


FORTRAN was developed by 1956.
PL/I was developed by 1966.
In the decade after 1956, many deficiencies had been identified in FORTRAN;
some of its statements were pretty crude.
Similar comments may be made about COBOL.
While some features of both FORTRAN and COBOL were adopted in PL/I,
many new features were added, including (but not limited to) recursive procedures
and dynamic allocation (already in Algol).
Of those features adapted from the older languages, arbitrary restrictions
were removed, making it much easier to write programs.
One other point is that the size of machines had increased significantly
in that early decade, permitting more language features to be incorporated
in PL/I.
PL/I can be considered to be the first general-purpose language.


As to code generation of the early PL/I compilers, that code was reasonably efficient.
I would agree, however, there were certain situations where much faster code
could have been generated, but that opportunity was not taken.
I refer to operations involving whole arrays or array sections.
For instance, where an operation involved a whole array,
IBM's first compiler, PL/I-F, could have optimised a matrix statement
(trivial example, A=B; where all elements of A and B are accessed)
to a single loop, instead of the two equivalent loops that were actually used:
do i = 1 to m;
        do j = 1 to n;
            A(i,j) = B(i,j);
      end;
end;
Four years later, IBM produced their Optimising Compiler and Checkout Compiler
(c. 1970).


>(Many of those have now been added to Fortran.)


Some have, but others have not.
For example, recent discussion in comp.lang.fortran evolved around a suitable
Fortran procedure to convert an integer to a string.
In PL/I, it requires a simple statement, s = i;
Some of the code examples offered for Fortran were as long as about 50 statements;
other shorter ones that used internal I/O failed to work when incorporated in a function procedure,
because that facility requires recursive I/O -- something that is not permitted.


Another of the same category is the Fortran list of string constants.
In Fortran, all such constants must have the same length,
as the array with which such a list is associated is not varying --
all array elements must have the same length.
[Considering what a rush job PL/I was, it's a remarkably good language. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.