Regarding types and array, some of this is already in the very structure of a Pascal program, which is very rigid. As I recall it, even, if there were arrays of arbitrary length of a common type in Pascal, you couldn’t do something as simple as ask for a length first and then define an array of that length inside your program, which was trivial in Algol (because a definition section could be at the start of every block and you could have a block everywhere).
Regarding the criticism of types and their limitations in general, while there were libraries and enhanced flavors, this wouldn’t have done for basic OS tools, which should compile out of the box, which was Kerighan’s use case. In this respect, lacking bit-level access is also damning. But, in all fairness, this isn’t what Pascal was designed for. (On the contrary, it was designed to keep you away from such things.)
break and premature
return are nice to have, especially for the tasks Kerighan was working on, and Pascal adds certainly another level in the control flow to work around them. However, we have all seen worse things, I guess.
Some of Kerighan’s criticism isn’t without irony. For example, “There is no guaranteed order of evaluation of the logical operators
or — nothing like
|| in C.”
First, Pascal isn’t alone here, but, I admit, once you encountered short circuit evaluation, it’s hard to see, why anyone should do without it. But, what about C and the “guaranteed order of evaluation”? What about
a = b++ * c + b … ?
In the original specification, nothing in C tells you, when
b will be incremented and what
a will actually be. As in Pascal, we have something to work around…