Re: language design after Algol 60

On 14/04/18 05:11, Robin Vowels wrote:
>> The IBM Language Reference for Enterprise PL/I for z/OS is 862 pages.
>
> The IBM PL/I for OS/2 Language Reference is 491 pages plus 121 pages
> for the built-in functions, published 1994.
> This reference includes a number of new language features.


So in order to master PL/I one would need to read *both* manuals, and
probably a few other similar sized manuals for any other versions or
variants of PL/I that may be in existence.


As we will see below, different versions of PL/I give different
meanings even for a very simple statement such as "C = A+B". Someone
who has mastered PL/I would need to have *all* of these different
meanings at their fingertips.


> Dijkstra's comment is nonsense because it is possible to master the
> language. His analogy with flying a plane is entirely erroneous.
...
>> What does C contain? Answer: three spaces. -John]
>
> No. IBM's PL/I for Windows compiler produces two diagnostics:
>
> 1: at compilation time, at line 6 [your line 4]:
>
> (6:1) : IBM1211I W Source in string assignment is longer than the target C.
>
> 2. At execution time, a fatal error at the assignment C = A+B :
>
> IBM0441I ONCODE=0150 The STRINGSIZE condition was raised.
> At offset +0000016B in procedure with entry L


Clearly *you* have not mastered PL/I: since you had to construct and
execute a sample program in order to find out the meaning of the very
simple statement "C = A+B" on a particular version of PL/I, and you do
not know the meaning of the statement for other versions of PL/I that
you do not have access to:


> I'm not sure whether a compiler warning message would have been
> produced in the 1960s with the PL/I F-compiler,
> but am fairly certain that there would have been no run-time error.


You are "fairly certain" that PL/I F gives a compiler warning, but
John knows that it does not. It would appear from this discussion that
Dijkstra's evaluation of PL/I has been fully justified: "I absolutely
fail to see how we can keep our growing programs firmly within our
intellectual grip when by its sheer baroqueness the programming
language -- our basic tool, mind you! -- already escapes our
intellectual control."


When you have to type in and execute a program to find out what "C =
A+B" does, then you can safely say that the programming language has
indeed escaped your intellectual control.


Later in the same paragraph he described PL/I as having the "growth
characteristics of a dangerous tumor": the growth of the manual from
612 pages in 1994 to 892 pages in 2013 also bears out this statement
as prophetic.


https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html


--
Martin


Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
[Every language's manual grows over the years so I don't think that is a fair
comparison. PL/I was a large language for its time but if you compare it
to, say, C++ or even python with its standard libraries it's not all that
large. It does have the problem of having been invented in a hurry, so
that there are persistent rough edges where the parts from Fortran and
the parts from Cobol meet. This will end the skirmishing unless someone
has something about, you know, building PL/I compilers. -John]

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