<div dir="ltr">how about smalgol?<div><br><div>it was an algol-like language with just int and float types.</div><div>i dont know its history, but it came out of berkeley near</div><div>when Niklaus Wirth was there. it compiled for the ibm 7094</div><div>in normal batch processing fashion. i converted it to a jit</div><div>into memory in order to skip the loading phase. i used</div><div>it for a lot of my fun-work. (1965-66)</div><div><br></div><div>mainframe time, then, was a big factor in the computing process.</div><div>smalgol could compile, load, and run in about 1 cpu-second.</div><div><br></div><div>smalgol was all ibm-cards, but it was on my mind through</div><div>the bcpl to b to nb phases. i would use the modern word</div><div>"influencer."</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Mar 9, 2025 at 10:37 AM Clem Cole <<a href="mailto:clemc@ccc.com">clemc@ccc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson <<a href="mailto:g.branden.robinson@gmail.com" target="_blank">g.branden.robinson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At 2025-03-09T08:29:43-0400, Clem Cole wrote:<br>
> On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <<a href="mailto:crossd@gmail.com" target="_blank">crossd@gmail.com</a>> wrote:<br>
> > Was any consideration for it made?<br>
> ><br>
> Only Ken can answer that.   My guess is that Algol-W would have failed<br>
> for the same reasons Pascal ultimately failed.   It really was<br>
> directed at students and lacked many of the tools C had.  Many of the<br>
> issues exposed in Brian's treatise *"Why is Pascal not my favorite<br>
> programming language"* also apply to Algol-W.<br>
<br>
I think it's worth noting that, as I undertand it from having read the<br>
paper, old Pascal manuals, and ISO 7185 (and, a long time ago,<br>
experience with Borland Turbo Pascal), most or all of the defects<br>
Kernighan pointed out were addressed by vendored versions of Pascal and<br>
ultimately by its ISO standard form.  I think even UCSD Pascal had<br>
extensions, though I don't recall what they were.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Branden — respectfully, if you download the standard <a href="https://archive.org/details/iso-iec-7185-1990-Pascal" target="_blank">https://archive.org/details/iso-iec-7185-1990-Pascal</a> or look at versions that have been converted to HTML such as</font><font color="#9900ff"> </font></span><font color="#0000ff"><a href="https://wiki.freepascal.org/Standard_Pascal" target="_blank">https://wiki.freepascal.org/Standard_Pascal</a></font><span class="gmail_default" style="color:rgb(153,0,255);font-family:arial,helvetica,sans-serif">, </span><span class="gmail_default" style="color:rgb(0,0,255);font-family:arial,helvetica,sans-serif"> that statement is a tad hollow.</span><span class="gmail_default" style="color:rgb(0,0,255);font-family:arial,helvetica,sans-serif"> Sadly, that is the issue with Pascal.  The </span><span style="color:rgb(0,0,255)">fundamental flaws of the core Pascal language remained as described in Brian’s paper as:</span></div><div><br><font color="#38761d"><font face="monospace">1. Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult.<br><br>2. The lack of static variables, initialization, and a way to communicate non-hierarchically combine to destroy the ‘‘locality’’ of a program — variables require much more scope than they ought to.<br><br>3. The language's one-pass nature forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.<br><br>4. The lack of separate compilation impedes the development of large programs and makes using external libraries impossible.<br><br>5. The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.<br><br>6. The case statement is emasculated because there is no default clause.<br><br>7. The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language and no extension mechanism.<br><br>8. The language lacks most of the tools needed for assembling large programs, most notably file inclusion.<br><br>9. There is no escape</font><font face="monospace">.</font></font><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span></font></div><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></font></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My grasp of the chronology is poor, though, and I'd concede that Wirth's<br>
Pascal of his 1973 memorandum wears most or all of the mud Kernighan<br>
threw at it.  For the most part, solving the problems Kerngihan observed<br>
did not require doing violence to the language (in other words, they<br>
could be solved with extensions rather than by altering the semantics of<br>
valid 1973 Pascal syntax).<br></blockquote><div><font color="#0000ff">You >>are<< correct that many (not all) of the defects Brian and Dave ran into when updating/rewriting the Software Tools book from FORTRAN (Ratfor) to Pascal >>could<< <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">have </span>be<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">en</span> fixed.  The core issue with Pascal is that if an implementation did add an extension,<u><i> every implementation did it differently.</i></u></font></div><div><br></div><div><font color="#0000ff">Now, the truth is that having different implementations from different vendors was not unusual.  The whole reason ASA developed FORTRAN-66, which begat the many versions that followed [I believe FORTRAN-2018 is the last verified version, but I'm told by Dr. FORTRAN [Steve Lionel] that they are preparing an updated draft. BASIC had it in spades.  In fact, at one of the early 'Hatfield/McCoy" parties between my friends at HP and Tektronix, we count 14 different flavors of "HP BASIC" and 6 different flavors of "Tek Pascal." </font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Maybe this is what it means to have been "directed at students"--that<br>
easy wins in terms of language improvement were not implemented because<br>
covering them topically in a semester-long university course would not<br>
have been practical.  If so, that may make the tragedy of Pascal<br>
greater, not smaller.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#9900ff"></font><font color="#0000ff">History.  Wirth was teaching at Stanford when</font></span><font color="#0000ff"> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Algol-X was proposed. </span>In the late 1960s, the International Federation for Information Processing (IFIP) held the International responsibility for the definition of the programming language ALGOL 60, chartered IFIP Working Group 2.1 to develop a replacement for the language which had been identified, notably the lack of a standardized string subsystem. This effort was dubbed ALGOL X. <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">You can use an internet search to find several of them, but o</span>ne of the proposals was submitted by Niklaus Wirth and Tony Hoare. When their proposal was not accepted<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">,</span> the language ALGOL 68 would be developed under these auspices.</font></div><font color="#0000ff"><br>The committee decided that the <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Wirth/Hoare </span>proposal was an insufficient advance over ALGOL 60, and the proposal was published as a contribution to the development of ALGOL in CACM after making slight modifications to the language.  Wirth eventually decided to develop his proposal and created an implementation targeting the IBM System/360 at Stanford University. He called the new language Algol-W [used in many universities, and I used it at CMU, and I have friends that used  it at Cornell and Princeton]. </font></div><div class="gmail_quote"><font color="#0000ff"><br></font></div><div class="gmail_quote"><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">At the time, Wirth's original target was a tool to teach his students at Stanford. It was not a "production quality" compiler in the sense of IBM's FORTRAN-H, which was considered the "best" production compiler at the time. Also, remember the whole assembler/compiled code was hardly a settled debate.  Wulf's findings showed  BLISS was as good as the best  PDP-10/PDP-11 programmers, which was still a few years in the future.  As I've said elsewhere, it took enough students trained in the ideas from the Green Book a few years to get into the world to start to develop the optimizers we now expect as the norm.</span><br></font><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Though even that doesn't explain why Wirth didn't spec Pascal functions<br>
to admit polymorphism (perhaps optionally) in array length.  That's an<br>
essential property for all sorts of work, even that undertaken by<br>
students.  (Say you want them to write a function that multiplies<br>
matrices.  You shouldn't have to specialize the function by matrix<br>
dimensions.  The obvious pinch point for a Unix programmer is massive<br>
inconvenience if you want to handle variable-length strings.)<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Again, it was not considered an issue for what they were trying to solve.   Read the IFPS meeting notes.</span> </font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Perusing its manual some months ago, it occurred to me that if someone<br>
had had the foresight to implement the language core of Turbo Pascal<br>
7.0, ignoring the libraries/"modules" entirely, and omitting the crap<br>
necessary to work with the x86 segmented memory model, I don't think<br>
Kernighan would have had much, if anything, to complain about.  And, in<br>
my opinion, we'd be living in a better timeline.<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Turbo Pascal was a flavor of Pascal that came much later. At the time, UCB Pascal and UCSD Pascal were the two popular implementations for students, and commercial folks used Whitesmiths and, later, OMSI. The first three were the compilers Brian and PJ used (I believe all were running a V7 Unix, but I'm not positive about the target OS).</span></font></div><div><font color="#0000ff"><br></font></div><div><font color="#0000ff"><span class="gmail_default">FWIW: today's popular Pascal is Free Pascal (<a href="http://freepascal.org" target="_blank">freepascal.org</a>), and it accepts all of the syntax of Turbo, Object Pascal, and Delphi as input.</span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> But it was too late.</span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
But I guess Pascal just didn't get good enough, soon enough.<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">No, it was not agreed upon.  Everyone developing a Pascal implementation was pushing their flavor (sound familiar).  Turbo "won" when they targeted DOS, which, at the time, was being ignored by the traditional "professional" programmers (DOS was too much of a "toy" to be serious. - Minicomputers were the bread and butter).</span> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> When PharLap created an OS extension that allowed for a real 32-bit C for the 386, UNIX and C had already taken the mantel, and Pascal was losing favor in the DOS world.  </span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And I wonder how big such a compiler would be, even if coded<br>
competently.<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Look at OMSI, which primarily targeted the PDP-11.  It has many of these extensions [it basically started as one of the Tek Pascal's, BTW.</span> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> Jon and I worked with some folks who developed it.]</span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chronology bedevils us in another way.  A _lot_ of C language features<br>
its advocates are proud of were not present in 1973 or even when<br>
Kernighan wrote CSTR #100 around 1980. </blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Please be careful here. The point is that in 1980, Pascal and C, as described by Brain, C did not have the issues I listed above, but the popular Pascal implementations being used in the wild did.</font></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> It is an error to substitute the<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </span>ANSI C of 1989 for the C that actually existed at the time when asking<br>
who'd win in a fight between C and Pascal taking place in, say, 1977.<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">I don't since I lived it.</span> </font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<a href="https://gunkies.org/wiki/Typesetter_C" rel="noreferrer" target="_blank">https://gunkies.org/wiki/Typesetter_C</a></blockquote><div><span class="gmail_default"><font face="arial, helvetica, sans-serif"></font><font color="#0000ff" style="font-family:arial,helvetica,sans-serif">Need to work with Noel to update that page -- that name was because it came with the original </font><font face="monospace" color="#38761d">ditroff </font>- which<font face="arial, helvetica, sans-serif" style="color:rgb(0,0,255)"> used </font><font color="#38761d" face="monospace">libS.a</font><font color="#0000ff" style="font-family:arial,helvetica,sans-serif"> to replace Lesk's portable I/O library.    It was less an issue of new compiler language features and more the requirement for a new I/O library.  Remember, C and BLISS, as examples are defined without an I/O library in their origin stories.  They both use the local OS's IO interface.  C does not formally get an I/O library until Typesetter C and White Book.   Simply, until C moved to the Honeywell and 360  nd people started to "port" code, that Lesk started to codify an IO library that could be used regardless of the local OS.   Look at the documentation in V6. You'll see some interesting </font></span><span class="gmail_default"><font face="arial, helvetica, sans-serif"><font color="#0000ff">lik</font>e </font><font face="monospace" color="#38761d">fd = -1 </font></span><font color="#0000ff">an</font><span class="gmail_default" style="color:rgb(0,0,255);font-family:arial,helvetica,sans-serif">d</span><font color="#0000ff"> other</font><font color="#0000ff" style="font-family:arial,sans-serif"> artifacts</font><span class="gmail_default"><font color="#0000ff" style="font-family:arial,helvetica,sans-serif"> that Mike had in so that earlier code would recompile and </font><font color="#0000ff">relink</font><font color="#0000ff" style="font-family:arial,helvetica,sans-serif">. With typesetter C, Dennis forced a small rewrite of your code to use</font><font color="#38761d" face="monospace"> libS.a</font><font color="#0000ff" face="arial, helvetica, sans-serif">.</font></span></div><div><span class="gmail_default"><font color="#0000ff" face="arial, helvetica, sans-serif"><br></font></span></div><div><span class="gmail_default"><font color="#0000ff" face="arial, helvetica, sans-serif">As I said, I lived this whole war.</font></span></div><div>Crumudgingly<span style="color:rgb(0,0,255);font-family:arial,helvetica,sans-serif"> yours<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">,</span></span></div><div><span class="gmail_default"><font color="#0000ff" face="arial, helvetica, sans-serif">Clem</font></span></div></div></div><div hspace="streak-pt-mark" style="max-height:1px"><img alt="" style="width: 0px; max-height: 0px; overflow: hidden;" src="https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=a3cbaf0b-f555-44e5-b3bd-8d98d6544663"><font color="#ffffff" size="1">ᐧ</font></div>
</blockquote></div>