Lazarus
Miscellaneous => Other => Topic started by: hansotten on July 31, 2020, 10:44:12 am
-
Pascal is quite old now, around 1970 the first compiler appeared designed by Niklaus Wirth.
About 1978 I was exposed to Pascal, read the Algorithms + Data Structures 1976 book by Wirth and discovered compiler writing 'Wirth style': recursive descent down one pass in an understandable way. I have used those techniques a lot since, writing parsers, compilers etc. So I collected lots of books and articles and compilers during the years. Some very rare, some scanned by me, or collected from websites long gone now.
Since Freepascal has an 'ISO7185' mode, this is still relevant, but also fun to read.
A large update to my history of Pascal and its standards, where it comes from, the early compilers, sources of first compilers, unique articles and rare books, originally scanned, written by Niklaus Wirth, Per Brinch Hansen, Tony Hoare, Dijkstra, Jim Welsh and many more. Come and see it at http://pascal.hansotten.com
-
I've added that as a link to https://wiki.freepascal.org/Make_your_own_compiler,_interpreter,_parser,_or_expression_analyzer#See_also
Please check that I've rendered your name correctly, your website doesn't identify its publisher.
MarkMLl
-
Thanks!
My name is spelled ok, the website's name is School of Wirth, and that is misspelled!
-
Thanks!
My name is spelled ok, the website's name is School of Wirth, and that is misspelled!
Fixed! Nice website. :)
-
Pascal is quite old now, around 1970 the first compiler appeared designed by Niklaus Wirth.
About 1978 I was exposed to Pascal, read the Algorithms + Data Structures 1976 book by Wirth and discovered compiler writing 'Wirth style': recursive descent down one pass in an understandable way. I have used those techniques a lot since, writing parsers, compilers etc. So I collected lots of books and articles and compilers during the years. Some very rare, some scanned by me, or collected from websites long gone now.
Since Freepascal has an 'ISO7185' mode, this is still relevant, but also fun to read.
A large update to my history of Pascal and its standards, where it comes from, the early compilers, sources of first compilers, unique articles and rare books, originally scanned, written by Niklaus Wirth, Per Brinch Hansen, Tony Hoare, Dijkstra, Jim Welsh and many more. Come and see it at http://pascal.hansotten.com
Just because I noticed this (http://pascal.hansotten.com/delphi/turbo-pascal-on-cpm-msx-dos-and-ms-dos/) on your website and it might interest you: the development version of FPC has initial, experimental support for MSX-DOS (https://wiki.freepascal.org/MSX-DOS).
-
@hansotten
Great job! Very nice web site.
Thank you for all the work you put in to create it, structure all the information and for sharing it along with the relevant books, documents and, standards.
-
Great Job Hans!
Published your Site Link on :
https://www.lazarusforum.de/viewtopic.php?f=9&t=13070&p=115984#p115984
-
Awesome job. Thanks for this, Hans.
-
"The language was originally developed by Apple Computer as Clascal for the Lisa Workshop development system. As Lisa gave way to Macintosh, Apple collaborated with Niklaus Wirth, the author of Pascal, to develop an officially standardized version of Clascal. This was renamed Object Pascal." -- From the Wiki on Object Pascal.
Interestingly, this part of the story of Apple's hand in developing Object Pascal is not elaborated on much. Doesn't seem to be much information out there about why, the details, influences, and decisions. Though there are interviews with Niklaus Wirth, this part of the history isn't discussed.
-
Another thing that tends not to be discussed is that Wirth acted as a (AIUI paid) consultant to the Ada design process. It's interesting that later on he appeared to be very hostile to OO, arguing that everything could be done adequately using records.
MarkMLl
-
Interestingly, I found a pdf that introduces Clascal, which later was renamed Object Pascal. Clascal being a play on words of Pascal, as in Pascal with Classes. This talks about the concept of Clascal, what inspired it, and differences between it and versions of Pascal at that time. Also included is a download of the Lisa Pascal manual, as it's referenced in the Clascal document and the extensions were built on top of it.
Download PDF- An Introduction To Clascal (http://bitsavers.informatik.uni-stuttgart.de/pdf/apple/lisa/toolkit_3.0/Package_2_Examples/02_An_Introduction_To_Clascal_Jul84.pdf)
Download PDF- Lisa Pascal Reference Manual (http://bitsavers.informatik.uni-stuttgart.de/pdf/apple/lisa/workshop_3.0/Lisa_Pascal_3.0_Reference_Manual_1984.pdf)
Another thing that tends not to be discussed is that Wirth acted as a (AIUI paid) consultant to the Ada design process. It's interesting that later on he appeared to be very hostile to OO, arguing that everything could be done adequately using records.
Yes, information about Pascal's and Wirth's connection to Ada is hard to come by too, though in looking at Ada, it becomes readily apparent. Even Wiki makes no mention of Wirth's influence on Ada, though gives a brief mention of Pascal.
As for OOP, there is a famous quote attributed to Wirth, "Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming."
I can see where Wirth is coming from, because Pascal has records, nested functions, variants, and units. OOP is very much a choice, as oppose to a necessity or forced paradigm like it is in various other languages. From that perspective, OOP is used when appropriate or where it makes sense versus "if all you have is a hammer, everything looks like a nail". Wirth may have seen through the hype early, and knew OOP was not necessarily the "be all, end all". There is composition versus inheritance, modularization in contrast to OOP's take on encapsulation, and polymorphism is not owned by only OOP.
-
Yes, information about Pascal's and Wirth's connection to Ada is hard to come by too, though in looking at Ada, it becomes readily apparent. Even Wiki makes no mention of Wirth's influence on Ada, though gives a brief mention of Pascal.
But equally, Ada could have been "Child of ALGOL-68" since it has a terminating END on conditionals etc., which is in neither Pascal nor ALGOL-W.
I'm afraid that I've not been through all of OP's references, but an interesting question is whether the original Modula (i.e. predating Modula-2) had an explicit terminating END. The "THEN applies to a single statement" structure is undeniably elegant and is delightfully consistent with the in-expression IF-THEN-ELSE supported by ALGOL, but is a PITA in practice.
It's most unfortunate that the Great Unwashed- which includes 95% of programmers- insists on classifying languages as "Pascal-like" or "curly-bracket" solely on the use of BEGIN vs {
MarkMLl
-
"Larry Tesler worked with Niklaus Wirth to add object-oriented language extensions to the Pascal programming language."
It appears that Larry Tesler (who had an amazing career), was the person at Apple that was directing or creating the extensions (first known as Clascal, then Object Pascal) to Apple's Lisa Pascal (with consultation from Niklaus Wirth).
Among the many interesting things about Larry Tesler, he was the person Xerox assigned to show Steve Jobs around Xerox's Palo Alto Research Center in 1979. Computing legend Alan Kay (designer of Smalltalk and inventor of the term OOP) was the one who hired Tesler for Xerox in the first place, and then it was Steve Jobs who hired him away to work at Apple.
-
Hi!
In the 70s Xerox needed urgent new ideas. They started the Xerox Palo Alto Research Center (PARC) where crazy genious persons should develop new ideas and concepts. Often enough that were Acid dropouts - dont underestimate the influence of LSD in those days. Those persons were not able for daily work but they had great ideas: They invented the Mouse, they invented the GUI, they invented PostScript and they invented the Laser Printer. And they invented the Ethernet.
Where were we now without them??
Winni
-
As we are going down memory lane and doing origins. The Lisa Pascal Reference Manual, for which Clascal (later Object Pascal) is based on, is itself based on and references the Pascal User Manual and Report (the basis of the ISO standard), created by Kathleen Jensen and Niklaus Wirth. Presented as viewable PDF.
Pascal User Manual and Report (http://seriouscomputerist.atariverse.com/media/pdf/book/Pascal%20-%20Manual%20&%20Report.pdf)
-
As we are going down memory lane and doing origins. The Lisa Pascal Reference Manual, for which Clascal (later Object Pascal) is based on, is itself based on and references the Pascal User Manual and Report (the basis of the ISO standard), created by Kathleen Jensen and Niklaus Wirth. Presented as viewable PDF.
Pascal User Manual and Report (http://seriouscomputerist.atariverse.com/media/pdf/book/Pascal%20-%20Manual%20&%20Report.pdf)
There's several iterations of that, starting off with Wirth's original conference etc. papers. The quality improves substantially once Jensen is involved, I think I'd argue that she made a substantial contribution to the viability of the language.
Interestingly, a student on an MSc course I was once supporting did a spectacularly competent job "refactoring" some of the Multics documentation for her thesis. She singlemindedly adopted a uniform format: what a command did, its parameters, and- above all- if it was interactive how you backed out of it without breaking anything. It was a good illustration of how a bit of discipline can make an enormous difference, and I've tried to learn from it whenever I've been doing technical writing.
MarkMLl
-
It's interesting that later on he appeared to be very hostile to OO, arguing that everything could be done adequately using records.
https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig.pdf
Are you referring to ending of chapter 6.3 in this paper?
the careful observer may wonder, where the core of the new paradigm would hide, what was the essential difference to the traditional view of programming. After all, the old cornerstones of procedural programming reappear, albeit embedded in a new terminology: Objects are records, classes are types, methods are procedures, and sending a method is equivalent to calling a procedure. True, records now consist of data fields and, in addition, methods; and true, the feature called inheritance allows the construction of heterogeneous data structures, useful also without object-orientation. Was this change of terminology expressing an essential paradigm shift, or was it a vehicle for gaining attention, a “sales trick”?
I find chapter 6.3 sounding more as a critique to OOP terminology then being hostile to OOP in general. If you were referring to some other paper then I would appreciate a pointer as I would really like to read it. Thanks!
-
No, it was much older... something like 1986 and I saw in it the mid/late-90s. It came across as reactionary in the extreme: OO didn't (in his opinion) have anything to offer since everything could be done with records and so on.
I'll see if I can track it down but I don't hold out very much hope. Certainly won't be immediate, I'm trying to do some power electronics faultfinding for somebody.
MarkMLl
-
https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig.pdf
Are you referring to ending of chapter 6.3 in this paper?
Like most everything N. Wirth has done/written, I thoroughly enjoyed reading that paper. Thank you for posting it.
I find chapter 6.3 sounding more as a critique to OOP terminology then being hostile to OOP in general. If you were referring to some other paper then I would appreciate a pointer as I would really like to read it. Thanks!
I agree. Actually, I am surprised he didn't mention any of the rather significant downsides of OOP.
-
It's certainly a wide-ranging paper, but once one starts considering the details one has to have conclude that he's being selective with his recollections.
For example, he criticises ALGOL's dangling-else, without mentioning that it was fixed in ALGOL-68 but still present in his (slightly later) Pascal. He talks about := being ALGOL's assignment, which is wrong (it used a left arrow). He states that memory protection is unnecessary since compilers should be trusted, which has been proven false multiple times both before and after his date of writing. Finally, he talks about "loopholes" in programs, rather than the industry-standard "cast" or his own term "type transfer".
I agree with his point about excessive research into parsers such that absolutely any kind of syntax could be processed efficiently. I think I'm a bit more positive about extensible languages than he is, and I'm disappointed that he ignored Modula-3's capability for declaring that a module has a questionable implementation: there's a whole lot of things that are essential but should only be in specially "blessed" modules implemented by a skilled programmer and these could usefully include type transfers and extensible syntax. And so on.
MarkMLl
-
I never took it as Nicklaus Wirth being anti-OOP, but rather he didn't buy into the hype or "only OOP, all the time". The procedural programming paradigm can be just as viable, and as to which to use was a matter of the situation, studied choice, and/or preference. Though I do think he was making it clear, that it would be advantageous to fully grasp what can be done with procedural programming. Again, things such as: records, nested functions, default/optional parameters, variants, using units, etc... In this way, one can be more well informed about when one should or should not use OOP.
Nicklaus Wirth from a 1997 interview with Carlo Pescio
"Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming (OOP) solidly rests on the principles and concepts of traditional procedural programming (PP). OOP has not added a single novel concept, but it emphasizes two concepts much more strongly that was done with procedural programming. The fist such concept is that of the procedure bound to a composite variable called object. (The binding of the procedure is the justification for it being called a method). The means for this binding is the procedure variable (or record field), available in languages since the mid 1970s. The second concept is that of constructing a new data type (called subclass) by extending a given type (the superclass).
It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass. An interesting phenomenon is that many people learned for the first time about the important notions of data type, of encapsulation, and (perhaps) of information hiding when introduced to OOP. This alone would have made the introduction to OOP worthwhile, even if one didn't actually make use of its essence later on.
Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming. Static modularization is the first step towards OOP. It is much easier to understand and master than full OOP, it's sufficient in most cases for writing good software, and is sadly neglected in most common languages (with the exception of Ada).
In a way, OOP falls short of its promises. Our ultimate goal is extensible programming (EP). By this, we mean the construction of hierarchies of modules, each module adding new functionality to the system. EP implies that the addition of a module is possible without any change in the existing modules. They need not even be recompiled. New modules not only add new procedures, but - more importantly - also new (extended) data types. We have demonstrated the practicality and economy of this approach with the design of the Oberon System"
Full interview link- http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html (http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html)
-
I'll see if I can track it down but I don't hold out very much hope.
It is not of much importance and was just my curiosity, so no need to put much effort in it. I thought you could remember out of your head, so never mind. Thanks anyway!
... he criticises ALGOL's dangling-else, without mentioning that it was fixed in ALGOL-68 but still present in his (slightly later) Pascal.
In his self critique of GOTO he also regrets not fixing dangling else in Pascal:
The designer of Pascal retained the goto statement (as well as the if statement without closing end symbol). Apparently he lacked the courage to break with convention and made wrong concessions to traditionalists. But that was in 1968. By now, almost everybody has understood the problem, but apparently not the designers of the latest commercial programming languages, such as C#.
Pascal was officially out in 1969. He and his team were coding it for more then a year, and if you also count the effort needed before coding you can more or less safely guess that ALGOL 68 was not out when they started. There also was no internet at the time, so news were travelling slow. Besides, I do not think that they wanted to throw away thousands of punch cards just to change dangling else that ALGOL 68 fixed in the middle of their work. ;) Unfortunately Pascal was too late for that, but Modula-2 wasn't. :D
He talks about := being ALGOL's assignment, which is wrong (it used a left arrow).
Are you sure? Wikipedia is not always right but it quotes use of := in this ALGOL 60 code example:
https://en.wikipedia.org/wiki/ALGOL#ALGOL_60
It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass.
This is so true. I remember my early OOP days when I didn't have problems in embracing methodology, but have been struggling with terminology.
-
This is so true. I remember my early OOP days when I didn't have problems in embracing methodology, but have been struggling with terminology.
Terminology is important in programming. For instance, a significant percentage of programmers would frown at any extensive use of the "goto" statement, yet those very same programmers don't seem to have any problem with an equally extensive use of exceptions (which are a lot worse than a run of the mill "goto".)
Somewhere along the line some advertising folks starting participating in programming language design.
-
Nicklaus Wirth from a 1997 interview with Carlo Pescio
Full interview link- http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html (http://www.eptacom.net/pubblicazioni/pub_eng/wirth.html)
Thanks for the link, a very pleasant reading.
Is there any new language that follows the tradition of Pascal and Modula ?
Daniel
-
Is there any new language that follows the tradition of Pascal and Modula ?
Tongue-in-cheek I would say almost all the "new" features introduced in C/C++/C# and their ilk are attempts to introduce Pascal-ish constructions and concepts into them by the back door :P
-
To whom it may concern:
Revised Report On The Algoritmic Language Algol 60
by J.W. Backus et al
Edited by Peter Naur
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjrt86Th5TrAhXbi1wKHatEB7EQFjAFegQIBBAB&url=http%3A%2F%2Fwww.eah-jena.de%2F~kleine%2Fhistory%2Flanguages%2FAlgol60-RevisedReport.pdf&usg=AOvVaw2PMyMl4we82-BWrLJFMi5Z (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjrt86Th5TrAhXbi1wKHatEB7EQFjAFegQIBBAB&url=http%3A%2F%2Fwww.eah-jena.de%2F~kleine%2Fhistory%2Flanguages%2FAlgol60-RevisedReport.pdf&usg=AOvVaw2PMyMl4we82-BWrLJFMi5Z)
:= ruled already then!
Winni
-
This is so true. I remember my early OOP days when I didn't have problems in embracing methodology, but have been struggling with terminology.
Terminology is important in programming.
I agree that embracing terminology matters a lot. But I was more referring to Wirth mentioning giving new names to existing terms that only had some make up. There were new concepts, but quite a bit was old but renamed. There was no need for that.
Is there any new language that follows the tradition of Pascal and Modula ?
Oberon and Oberon-2?
-
There were new concepts, but quite a bit was old but renamed. There was no need for that.
I agree with that. I suspect that without the renaming, it wouldn't have attracted as much attention. The renaming made it look like a new concept even though in many ways it was not.
-
Is there any new language that follows the tradition of Pascal and Modula ?
Oberon and Oberon-2?
I think we should add Component Pascal into the mix, which is a superset of Oberon-2. Part of the issue is that with the various Object Pascal flavors (including Delphi) being so prominent and also evolving/updating, I think the other Wirthian languages can't get traction.
-
Is there any new language that follows the tradition of Pascal and Modula ?
Tongue-in-cheek I would say almost all the "new" features introduced in C/C++/C# and their ilk are attempts to introduce Pascal-ish constructions and concepts into them by the back door :P
Well yes, C++ keeps introducing features at a steady pace, the problem with older languages is that they can't deprecate features without breaking backwards compatibility, and its complexity is daunting. That's why I specified "new" language.
Is there any new language that follows the tradition of Pascal and Modula ?
Oberon and Oberon-2?
Kinda, Oberon is '87, Oberon 2 is '93, then you have Oberon 07. I tried BlackBox Component Builder some time ago and was underwhelmed, but I'm likely conflating the language and the tool here.
I was meaning newish like Nim, Zig or Pony, for example. This is just out of curiosity, anyway. I wonder how Object Pascal, Modula or Ada would look if they where designed in, say, 2015, from scratch.
Thanks,
Daniel
-
This is just out of curiosity, anyway. I wonder how Object Pascal, Modula or Ada would look if they where designed in, say, 2015, from scratch.
That's an interesting thought. My guess is that it would probably depend on what the language designer(s) consider(s) important in the language.
-
To whom it may concern:
Revised Report On The Algoritmic Language Algol 60
by J.W. Backus et al
Edited by Peter Naur
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjrt86Th5TrAhXbi1wKHatEB7EQFjAFegQIBBAB&url=http%3A%2F%2Fwww.eah-jena.de%2F~kleine%2Fhistory%2Flanguages%2FAlgol60-RevisedReport.pdf&usg=AOvVaw2PMyMl4we82-BWrLJFMi5Z (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjrt86Th5TrAhXbi1wKHatEB7EQFjAFegQIBBAB&url=http%3A%2F%2Fwww.eah-jena.de%2F~kleine%2Fhistory%2Flanguages%2FAlgol60-RevisedReport.pdf&usg=AOvVaw2PMyMl4we82-BWrLJFMi5Z)
:= ruled already then!
Winni
Thanks for that. I can certainly see that they've used it as a de-facto equivalent, but skimming the paper I can't see it defined as a digraph etc. My experience- although I'm entirely happy to be proven wrong- is that computers of the ALGOL-60 era very often had caps-only 64-codepoint character sets with arrows (and inequalities etc.) available, and that manufacturers had their own list of equivalents to allow the industry-standard IBM cardpunches to be used.
Interestingly, I got into a slight amount of trouble elsewhere for making the assumption that because a program fragment contained odd characters it had to be bogus. It turned out not to be: the early EDSAC computer apparently had ⊖ in its terminals' character set, and the publisher and printer had reproduced the Illustrious Author's manuscript accurately :-)
https://scifi.stackexchange.com/questions/233847/first-fictional-programming-language-in-sci-fi-or-fantasy/233942#233942
MarkMLl
-
I'll see if I can track it down but I don't hold out very much hope.
It is not of much importance and was just my curiosity, so no need to put much effort in it. I thought you could remember out of your head, so never mind.
What I can say is that it was reprinted in .Exe in the late 90s. I suppose I could drop Verity a line to try to get a reference, but I've got... rather a lot of odd stuff going on in life and could do with it not getting odder :-)
... he criticises ALGOL's dangling-else, without mentioning that it was fixed in ALGOL-68 but still present in his (slightly later) Pascal.
In his self critique of GOTO he also regrets not fixing dangling else in Pascal:
The designer of Pascal retained the goto statement (as well as the if statement without closing end symbol). Apparently he lacked the courage to break with convention and made wrong concessions to traditionalists. But that was in 1968. By now, almost everybody has understood the problem, but apparently not the designers of the latest commercial programming languages, such as C#.
Except that for the problem to be fixed in ALGOL-68 it must have been known several years earlier. I can sympathise with Wirth not fixing it in ALGOL-W, but since he intentionally broke ALGOL's syntax to get to Pascal he really has very little excuse (unless, of course, his earliest Pascal implementations still used recursive ascent, some of his earlier compilers look like right bitches to maintain and modify).
He talks about := being ALGOL's assignment, which is wrong (it used a left arrow).
Are you sure? Wikipedia is not always right but it quotes use of := in this ALGOL 60 code example:
https://en.wikipedia.org/wiki/ALGOL#ALGOL_60
Somebody else has contributed a link that demonstrates that e.g. := as an alternative to an arrow was known to the standard-setters early on. My understanding had been that it was a later occurrence, because of the necessity of being compatible with IBM card punches and (later) Teletypes. Of course, we've still got ¬ on UK keyboards :-)
It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass.
This is so true. I remember my early OOP days when I didn't have problems in embracing methodology, but have been struggling with terminology.
That might actually throw useful light on the bigger picture. Let's assume for a moment that the difference between "calling a procedure with parameters" and "sending a message to a method" is that methods are late-bound and polymorphic. Let's also assume that when Wirth claimed (according to my recollection) that classes/objects contributed nothing that couldn't be done with records, that he was overlooking (intentionally or otherwise) late binding and polymorphism.
I'd suggest that uncertainty as to /which/ procedure/method is to be called and uncertainty as to exactly how parameters will be promoted to alternate types to suit the implemented procedures are major language problems, and ones that- certainly in the Modula-2 era- Wirth did not want to grapple with. I certainly consider excessive polymorphism and automatic promotion to be a problem, perhaps there needs to be a pragma or linguistic "hint" indicating whether or not "useful idiocies" of that nature should be applied (again, I think that Modula-3 was more open to that sort of solution than any of Wirth's own languages).
MarkMLl
-
It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass.
This is so true. I remember my early OOP days when I didn't have problems in embracing methodology, but have been struggling with terminology.
That might actually throw useful light on the bigger picture. Let's assume for a moment that the difference between "calling a procedure with parameters" and "sending a message to a method" is that methods are late-bound and polymorphic. Let's also assume that when Wirth claimed (according to my recollection) that classes/objects contributed nothing that couldn't be done with records, that he was overlooking (intentionally or otherwise) late binding and polymorphism.
I'd suggest that uncertainty as to /which/ procedure/method is to be called and uncertainty as to exactly how parameters will be promoted to alternate types to suit the implemented procedures are major language problems, and ones that- certainly in the Modula-2 era- Wirth did not want to grapple with. I certainly consider excessive polymorphism and automatic promotion to be a problem, perhaps there needs to be a pragma or linguistic "hint" indicating whether or not "useful idiocies" of that nature should be applied (again, I think that Modula-3 was more open to that sort of solution than any of Wirth's own languages).
I strongly believe that Wirth knew exactly what he was talking about, in reference to OOP. When he was asked to consult on the creation of Clascal (which became Object Pascal) with Larry Tesler in 1985, he was dealing with a former employee of Alan Kay (who personally hired him) and one of the designers of Smalltalk, which some might say is true OO. And Alan Kay has not been shy about voicing his opinions. Wirth is also a Turing award winner. So not only that and his front row seat to the creation of Object Pascal, but having many years since then to reflect on it (and see it evolve) before the 1997 interview I linked to. Polymorphism is not owned by OOP, nor even overloading (which advanced records can do). Among other things, there is also usage of default/optional parameters, which I have seen referred to jokingly as sloppy polymorphism. Based on various quotes from Wirth, it seems he was thinking more along the lines of project size, kind of problem, and various simpler or different ways one can go about solving problems versus being forced or "religiously" locked into a paradigm.
The beauty of Object Pascal as a hybrid language, is people have more freedom and options to decide the way they want to go about things. It appears that Modual-3, Oberon-2, and Component Pascal have had to follow in the footsteps of Object Pascal, in terms of embracing being a hybrid. I don't think this is a knock on Wirth, but possibly more a reflection of expectations and/or an added selling point, that a language include OOP.
-
I think we should add Component Pascal into the mix, which is a superset of Oberon-2. Part of the issue is that with the various Object Pascal flavors (including Delphi) being so prominent and also evolving/updating, I think the other Wirthian languages can't get traction.
I don't think that. I simply think those languages and their tooling never were complete enough to really be attractive. (Some commercial Modula2's excepted maybe).
I originally migrated back to Pascal because I was translating Turbo Pascal code half of the time anyway, to get decent examples of how to do something, and I was really frustrated with the overly laborious string handling in Modula2.
At the same time, the Modula2 newsgroup seemed mostly filled with language enthusiasts and the then emerging "standard", something that didn't help *users* very much.
-
As we are going down memory lane and doing origins. The Lisa Pascal Reference Manual, for which Clascal (later Object Pascal) is based on, is itself based on and references the Pascal User Manual and Report (the basis of the ISO standard), created by Kathleen Jensen and Niklaus Wirth. Presented as viewable PDF.
Pascal User Manual and Report (http://seriouscomputerist.atariverse.com/media/pdf/book/Pascal%20-%20Manual%20&%20Report.pdf)
Thanks for the link! Book added, it is an important part of the ISO Pascal information.
-
Hans, do you have this link https://www.research-collection.ethz.ch/handle/20.500.11850/68669 from Wp? I believe that it describes the original Modula, i.e. pre-2, and if I'm correct it's significant in that it indicates at what point the dangling-else problem was fixed.
Also, if you've not got it, https://github.com/retro-software/B5500-software and possibly https://github.com/pkimpel/retro-b5500 might interest. I've not investigated whether the copy of Euler there is actually compilable/runnable, and the mapping from the 64-codepoint character set to 7-bit ASCII can be a bit weird.
I think you've got links to all his Stanford stuff, but http://www.ianjoyner.name/Files/Waychoff.pdf suggests some of the politics behind the university's (and SRI/SLAC etc.) choice of computers... and don't forget Pastel.
MarkMLl
-
Hans, do you have this link https://www.research-collection.ethz.ch/handle/20.500.11850/68669 from Wp? I believe that it describes the original Modula, i.e. pre-2, and if I'm correct it's significant in that it indicates at what point the dangling-else problem was fixed.
Also, if you've not got it, https://github.com/retro-software/B5500-software and possibly https://github.com/pkimpel/retro-b5500 might interest. I've not investigated whether the copy of Euler there is actually compilable/runnable, and the mapping from the 64-codepoint character set to 7-bit ASCII can be a bit weird.
I think you've got links to all his Stanford stuff, but http://www.ianjoyner.name/Files/Waychoff.pdf suggests some of the politics behind the university's (and SRI/SLAC etc.) choice of computers... and don't forget Pastel.
MarkMLl
Thank you for the links! Yes, the collection is still a bit mostly early Pascal. Modula requires more attention.
-
Hans, do you have this link https://www.research-collection.ethz.ch/handle/20.500.11850/68669 from Wp? I believe that it describes the original Modula, i.e. pre-2, and if I'm correct it's significant in that it indicates at what point the dangling-else problem was fixed.
MarkMLl
Thanks for this link, 240 documents by Niklaus Wirth, it's a treasure !!! In this one:
https://www.research-collection.ethz.ch/handle/20.500.11850/68705
he talks about the object oriented programming fad and how Modula 2 can be extended to achieve the same features, and how he did that in Oberon (this paper is from '89, the first Oberon was from '83). Very enlightening. Well, to me at least, I guess most people around here are aware of this.
Daniel
-
https://www.research-collection.ethz.ch/handle/20.500.11850/68705
he talks about the object oriented programming fad and how Modula 2 can be extended to achieve the same features, and how he did that in Oberon (this paper is from '89, the first Oberon was from '83). Very enlightening. Well, to me at least, I guess most people around here are aware of this.
Agree, this is a very good find, when it comes to Wirth's thoughts on OOP and his other creations (Modula and Oberon). Here he is making it very clear and breaking down what is OOP, then showing what his approach is about.
-
Here he is making it very clear and breaking down what is OOP, then showing what his approach is about.
And more importantly, he made it quite clear that OOP isn't the panacea (magic bullet that makes all programs better) it has been painted as.
... we believe the use of object oriented programming should be employed selectively only where appropriate. In the design of an entire operating system, we found that almost the whole system was advantageously programmed in the conventional style, the object-oriented style being restricted to the viewer system which provides distributed control.
(emphasis mine) That's a far cry from what is happening these days. Just about everything under the sun is being turned into a class/object.
Ignore my comments but, don't ignore those of N. Wirth. He knows a "little bit" about programming.
-
Ignore my comments but, don't ignore those of N. Wirth. He knows a "little bit" about programming.
I agree, provided that he's not blinkered by "what he's thought of" and "what he can graft onto existing projects" traps.
I can't help but feel that that paper has a number of flaws, one of the most serious of which is that Wirth glosses over any consideration of the distinction between method references which are unambiguously resolved at compilation time, and those that- due to polymorphism etc.- cannot be resolved until runtime. Because of this, he appears to condemn the use of objects to represent short-lived transient data, where the create/manipulate/destroy cycle can be particularly useful: provided that each message is not burdened with excessive references to VMTs etc.
I certainly agree that any technique can be overused, and I am regularly dismayed when I see a description of some new technique boast of "only" a 5% inefficiency relative to its predecessor, which in turn had "only" and 5% inefficiency relative to its predecessor...
I'd suggest that the real problem is poor documentation, and poor discipline amongst programmers implementing facilities from poor definitions. And having such a vital part of modern software being implemented by volunteers who can be expected to keep doing it only as long as they are having fun is perhaps the biggest problem of our time, dwarfing the "software crisis" of the late 60s and early 70s.
-----
I would crave indulgence for a moment whilst I recount a bit of history, or at least my perception of it. It is common knowledge that Wirth spent at least one sabbatical at Xerox PARC, during which he learnt about the mouse, GUIs, the possibility of building a comparatively simple microprogrammed CPU and so on.
What isn't generally known is the extent to which Logitech- who at the time were a Swiss company- either acted as Wirth's commercial vehicle, or watched what he was doing and got their inspiration from the same sources. Those few who remember them as a compiler supplier (and at one time I was their de-facto British technical support) obviously know about their initial DOS/embedded products and their later (and not entirely successful) foray into supporting OS/2. They also had a well-regarded debugger called Multiscope which I think was spun off when they morphed into a mouse manufacturer.
At one point Logitech had something which I think they called their Mouse Programmer's Toolkit, and in it there was example code (in Modula-2) which had a complete message loop handler unifying keyboard and mouse input. I can't remember whether this had hooks for GUI or TUI support, but it was pretty damned unusual stuff to find as source in the mid-80s.
Which takes us back to a possible assumption by Wirth that the /only/ way to program an OO system was by using explicit messages, with all dispatching to appropriate handlers done at runtime, and no optimisation by the compiler which could make unambiguous references every bit as efficient as straight procedural programming. Or possibly only lose 5% or so in relative efficiency :-)
MarkMLl
-
At one point Logitech had something which I think they called their Mouse Programmer's Toolkit, and in it there was example code (in Modula-2) which had a complete message loop handler unifying keyboard and mouse input. I can't remember whether this had hooks for GUI or TUI support, but it was pretty damned unusual stuff to find as source in the mid-80s.
MarkMLl
Hi!
The Logitech Modula toolkit was cool. I learned a lot from it.
The manual can be found here:
https://archive.org/details/bitsavers_logitechLoersToolkitNov86_1580854 (https://archive.org/details/bitsavers_logitechLoersToolkitNov86_1580854)
Winni
-
Hans, do you have this link https://www.research-collection.ethz.ch/handle/20.500.11850/68669 from Wp? I believe that it describes the original Modula, i.e. pre-2, and if I'm correct it's significant in that it indicates at what point the dangling-else problem was fixed.
MarkMLl
Thanks for this link, 240 documents by Niklaus Wirth, it's a treasure !!! In this one:
https://www.research-collection.ethz.ch/handle/20.500.11850/68705
he talks about the object oriented programming fad and how Modula 2 can be extended to achieve the same features, and how he did that in Oberon (this paper is from '89, the first Oberon was from '83). Very enlightening. Well, to me at least, I guess most people around here are aware of this.
Daniel
That leads us to three questions:
1. Why Niklaus Wirth moved on from Pascal to Modula, and then to Oberon?
2. Is there any current worth mentioning professional software built with Modula or Oberon?
3. Is Modula or Oberon any better than modern Pascal?
-
That leads us to three questions:
1. Why Niklaus Wirth moved on from Pascal to Modula, and then to Oberon?
2. Is there any current worth mentioning professional software built with Modula or Oberon?
3. Is Modula or Oberon any better than modern Pascal?
My understanding:
1) Separate compilation (in particular separate precompiled definition modules), remove "magic" required for things like WriteLn() from the language, coroutines, and better-defined type checking. Strings implemented as zero-based arrays of char might or might not have been an advance, bitsets were an advance but ordering was platform-specific without adequate infrastructure.
2) Not that I know of.
3) Fixes dangling-else. Arguably provides a more robust base language on which extensions could be built, but ideally this would require an extensible language definition accessible to (senior) application programmers.
MarkMLl
-
That leads us to three questions:
1. Why Niklaus Wirth moved on from Pascal to Modula, and then to Oberon?
2. Is there any current worth mentioning professional software built with Modula or Oberon?
3. Is Modula or Oberon any better than modern Pascal?
My understanding:
1) Separate compilation (in particular separate precompiled definition modules), remove "magic" required for things like WriteLn() from the language, coroutines, and better-defined type checking. Strings implemented as zero-based arrays of char might or might not have been an advance, bitsets were an advance but ordering was platform-specific without adequate infrastructure.
2) Not that I know of.
3) Fixes dangling-else. Arguably provides a more robust base language on which extensions could be built, but ideally this would require an extensible language definition accessible to (senior) application programmers.
MarkMLl
1) Separate compilation (in particular separate precompiled definition modules),
Ok.
remove "magic" required for things like WriteLn() from the language,
Was that so bad?
coroutines,
What do you mean?
and better-defined type checking.
Ok.
Strings implemented as zero-based arrays of char might or might not have been an advance,
Knowing the number of characters in a string up to 256 characters stored in [ 0] was a bad idea?
bitsets were an advance
What do you mean?
but ordering was platform-specific without adequate infrastructure.
What do you mean?
-
remove "magic" required for things like WriteLn() from the language,
Was that so bad?
Yes, since the language was not extensible. In particular in the case of Writeln() etc. Pascal (as per J&W) has no provision for "variadic" parameter lists or for open (dynamically-sized) arrays.
coroutines,
What do you mean?
See https://en.wikipedia.org/wiki/Coroutine
bitsets were an advance
What do you mean?
but ordering was platform-specific without adequate infrastructure.
What do you mean?
A bitset was defined as allowing access to the individual bits in a machine word, but the definition omitted any statement as to whether bit zero was LSB or MSB... and I've seen both assumptions made, even on the same target CPU.
Don't get me wrong: Modula-2 was useful, and I've used it to write a microkernel (portable between Z80, 8086 on DOS, and 80286 bare-metal protected mode).
MarkMLl
-
remove "magic" required for things like WriteLn() from the language,
Was that so bad?
Yes, since the language was not extensible. In particular in the case of Writeln() etc.
Pascal (as per J&W) has no provision for "variadic" parameter lists or for open (dynamically-sized) arrays.
Who is J&W?
extensible language
https://en.wikipedia.org/wiki/Extensible_programming
http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf
-
Strings implemented as zero-based arrays of char might or might not have been an advance,
Knowing the number of characters in a string up to 256 characters stored in [ 0] was a bad idea?
I don't know how the original string definition of Wirth was, but at least in ISO Pascal it's as follows (6.4.3.2 Array-types):
Any type designated packed and denoted by an array-type having as its index-type a denotation of a subrange-type specifying a smallest value of 1 and a largest value of greater than 1, and having as its component-type a denotation of the char-type, shall be designated a string-type.
Thus a ShortString as we know it from TP did not exist.
-
Who is J&W?
https://www.amazon.com/PASCAL-User-Manual-Report-Jensen/dp/354006950X
Daniel
-
Who is J&W?
Kathleen Jensen and Niklaus Wirth, mostly this is a reference to the Pascal User Manual and Report book.
-
Who is J&W?
The adoption of Pascal owes as much to Kathleen Jensen's clear exposition as to Wirth's design.
extensible language
https://en.wikipedia.org/wiki/Extensible_programming
A fairly good review. I'd add however that during the '60s, i.e. the first period discussed in that article, binary linkage hadn't really caught on: not only was it far more common to either have to submit an entire program as a single card deck or possibly augment the source with files included from tape or disc, but there was really no concept of a separate system library which implemented e.g. the I/O facilities which were nominally part of the language.
In other words, in the 1960s if you wanted to change the behaviour of something like WriteLn() then it was considered to be extension of the language: there was no real way to say "link in a non-standard RTL so that my program can access a novel peripheral device".
Modula-2 wasn't the first language/implementation to support binary linkage. It was, however, arguably the first to (a) provide robust type-checked separate compilation and (b) by having distinct definition and implementation modules allow the possibility of applying access restrictions to ensure that junior staff couldn't override specifications provided by their betters.
MarkMLl
-
remove "magic" required for things like WriteLn()
Minimalism in general. Maybe also portability.
Strings implemented as zero-based arrays of char might or might not have been an advance,
Well, he would have been comparing from seventies Pascal, not eighties UCSD/TP strings.
On one hand the open array ability improved writing general string routines compared to seventies pascal, on the other hand in retrospect keeping it mostly statically allocated was maybe a missed opportunity, and something that wouldn't survive the eighties. Even for systems programming.
bitsets were an advance but ordering was platform-specific without adequate infrastructure.
Maybe for embedded programming, flag testing etc. But imho bitpacking of records is more important for that.
3) Fixes dangling-else. Arguably provides a more robust base language on which extensions could be built, but ideally this would require an extensible language definition accessible to (senior) application programmers.
Some of the language things of Modula2 were ok, compared with nineties Pascal. But it didn't even have the practical extension and implementation that Pascal had. The Modula2 world was so small.
I do know that some medical vendors used Modula2 a lot in the nineties for critical systems, but most of that has disappeared (some reached out to me in the 2005-2010 timeframe to assess what they had, which was TS 1.17 dos code, so not much)
Oberon was always more experimental. I never saw professional Oberon use myself.
-
I've just started reading a paper by Knuth called "Structured Programming with goto Statements". https://www.cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf
I suggest that it might be of interest to others, since it pulls together examples and opinions from a number of luminaries of the 60s and early 70s, including even Val Schorre whose Meta-2 I've mentioned in the past.
One of Kunth's observations is that
"...people are now beginning to renounce every feature of programming that can be considered guilty by virtue of its association with difficulties. Not only goto statements are being questioned; we also hear complaints about floating-point calculations, global variables, semaphores, pointer variables, and even assignment statements. Soon we might be restricted to only a dozen or so programs that are sufficiently simple to be allowable; then we will be almost certain that these programs cannot lead us into any trouble, but of course we won't be able to solve many problems."
But particularly telling is this from Dijkstra himself:
"Please don't fall into the trap of believing that I am terribly dogmatical about [the goto statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"
And of course the ACM editor who caused all the trouble by giving Dijkstra's original paper a snappy title was Niklaus Wirth.
MarkMLl
-
"Please don't fall into the trap of believing that I am terribly dogmatical about [the goto statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"
I liked a professor that said (on the question of some l33t person about the usage of assembler in an TP assignment) that you could use anything, but anything not in the handout required three page essay to explain why you really needed that feature.
I still think that is a nice litmus test, I also apply it to gotos. I have 2 gotos in my work (Delphi) codebase :-)
-
:-) But have you ever tried to read any of Wirth's early compilers, even the ones written in ALGOL?
MarkMLl
-
My 2 cents: I converted an old style Fortran program with its usual amount old fashioned constructs like (arithmetic) GOTOs and IFs. Taking into account the time of its creation, it was fairly nice code. At least compared to other hacks, i have seen from those times. The initial motivation was simply style, aestethics, maybe readability for young programmers.
To my surprise the program gained execution speed already with moderate optimisation levels. I assume that the more modern constructs have a more clear path of flow and are easier to optimise than the old style spaghetti-type of code.
MiSchi.
-
I don't know how the original string definition of Wirth was, but at least in ISO Pascal it's as follows (6.4.3.2 Array-types):
Hi!
There was no string definition in Wirths Pascal.
From his point of view you could it build yourself with an array of char.
The first Pascal string definition occured in UCSD Pascal: The well know "Pascal (short) strings".
Later it was used in Turbo Pascal.
Winni
-
There was no string definition in Wirths Pascal.
From his point of view you could it build yourself with an array of char.
The first Pascal string definition occured in UCSD Pascal: The well know "Pascal (short) strings".
J&W ed. 4 linked to earlier certainly discusses strings, both in the literal form and one defined as packed array[1..n] of char
I don't know if that was in earlier editions (and am not checking since I'm going out soon), and I note the careful definition to avoid element zero which might have been because by then UCSD etc. had done its own thing.
Modula-2 of course had no special string type, but instead used (open?) arrays with zero origin.
MarkMLl
-
Modula-2 of course had no special string type, but instead used (open?) arrays with zero origin.
Static arrays that could be passed to open array procedures. Partially zero terminated (if the string completely filled the allocation size, then it was not zero terminated.
-
Modula-2 of course had no special string type, but instead used (open?) arrays with zero origin.
MarkMLl
And Miele Modula 2 for OS/9 (realtime Unix) had not even one library for strings.
The very simple routines like insert, delete , concat you had to do on your own.
Not such a big support for Modula 2.
Winni
-
And having to check for both an index being within bounds and the current character not being zero is painful (particularly with people saying that break/continue/exit are tantamount to goto so must be cast out)... although I wish more C programs took the trouble to do so.
MarkMLl
-
1. Why Niklaus Wirth moved on from Pascal to Modula, and then to Oberon?
2. Is there any current worth mentioning professional software built with Modula or Oberon?
3. Is Modula or Oberon any better than modern Pascal?
I think many people are curious about at least the first 2 questions, which are very good ones. The 3rd question, of Pascal versus Modula and Oberon, has a lot to do with preference. Though a huge factor is Pascal having the corporate backing of Apple and then Borland/Embarcadero.
In a more recent interview done with Wirth (link below), there is more insight given into his thinking in regards to developing Modula and Oberon. It appears that in the case of the time frame of him doing Modula and Oberon, he was greatly curious about OS and hardware development. As a scientist, Wirth had a degree in electrical engineering and built his own TVs as a younger man. This background also corresponds with him developing the Lilith computer (link below).
In an alternate universe, Niklaus Wirth could have been the European replacement of Bill Gates or Steve Jobs. His Lilith computer, along with the operating system based on Modula-2 and Oberon came out in a competing time frame. Oberon, the OS, was out on computers when Windows 3.1 was being developed. In fact, a lot of research will have to be done to ascertain which was more advanced. It appears Oberon was in many respects, though eventually Microsoft's success, new versions, and money would mostly overwhelm all competitors.
His interests were beyond just programming languages. It could be argued that he didn't so much abandon Pascal, as he had his sights on higher goals or other pursuits in the computer industry (to include RISC Architecture and FPGA). We also have to remember, that he was an consultant on the development of Clascal (which became Object Pascal), so he still had his "fingers in the mix" there too. Lastly, an element of this is that Wirth retired in 1999 (was a professor since 1968). So his level of involvement in various pursuits appears to be not as vigorous as his younger days. Though even in retirement, he has done a lot of amazing things.
https://youtu.be/OEmMx55SF8U (https://youtu.be/OEmMx55SF8U)
(Interview with Niklaus Wirth, subtitles are in English)
https://en.wikipedia.org/wiki/Lilith_(computer) (https://en.wikipedia.org/wiki/Lilith_(computer))
(DISER Lilith, custom built computer with AMD processor, uses Modula-2 to build OS, started project in 1978)
-
Apropos language history, somebody elsewhere has just pointed me at https://www.cl.cam.ac.uk/~mr10/cpl2bcpl.pdf by Martin Richards, discussing the history of CPL (an ALGOL-60 derivative), BCPL, and hence briefly C.
It has some interesting observations on the gradual changes of character sets as the industry moved towards a definition of ASCII, for example CPL used § and § for blocks, which was superseded first by $( $) and later { }.
It's also interesting that CPL and BCPL apparently used "Pascal style" calling convention, unlike C which has its own.
MarkMLl
-
A very belated comment on := as a digraph to get it into the record.
Thanks for that. I can certainly see that they've used it as a de-facto equivalent, but skimming the paper I can't see it defined as a digraph etc. My experience- although I'm entirely happy to be proven wrong- is that computers of the ALGOL-60 era very often had caps-only 64-codepoint character sets with arrows (and inequalities etc.) available, and that manufacturers had their own list of equivalents to allow the industry-standard IBM cardpunches to be used.
Apparently := was in IAL (AKA ALGOL 58), where it was allegedly "forced in" by the American delegates overriding the preference of Zuse/Rutishauser. See https://en.wikipedia.org/wiki/Plankalk%C3%BCl#Assignment_operation and the Bauer reference section 6 and footnote 9.
So contrary to my earlier belief := was never a digraph for left-assigning ←, but instead was adopted (with an arrow as an alternative) as a replacement for the Rutishauser right-assigning ⇒ or Zuse's unique glyph which I believe has no modern codepoint.
https://en.wikipedia.org/wiki/File:Ergibt-Zeichen.png
MarkMLl
-
Yes, information about Pascal's and Wirth's connection to Ada is hard to come by too, though in looking at Ada, it becomes readily apparent. Even Wiki makes no mention of Wirth's influence on Ada, though gives a brief mention of Pascal.
Adding to a rather old thread for historical completeness. Via https://en.wikipedia.org/wiki/High_Order_Language_Working_Group I find http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm hence
David Fisher acted as the Secretariat for the HOLWG, and so became the one who assembled, sifted, correlated, and integrated the requirements, since during the first couple of years, this was the primary action and output of the HOLWG. Fisher had designed machines at Burroughs and taught at Vanderbilt University, before joining IDA. His position was that of the technical heart of the project. It would be improper to say that he "wrote" the requirements, since this was an integration effort of Service needs with worldwide technical input. However, he that produced the final requirements documents; these were his offspring.
The resulting document, entitled STRAWMAN [HOLWG, 1975a], was forwarded to the Military Departments, other government agencies, the academic community, and industry. Additionally, a number of technical experts outside the United States were solicited for comments. The European community was especially responsive, particularly valuable since language research had been more active there than in the United States over the previous decade. ONR London paid several academics (Dijkstra, Hoare, Wirth, ...) to provide inputs, but we got more valuable aid from European industry.
Burroughs was, of course, heavily into ALGOL-60 derivatives for its mainframes, which by the mid-70s would probably have been the B6800 series with semiconductor memory rather than core.
I can't find any more information on who the other paid consultants were, but it's interesting to speculate that there was substantial overlap with the authors and supporters of the ALGOL-68 "Minority Report", i.e. Dijkstra, Duncan, Garwick, Hoare, Randell, Seegmuller, Turski, Woodger, Naur and Wirth.
MarkMLl