Features of PL/I not realized in a modern language
minnie.tuhs.org
minnie.tuhs.org
Because PL/I was designed by IBM for their computers and operating systems, there were no concerns for portability, so the language definition included a large amount of features that are left unspecified in standards for languages like C/C++, because they are available only for certain operating systems or computers, so the standard must be restricted to specify only the minimum features that are available everywhere.
For example the C++ threads are limited only to the features provided by the POSIX pthreads, even if most operating systems have additional features for multi-threading. PL/I on the other hand, already in 1965 had more powerful features than the C++ threads.
One feature of PL/I that is completely absent in all modern languages is what I consider to be the right way for error handling.
Instead of being forced to test the return value of a function to determine what error might have happened, which is a redundant operation, as this was already tested once in the invoked function, and which clutters the code, obscuring the processing of the normal path, the PL/I method was to group the error handlers at the end and pass the labels of the error handlers to the invoked function as alternative return labels.
While this looks visually very similar to a try block with exception handlers, the hardware implementation in PL/I is far more efficient than in modern languages, because there are no conditional branches and no extra code to determine where is the appropriate error handler, just the return, which is done anyway when the invoked function finishes, jumps to different addresses in case of errors, instead of returning to the point of invocation.
PL/I also had exceptions, but those were used for really exceptional conditions, like numeric overflow, illegal memory accesses etc., not for correctable error conditions, like a mistyped user input or a file that cannot be found, which are best handled at the point where a function has been invoked, because only there you have complete information about the intention of the failed operation.
What facilities are you thinking of?
> PL/I on the other hand, already in 1965 had more powerful features than the C++ threads.
Given that the term "threads" originates in the 65/66/67 era, this is an interesting claim.
Nobody used the terms "thread" or "multi-threading" when PL/I was designed. Everybody used the terms "task" and "multi-tasking", with the same meaning.
So in PL/I you have "tasks" for what are now called "threads".
The most annoying feature of the C++ thread support library, which is inherited from the POSIX pthreads specification, is the pathetic operation join which waits for the termination of a designated thread.
This is almost never what you want. The most frequent case is to wait for the termination of anyone of a group of threads, which cannot be done with join.
Already in 1965, PL/I had a wait that could do anything that can be done with WaitForMultipleEvents/WaitForSingleEvent, i.e. it could wait for any or all of any combinations of a set of events, e.g. thread terminations.
This is such a basic feature that I cannot understand how it could have been omitted from the POSIX pthreads and in consequence also from the C++ thread support library. The other features of pthreads/C++ that can be used to implement such a functionality, e.g. condition variables, also suck badly in comparison with a good wait for events.
The Linux kernel retains the term "task" for "execution context", and the term "thread" is used exclusively in user space purely because of programmer conventions (pthreads, specifically). This makes a limited amount of of sense because "thread" has also come to mean things that are very definitely not full execution tasks (user-space and/or so-called "green" threads). This overloading of the terminology in user-space is not reflected in kernels, but allows for developers to play with alternate implementations without changing their fundamental terminology. After all, there some things where user-space threads are precisely what you want (and these absolutely do not correspond to kernel tasks).
> This is almost never what you want.
I would beg to differ. I've been writing multithreaded code in C++ for nearly 30 years, and I don't remember any time that I wanted to join on a group of threads. My current project (20 years old) is heavily multithreaded (typically 20-60 threads) and there is nowhere that a thread primitive to join on a group of threads would make our lives easier. The only context where I could even think of using it might be to wait on a thread pool, but in general this tends to be unnecessary and if it is, can be trivially handled without a multi-join.
> Already in 1965, PL/I had a wait that could do anything that can be done with WaitForMultipleEvents/WaitForSingleEvent,
WaitForMultipleEvents/WaitForSingleEvent are not part of the C or C++ language, but Windows system calls. While their semantics are very powerful and useful (which obviously would thus apply to PL/1's wait), their absence cannot be laid at the feet of C or C++: no Unix-like OS has had this operation, ever (it is almost possible with contemporary Linux).
You could make the argument that it's not part of pthreads because this operation was never a part of posix, and so pthreads could not build on it (you can use those calls on Windows even in a single-threaded task, and that would be true in a POSIX system if the call existed). So it really has almost nothing to do with pthreads at all, other than that one could imagine a pthread wanting to block on "wait-for-something-anything".
This has historical roots from the first UNIX versions written for DEC computers. Even if the UNIX authors usually preferred the term "process", in the DEC documentation for their computers and operating systems the term "task" was always used for "process". So the term was also used in UNIX in various places.
> I don't remember any time that I wanted to join on a group of threads
This is not surprising, because there are many kinds of multi-threaded applications and many styles of programming them.
I do not doubt that what you say is correct for you applications, but my experience happened to be opposite. I have never encountered a case when I wanted to join a single thread, but I have encountered a lot of cases when I wanted to join any of a group of threads (e.g. for keeping a number of active threads matching the number of available cores) and also a less number of cases when I wanted to join all of a group of threads, typically at the end of an operation. The latter case is less important, because it can be done by repeating a join with a single thread, even if that is much less efficient than a wait that waits for all.
> are not part of the C or C++ language, but Windows system calls
This is precisely what I have already said in my first post, i.e. that standardized languages like C/C++ are forced to specify only the minimal features that are available on all operating systems, so they cannot include WaitForMultipleEvents, while PL/I was free of such portability concerns, so it could specify more powerful features.
I think you missed my point. WaitForMultipleEvents is not part of a thread API on any platform. It's a part of the platform API, and is used by single-threaded and multi-threaded code. There's no reason for pthreads (or any other thread API) to represent this system call, because the system call either exists, and can be used directly, or does not exist, and cannot be used.
In essence, you're really just noting that POSIX (not pthreads) never had a wait-for-just-about-anything API. That's a legitimate complaint, just not very relevant for multithreaded programming.
> This is not surprising
Well, given that you said "This is almost never what you want.", I'd count it as least a little surprising. My point was that multi-join is not "almost never what you want", but has always been "useful in certain contexts". I have never come across a multi-join API that blocks until all threads have completed (they typically return when any of the specified threads completes), and so the difference in efficiency for this version of multi-join is essentially identical to a loop+single-join.
>This has historical roots from the first UNIX versions written for DEC computers.
I don't see much evidence for this claim. task_t exists in early versions of AIX and Mach, and the terminology was already common in Multics (as you know). I don't think that Linux' use of task_t has any relationship to the Ultrix use, but maybe you have some specific insight here?
The OS I learned on was called CTOS, which used the term "process" to refer to "the basic unit of code that competes in the scheduler for access to the CPU". A "task" was essentially what we'd now call a program, complete with libraries and sub-processes. We didn't use the term "thread". I think CTOS dates to about 1981.
Hm. For me "heavily multithreaded" is 1000 threads and more. That said, I just detach them, there's no real reason to wait for a thread.
my stuff isn't client/server computing, my threads are generally compute bound, and having (lots) more than there are cores would be counter-productive.
Yeah, so basically this. Except that "I/O bound" usually implies critical moments of computation too, and pre-emption is really nice here.
I also have to say that this doesn't match my experience at all. Typically, my threads run for the whole duration of the program/object and I only need to join them when the program/object is done. In fact, this pattern is so common that C++20 added std::jthread which automatically joins the thread in the destructor.
I literally never had to wait for "the termination of anyone of a group of threads". For you it's apparently the most frequent case. This only teaches us not to make too broad assumptions. The world of programming is large.
When you have enough work for a very large number of threads, there are 2 main styles to do it.
Both styles avoid creating an excessive number of active threads in comparison with the number of available cores, because that can reduce the performance a lot.
One style is to have a permanent pool of working threads and to use some means of communication between threads to know when any thread has finished its current job, to give a new piece of work to that thread. This is also done in the simplest way with some kind of waiting for any of multiple events in the dispatching thread, where the event is that some thread has signaled the end of its job.
This style is appropriate for environments where thread creation and destruction is expensive, like Windows.
When the thread creation and destruction is cheap and also the indvidual pieces of work are relatively large, requiring an execution time much greater than the thread creation/deletion time, a second style of programming is much simpler.
You just create one thread for each piece of work, until you reach the limit for the maximum number of active threads. Then you wait until any thread terminates and then you create a new thread for the next piece of work. When there is no more work, you wait until all threads terminate.
In conclusion, any kind of work where you could launch an arbitrarily high number of parallel threads needs to wait for any of a group of events.
For all problems with limited parallelism, where you can create only few threads, you do not need this feature, but my work was always about problems where I could launch much more threads than the available hardware cores, where some kind of wait for multiple events is mandatory.
The idea of an alternative return address - that is, allow the calling convention to pass more than on return instruction pointer - seems both simple to implement and really useful. I guess in the modern gotoless world the trouble is structuring the syntax around the call.
Then you just passed them during function call, e.g. "handle = open_file(input_file_name, open_flags, FailedToOpenInputFile);"
The error handlers at the end of the body of the invoking function were just labelled appropriately.
Writing a label like FailedToOpenInputFile: before an error handler is certainly much simpler and more obvious than strange workarounds for exception identification, like inventing a dedicated data type for each possible error, as in C++.
This could be an easy syntax extension, but then the only advantage remains the more efficient hardware implementation of the error handling.
In that case you no longer have the separation in program text between the normal execution path and the error handlers, which removes visual clutter.
If called function is responsible to clear stack, like in Pascal or Forth, then yep, multiple return points are easy to implement and useful to implement something like switch operator. I used it in Pascal, when I was in school. Just pop old return address from stack and push new one.
Like for the C null-terminated strings, there are many alternative ways to implement variable argument lists and all of them have already been used many years before the first C compilers, e.g. passing a hidden parameter count or implementing transparently for the programmer any printf-like functions as vprintf-like functions.
With the alternative implementations, the stack should always be freed in the invoked function, which also enables various other important features, e.g. tail-call optimization.
All of those hark back to PL/I error handling, possibly through Project MAC (which was probably bigger PL/I user than anything from IBM for a time)
https://www.britannica.com/topic/Project-Mac
"Project MAC, in full Project on Mathematics and Computation, a collaborative computer endeavour in the 1960s that sought to to create a functional time-sharing system. Project MAC, founded in 1963 at the Massachusetts Institute of Technology (MIT), was funded by the U.S. Department of Defense’s Advanced Research Projects Agency (ARPA) and the National Science Foundation. The goal for the project was to allow many users access to the programs of a single computer from various locations. Project MAC’s pioneering exploration of the working methods of multiple-user access became a foundation for modern computer networking and online collaboration."
Nevertheless, this feature is much less useful in FORTRAN than in laguages like PL/I, because the FORTRAN labels are restricted to numbers.
Unless you use a preprocessor, you cannot give descriptive names to the error handlers, so the equivalent FORTRAN code looks much uglier than in PL/I.
I should have said that alternate return is obsolescent in recent Fortran, and I don't remember ever feeling the need to use it, at least for error-handling.
https://github.com/ratboy666/string
(Microsoft F80 was a FORTRAN 66, slightly subset compiler -- no COMPLEX that Microsoft sold from the late 70s to early 80s).
In there find pop.mac which is a short 4 byte assembly routine to discard a stack level. That can be used as follows:
ASSIGN 1 TO I -- STORE ADDRESS OF LABEL 1 TO I
CALL F(I) -- PASS I TO SUBROUTINE F
... -- WE WILL NEVER GET HERE
1 ...
SUBROUTINE F(I)
EXTERNAL $POP
INTEGER $POP
JUNK = $POP(0) -- REMOVE RETURN ADDRESS
GO TO I -- GO TO ASSIGNED LABEL I
END
The ASSIGN was deleted as a feature in FORTRAN 95 -- obsolescent by FORTRAN 90. I guess "very very old-school".
Now, the FORTRAN 66 standard doesn't mention if something like this is allowed... but, since no stack was involved in early implementations, and recursion was not allowed, I imagine that it would work more widely than might otherwise be expected.
Huh. I wonder if it would be possible to modify LLVM to support this for rust. You'd be inlining the match / try / unwrap() calls that usually happen after returning from a method which returns an enum variant. And you'd be inlining it across the function call boundary.
This would change the calling convention for methods that return enum variants, but rust doesn't publish a calling convention yet anyway. And for internal only methods, this might be a significant performance win in IO-heavy workloads.
You might need some complex heuristics to figure out when this is worth it though. Not all enums are Option / Result. I bet plenty functions are faster without this trick.
And if you jump based on the value in a register, is this fast in modern CPUs? How would that compare to making a high prediction accuracy branch?
https://github.com/bytecodealliance/wasmtime/issues/1057
We have looked at these before. Modern CPUs have a RAS, and you dont want to mess with that. But there are ways to implement this, and some papers that cover the performance impact.
We'd need a very motivated individual to add support for this to LLVM and Cranelift.
The method used by modern languages requires both an indirect jump for return, hopefully predicted, and a mispredicted conditional jump. Moreover, if the invoking function is executed once more, but the next time there is no error, the conditional jump that tests the error code may be mispredicted once more.
Using multiple return labels requires only a single mispredicted unconditional jump and it also omits a bunch of redundant instructions for generating an error code and testing it.
For functions that may encounter multiple types of errors, the economy is much larger because testing the returned error code would have needed either multiple conditional branches or an indirect indexed jump for a switch/case structure.
But Rust works on a really wide range of kinds of processors - CPUs, GPUs, FPGAs - and hardware architectures (dozen CPU architectures, dozen GPU architectures, etc.), and nobody has shown that this is a net win for all of them.
Figuring out for which, if any, this is a net win, is something that will have to be demonstrated.
Reading wiki I am not sure the assertion is right. In fact I am not sure even the first set of statements is right.
It was involved a lot of others from beginning (from users in share/guide) to other universities and European standard committees.
The design of the new language has taken into account the feedback from the users of FORTRAN IV and COBOL on the previous 7xxx series of IBM computers and it was also inspired by features from ALGOL 60, but otherwise there was no direct influence of outsiders on the language design.
Around 1966, a few extra features were added to PL/I, the most important being pointers and unions, which were taken from the Hoare and McCarthy proposals for the successor of ALGOL 60.
At that time IBM did not care yet if any of their programming languages will also be used on other computers. They were a hardware vendor, which offered as a bonus operating systems and programming languages with their computers, to convince the customers to buy the hardware. They were not selling software yet.
Compatibility with other hardware was not at all desirable for IBM. Only the other smaller companies were interested in porting IBM languages like FORTRAN or PL/I to their computers, to make them an acceptable alternative to IBM hardware.
So the standardization efforts were done in other places, but based on the de facto standards created by the IBM products.
On the downside, label variables entail the danger of jumping to an uninitialized or dead label value. This is a counterexample to another comment's claim that PL/I is a "safe" language.
It's been a long time, and I've not delved deeply in to a wide swath of languages (recently), but surely the features he's citing are in other languages? Hell, even the list of "features only Lisp has" keeps shrinking by the decade. Some of these PL/I "features" feel like things you could trivially implement in a library in other languages (ie, not have to implement half of PL/I to get those features). Some of it sounds simply like syntactic sugar, and not actual features.
What am I missing here?
However, some of these (#4 in particular) are exactly supported in other "modern" languages.
1. Assignment by name.
python: A = {**A, **B}
javascript: A = {...A, ...B};
2. Both binary and decimal data
For these you use libraries like Decimal in python, boost::multiprecision in C++
3. Bit strings of arbitrary length
vector<bool>, boost::dynamic_bitset, or write your own
in python you would use numpy
4. A named array is normally passed by reference, as in F(A)
In C++ you can do this for any type with a copy constructor.
void f(A_Type& A) { ...
... = f(A); // by ref
... = f({A}); // by value
5. IO by name.
Not generally done as far as I'm aware, but you could easily build this in C++. Something like
class StdOut { void operator=(string s) { cout << s; } };
StdOut{} = "hello\n";
6. SORT statement
Why not sort function? c++ std::sort, python sorted() builtin
7. Complete implicit conversion
Javascript is the KING here, and we all know how helpful that is....
Of course C++ let's you define this yourself, but there isn't directly language support.This was exactly the feeling I got as I read his list: "these aren't features, they are, at best, nice to have library functions and syntactic sugar."
Yes, you can use bit strings in PL/I, but the subroutine overhead was ginormous.
This is simply the worst case of PL/I data conversion routines. PUT EDIT and GET EDIT are somewhat less costly.
Structures are a two edged sword. Best to have them STATIC in the owning routine and have them based on pointers for other routines. Otherwise the prolog code can dwarf the code that does useful work.
PICTURE works very well in structures. Assigning between structures with fields of the same name in one PICTURE, and the other in machine format can often be performed without resort to data conversion routines.
Bottom line: Many advertised features are costly while PL/I offers remarkably efficient alternatives.
This seems like an extraordinarily bad idea.
That is orthogonal to the issue at hand.
> Weak/strong typing and dynamic/static typing are different axes.
And perl and javascript have both, and the weak typing is what gets criticised the most, and what causes the most issues.
So in your opinion, the PL/1 design here is closer to a trainwreck than an other trainwreck?
Furthermore C's implicit conversions come nowhere near parsing a string to get a float, that's squarely on the Perl/JS side of the board.
My point was that the implicit conversions in PL/1 have a different context in PL/1 than they have in Perl and Javascript, more akin to the one in C. One effect of that is that the type of a variable remains fixed in PL/1 where it doesn’t in Perl and Javascript. This places it at a different point in design space and changes the dynamics to some extent, which is just a nuance that I find interesting. It wasn’t expressed in the original comment I was replying to, so I thought it would be worth pointing it out so that he distinction isn’t being missed.
And it’s widely considered horrible.
where it is also generally considered
> an extraordinarily bad idea.
so it seems like a rather useless point?
Probably the greatest reliability regression from Multics to Unix was implementing the kernel and user apps in an unsafe language.
(Or, more accurately, using an unsafe compiler/ABI, as there have been memory-safe compilers/runtimes for ANSI C such as Fail-Safe C.)
The thinking behind that was that the set of keywords would grow over time, and that you couldn’t expect any programmer to know all of them.
There likely also are few programmers who do know all of them, as there are hundreds (see https://www.kednos.com/pli/docs/reference_manual/6291pro_042... for those of one implementation)
JavaScript has done something similar with its `await`, `let`, etc
This leads to this confusing block of code being legal (the syntax is almost certainly wrong however):
IF IF = THEN THEN
THEN := ELSE
ELSE ELSE = THEN THEN
THEN := ENDIF
ENDIFThis one actually piqued my interest in PL/I recently. Closest thing I’ve seen in modern languages is bitstrings in the BEAM.
I’ve heard about lisps having bitstrings support, but it was only briefly explained to me years ago and I haven’t seen it since.
For example, I don’t think C++ has such bit strings (the confusingly named bitset (https://en.cppreference.com/w/cpp/utility/bitset) comes close, but don’t think it does the substr and concatenation parts. basic_string<bool> has those, but not the Boolean operations), but they can be added when needed.
Then, I guess APL is not exactly 'modern' anymore...
I did a group project with it, and the language was large enough that we found that each member of the group seemed to have learned a slightly different subset of it.
E.g. what's good about automatic conversion between float and str? It can save you a minute or two if you're making a PoC or fiddling around in a notebook, but it's hiding real issues in your data flow if you're developing something for production use.
Maybe if IBM chose 68K for the PC, we would have gotten the full blown PL/I.
Edit, well actually I found this "X3.74, PL/I General Purpose Subset (Subset G)" from 1983. This version at least has strings.
Look at manual disk here:
https://winworldpc.com/product/digital-research-pl-i-compile...
Do you mean something like with-expressions? See https://docs.microsoft.com/en-us/dotnet/csharp/language-refe....
AFAIK `with` will only "copy with overwrites", similar to e.g. Rust's `..x`.
Visual Basic (VB6/VBA) does exactly this, with the same syntax (except without the outer parentheses if the call is a statement).
JS and Python always pass object references (pointers) by value (the value being the memory address), but in VB you can pass references by reference, references by value, values by reference or values by value, which lets you do things like this:
Dim x as Integer
x = 1
SomeFunction x
Debug.Assert x = 2 ' our local variable was reassigned from elsewhereI wonder how the claim stands up if we remove that "modern" adjective. Or perhaps consider that "modern" languages don't have some of these features as they turned out to be "harmful" (see Dijkstra's "GOTO considered harmful") - at least one reply in that thread calls out one of these "missing features" as very dangerous, sort of like how some C++ projects will forbid features (private inheritance, etc) for ease of maintenance.
In Go, you can copy a variable of type A to a variable of type B if the types have similarly named fields of same types, although an explicit cast is required.