9

In Charles Lindsey's “A browse through some early bulletins”, he mentions (regarding Knuth's Man Or Boy test):

As a postcript to this whole episode, it may be noted that a couple of years later Bekic was able to use this example to persuade the designers of PL/I (who really did not understand environments) to mend their ways.

This article is fairly informal and has no bibliography, so there's no citation for the statement.

One relevant document I can view is an article about the development of PL/I, ”The early history and characteristics of PL/I” by George Radin, which states

"BEGIN...END" blocks were introduced, supported by the members of the IBM laboratory in Vienna, Austria. They argued, in a paper called "Block Concept for NPL," (9) for the elimination of ALLOCATE and the inclusion of Blocks. Paul Rogoway (who had now joined IBM) and I objected because we wanted the function of dynamic storage allocation at other than block entry. We prevailed and both functions were included.

That paper has Bekič listed as an author (along with two others), but is not accessible online. Note that according to the citation it was published in 1964, which contradicts “a couple of years later”. Furthermore, I believe Knuth's example would be sufficiently well known to people working on a theoretically universal language after a few years (but maybe not immediately after publication in 1964).

I can see the connection between these statements, but something seems to be missing. Lindsey's anecdote hints at a more interesting story than “some guys wrote a paper and the PL/I designers decided to add blocks”. Also, it isn't clear that the PL/I designers didn't understand environments, as opposed to simply not caring for block structure, especially given that the original design stuck around even after they were persuaded (allegedly).

Is there more to the story, ideally supported by primary sources?

4
  • 2
    Not an answer, but my guess is that the remark is due to distaste at CONTROLLED storage, which in conjunction with ALLOCATE gives you 'manual stack control' cutting across the lexical structure of the code.
    – dave
    Commented Jun 9 at 12:36
  • @dave Yeah, maybe I'm reading too far into it. Perhaps Lindsey was saying that the designers were going in the wrong direction (manual allocation), rather than that they literally didn't grasp block structure and its ramifications. In fact, Radin's paper discusses problems related to scope and extent (w.r.t. labels) in a way that suggests that the committee was very familiar with the interaction between static scoping and dynamic execution. (E.g. they knew label variables needed extra information to reset the environment correctly.)
    – texdr.aft
    Commented Jun 9 at 21:01
  • 3
    Lindsey's "Browse" is rather awesome in the amount of dirt dished in such a casual and friendly way!
    – davidbak
    Commented Jun 10 at 0:04
  • 1
    From reading the article by Lindsey, there is something to be said for his position. Algol had been through language revisions and the team had seen that there were a number of unanticipated interactions they had to deal with as they tried to understand Algol 60 and move to Algol 68. Language designers who had not been through the ringer would not understand what happened as deeply as those who bore the scars. The 'environment' of the language developers was thus different between Algol and PL/I.
    – Jon Custer
    Commented Jun 10 at 16:55

2 Answers 2

9

Up until PL/I, IBM mostly use FORTRAN for scientific computing, and COBOL for business computing. The basic idea was that PL/I would combine the two.

But neither FORTRAN nor COBOL supported recursion at the time.

Furthermore, IBM computers of the time (this was nearly concurrent with the introduction of the IBM 360 series) didn't support stacks.

So, at the time, nearly everybody at IBM was accustomed to the idea that all a program's variables were allocated statically, when programmers did what we'd now call linking.

Even today, when compiling something like C for an IBM mainframe, the call stack it uses isn't much like the stack you'd expect on most other machines. Rather, it's created as a linked list of dynamically allocated blocks. At one time, each stack frame was a node in the linked list. More recently, they've improved memory usage by allocating a few big blocks instead, so they can typically create several stack frames in each. But it's still a linked list, not what you'd normally think of as a stack.

Although he didn't go into detail, Dijkstra repeatedly mentioned IBM's failure to understand the nature of computation and computing, and I suspect their inability to grasp recursion was a large part of that.

1

I think much of it was that FORTRAN IV didn't offer programmers much ability to structure code syntactically, and the PL/I concept started as an improved FORTRAN. FORTRAN programmers were used to managing without much syntactic structure. FORTRAN IV code was full of GOTOs.

2
  • 1
    This is true, but I don't see how it's specifically relevant to environments. Lindsey is talking about a mostly semantic matter, not a syntactic one. Also, PL/I code was full of GOTOs as well. Radin's paper discusses how they added label variables to the language.
    – texdr.aft
    Commented Jun 9 at 20:07
  • 1
    @texdr.aft FORTRAN programmers didn't have the environment concept in their toolkit, so they didn't see the advantage. But they had various forms of GOTO.
    – John Doty
    Commented Jun 9 at 22:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .