On 2025-01-13 12:18 p.m., Brent Hilpert via cctalk wrote: This quote comes to mind. The politics involved with ALGOL for 1) having a character set with no [] but lots of the /\ \/ like characters, 2)not having a machine with ample power for recursion and indexed data structures. 3) Eggheads who kept adding features, like call by name and dynamic arrays. 4)Student and production compilers where two different beasts with No standard defined IO, do to a lack of standard disc operating system calls. really slowed use of algol type languages in development and use. Funny when the 8 and 16 bit micros hit the market, Algol seemed to vanish off the face of the earth. Was 64KB too small a address space? I never liked the idea of dynamic arrays, who knows when the heap? will overflow. With static data it fits, or not at all.

Re: “Algol seemed to vanish off the face of the earth. “ I think the popularity of languages is due to how trendy they are to teach in Colleges. Witness the popularity of Python. That’s being taught in school these days. Sent from my iPhone

On 1/13/2025 4:31 PM, Wayne S via cctalk wrote: Thus the reason I am still a strong advocate for COBOL. Languages should be domain specific and not general purpose. bill

If C were called Algol SC [Algol With Special Characters, e.g. using { instead of BEGIN, } instead of END, &c] then there would be absolutely no talk about "Algol vanishing off the face of the earth". Almost all commonly used languages use Algol SC syntax. C++, Java... even JavaScript even though JavaScript semantics are much more like LISP. I'd say that, looking at the first three languages (LISP, FORTRAN, Algol 60), Algol won the syntax war and most of the semantics war, with LISP semantics coming in second. FORTRAN was a dead end, both in syntax (line-oriented, line numbers) and semantics (common blocks, static arrays, very poor string support). Oops, forgot COBOL. I honestly have never programmed in COBOL. But its syntax seems dead and its semantics are now just standard formatting libraries. On Mon, Jan 13, 2025 at 1:31 PM Wayne S via cctalk <cctalk(a)classiccmp.org> wrote:

OK, but do you know what I mean? I should have said that classic FORTRAN syntax was a dead end. Modern FORTRAN to me looks like "Algol F". P.S. Apologies but I may be confusing this thread with another (on this or some other list) about Hollerith constants. Which definitely were (semantically) a dead end. On Mon, Jan 13, 2025 at 6:51 PM Van Snyder <van.snyder(a)sbcglobal.net> wrote:

On 2025-01-13 9:33 p.m., Fred Cisin via cctalk wrote: Who wants 2025, FORTRAN IV was portable. Sometimes you need the original version warts and all. Look how many versions of ADVENTURE is out there.

Does Fortran 2025 provide pointers and make it possible to dereference an invalid pointer? If not, then I guess that’s one reason to use it instead of C. On Tue, Jan 14, 2025 at 6:28 AM Peter Corlett via cctalk < cctalk(a)classiccmp.org&gt; wrote:

On Tue, 14 Jan 2025, Van Snyder via cctalk wrote: I first taught Fortran in community college in Fall 1983. In the lab, we used the IBM/Micorosft Fortran, which worked very well for THAT task, but had some serious deficiencies. A "Sieve of Erastothanes" compiled in it ran slower than in BASICA. Bob Wallace (who was still at Microsoft) warned me to avoid the run-time library. My FORTRAN experience was from fifteen years prior (PDQ FORTRAN, WATFOR, and FORTRAN 4?), so, until I managed to catch up, I was teaching my students to write FORTRAN programs in Fortran77. -- Grumpy Ol' Fred cisin(a)xenosoft.com

On Tue, 14 Jan 2025, Van Snyder via cctalk wrote: My courses were SO beginning (first-single semster, no prerequisites) that the differences were relatively unimportant. We had to spend two or three of the eighteen 3 hour lectures on "What is a program?" and how to compile. I had a couple of students with prior college courses in programming, but some of them had never learned anything about what happened between leaving their deck of cards on the ocunter, and picking up output hours or day later. First assignment was "write a program to display YOUR name." Freeform input would indeed be a lot easier for beginners! Formatting the input was a struggle for some. (obviously, only at the very beginning) -- Grumpy Ol' Fred cisin(a)xenosoft.com

On Tue, 2025-01-14 at 22:43 +0000, Chuck Guzis via cctalk wrote: I corresponded with X3J3 starting in about 1980, but had no funding to participate officially. From 1997 until I retired in 2020, I was my employer's representative to J3, as INCITS renamed X3J3 when they took over from CBEMA, and then PL22.3, as they renamed it to correspond to ISO nomenclature. I was also my employer's representative to ISO/IEC JTC1/SC22/WG5. I was liaison from J3/PL22.3 to WG9 (Ada), IEEE P1722 (interval arithmetic), and IFIP WG 2.5 (numerical software), of which I was vice-chair for about five years until I retired. F90 was an extension to F77 and was entirely upwardly compatible with it, not an entirely new language. The most important syntax extension was free-form input to get away from the rigid card-oriented format, but vector operations, dynamic memory, modules, etc. were also very important.  Almost all of F66 and F77 are still present in F2025. The column-1 vertical format control was removed in 2003 because there was no way to detect or specify that it was enabled for a particular file. Assigned GO TO and assigned FORMAT and the ASSIGN statement were removed in 2008. A few things are marked as "obsolescent" with a caveat that they might be removed, but the vendors say "go ahead and remove it, but I still have to compile it forever."

On Wed, 2025-01-15 at 00:32 +0000, Chuck Guzis via cctalk wrote: I have the 1401 FORTRAN-II compiler. I reverse engineered it from operational tapes, then the author (Gary Mokotoff) sent me a scan of his listings, that he thought he lost when he retired. My reverse- engineered code has far more comments. It works in an interesting way: It reads the source code into core, then reads 64 more phases, average about 300 instructions each, until it has object code in core. It has an option to punch an object deck, or just compile-and-go. I recently modified it so they could run it at the Computer History Museum in Mountain View, CA. They have a Tape Adapter Unit (TAU) emulator connected to a PC. It can pretend to be a TAU that they can use to diagnose tape drives, or it can pretend to be a tape drive so they can read and write "tapes" in the PC. But it has a 2,400 character buffer, and some of the blocks were 3,500 characters. It works in SimH i1401, but I don't know whether they've tried on their real 1401s. Its (necessarily decimal) floating point arithmetic was quite good -- up to 20 digits, with two guard digits. The only defect by modern standards was that it didn't do symmetric rounding. The intrinsic function library was small, but also quite good — trig functions, exponential, logarithm, square root. Jay Jaeger has built a 1410 using FPGA, including 1401 compatibility. I haven't kept up with the status so I don't know whether everything works yet. 1401 (and 1410 and 7010) had a "branch if bit equal" instruction and column-binary card reading and punching (both optional on 1401), but nothing more for boolean operations.

On 1/14/25 16:50, Van Snyder via cctalk wrote: I remember running 1620 card FORTRAN. It sounds much like the 1401 version (no surprise). You first read in the compiler, then the source program; an intermediate deck is punched. The second pass of the compiler is then read in, followed by the intermediate deck punched in pass 1, then any subroutine decks. My recollection is that the precision could be specified by the user; integers could be up to 10 digits and floating mantissas could be up to 28 digits in length. An interesting feature was that subroutines were not required to have the same precision as the main program. It was a fairly time-consuming process and program errors set the whole process back to square 1. IBM, realizing the essence of "cumbersome", produced a companion product, called GOTRAN, where the compiler/runtime remained resident and source statements were compiled into an intermediate form and executed interpretively. Of course, execution was slower and the language was simpler (e.g. the FORMAT statement was omitted). --Chuck

On 1/15/25 09:49, Paul Koning wrote: Looked up the latest 1620 FORTRAN reference in the Monitor II-D manual. 10 and 28 for FANDK, so my memory isn't completely gone yet. Always wondered if addition and subtraction on the 1620 had a "shortstop" implementation. For example, adding a 10 digit to a 50 digit number, would the operation stop if there was no carryout after 10 digits, or would the implementation process all 50 digits? --Chuck

On 2025-01-15 5:17 p.m., David Wise via cctalk wrote: I think being dumb is the smart thing to do.

OK, I just wanted to chime in on this retro stuff.  Back in 1996 or so I built a laser photoplotter for making circuit board artwork.  See http://pico-systems.com/photoplot.html for a pic and some info.  The original software was written in Turbo Pascal on a Win 95 system so it could access the DMA card from a user program.  The limited memory under Win95 left the program really cramped for large bitmaps.  So, I moved the program to a Win 2K system and split it in half.  the Win 2K program created a massive bitmap file which I then compressed with zip and shipped to the Win95 computer that then sent it out to the laser.  This worked quite well.  But, about 2014 I was worried that ancient Win 95 system would die, so I converted it to run from a Beagle Bone Black.  Due to the small shared memory between the PRU and the ARM processor, I needed to compress the data.  So, for each raster line, there was a string of 16-bit tokens.  The high bit indicated laser on/off, and the rest of the bits were a 15-bit repeat count.  A token of all zero indicates the end of that raster line.  2 consecutive zero tokens indicates the end of the entire plot. THEN, I hacked up the Win 2K Turbo Pascal for Windows program from 1996 to generate these compressed files and ran it through the Linux FPC (Free Pascal Compiler).  It was designed to handle Borland and DEC Pascal extensions, and does a really nice job of it. Pascal is really sort of a dialect of Algol, so I thought this was somewhat on topic. Jon

My experience of Algol 68 was for my computer programming course in Uni (Hull, 1978). We submitted a pile of cards and got fanfold in return. No contact with the actual run system. ICL 1900 running George iV iirc. On Fri, Jan 17, 2025 at 3:32 PM ben via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote:

On 1/17/25 09:46, Paul Koning via cctalk wrote: I can state certainly that VMS Pascal had separate compilation features, that were VERY similar to Borland's method. Jon

On 2025-01-17 8:46 a.m., Paul Koning wrote: Gadzooks, A PDP running something other than B ^H C. :) Did Burroughs ALGOL, make cleaner software for people that used it? What about FORTRAN users? (I keep wanting to spell FORTAN) Ben.

Burroughs (it's now called Unisys) mainframes and their ALGOL dialect shouldn't be discussed in the past tense, because the current versions of those systems are still being marketed, supported, and used. Burroughs had a variety of mainframe architectures. The one under discussion here has variously been called Large Systems (B6x00/7x00), A Series, and now ClearPath MCP. That product line was derived from the B5000/5500 and has an architecture specifically designed to support ALGOL, including hardware support for dynamically-allocated arrays and call-by-name semantics. Binder is still used, but it never was that common outside of FORTRAN and C applications. For the past 40 years, separate compilation has usually been done by means of dynamically-linked libraries, which are quite efficient. That is also now the most common way to call routines written in other languages, e.g., a COBOL program calling routines in an ALGOL library. FORTRAN and COBOL definitely exist on those machines. COBOL in particular is still used heavily. There was a PL/I compiler for a while, but almost no one used it, and it was discontinued years ago. Other languages are Pascal and C (with a fairly complete POSIX library). There are also a few utility languages, such as a sort generator and WFL, the batch job control language. There is still no assembler. ESPOL did not have anything like C extensions (never mind that it existed before C did). It was basically ALGOL with language extensions to access low-level hardware facilities and handle control words transparently. ESPOL was replaced in the early '80s by a new language, NEWP, which is somewhat Modula-like. All of the system software is written in ALGOL (or one of its variants), and NEWP, with some of the newer stuff in Pascal and C. It's true that the B6700 (early '70s) systems depended heavily on the compiler to restrict access to sensitive capabilities of the system, but that's been tightened up a lot over the years. You never could just sit down and write a program to generate runnable code -- runnable code can only be generated by compilers, and the code file for a compiler must be "blessed" by the system administrator. ESPOL could never be used to write a program that would run under the MCP (the OS). It could only be used to generate standalone programs that had to be booted manually. You could, however, write a procedure (subroutine) in ESPOL and bind it to another program. NEWP can generate runnable programs, but if you use any "unsafe" features of the language, the resulting code file is marked unsafe and requires administrator blessing before it can be run. We just don't have a problem with bad code getting into the modern systems. There is no such thing as anti-virus software for them. A different Paul

OMG :-O Let me then suggest: LisP (List Processing) AlgoL (Algorithmic Language) JavaScript (Pure unadulterated marketing BS. Should have been named something based on "LISP disguised as Java"[1].) NOW you tell me. This is why I prefer LISP./forward-Polish-notation. First you are told what will happen, and then you discover whom it will happen to, As Laurie Anderson would say, it's like a prophecy. Doesn't it? Doesn't it look? [2] (just-kidding (should-have-been it 'ForTran)) [1] https://www.youtube.com/watch?v=e4t672J3PvM [2] https://www.youtube.com/watch?v=n0lShWwy_Oc On Tue, Jan 14, 2025 at 4:33 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org&gt; wrote: > On 1/14/25 15:31, Van Snyder via cctalk wrote: > > > F90 was an extension to F77 and was entirely upwardly compatible with > > it, not an entirely new language. > > IMOHO, the most significant revision of the F77 standard by F90 was > that is was acceptable to spell the last 6 letters of the language in > lower case. (i.e. Fortran). In a way, that broke with the historical > sense of the name. It should have been ForTran. > > > F66 was important in a way, as vendor extensions had gone a bit wild. > (e.g. punch a B in column 1 and the arithmetic operators become boolean. > I think that was a feature in 7090 FMS/IBSYS). > > One defining characteristic of post-1980 languages was the assumption of > a binary radix, as opposed to systems like the 1401 or 7070, which were > decimal and lacked bitwise boolean operations. > > --Chuck > > >

Well, verb order does matter, but I appreciate your point. E.g. in RPN: 1 2 3 * + => 7 1 2 3 + * => 5 On Tue, Jan 14, 2025 at 5:01 PM roger arrick via cctalk < cctalk(a)classiccmp.org&gt; wrote:

Indeed, BNF was created in the Algol 60 language definition (the Revised Report). paul

Interestingly, I moved on from Fortran IV to Algol68; perhaps Fortran II would have been a more compelling offering Martin -----Original Message----- From: ben via cctalk [mailto:cctalk@classiccmp.org] Sent: 13 January 2025 23:27 To: cctalk(a)classiccmp.org Cc: ben &lt;bfranchuk(a)jetnet.ab.ca&gt; Subject: [cctalk] Re: Try Algol 68 on Windows << snippety >> Who needs BNF, we have FORTRAN II :)

Eek. I learned on the THE system at TU Eindhoven. That was an Electrologica X8 system with a very nice OS designed and built by Dijkstra. For input it used Flexowriters to do off-line paper tape punching, in a 6 bit code (puched as 7 bits, one being parity), giving upper and lower case plus assorted special characters. Dijkstra once commented that it was nice to be able to order custom characters on their Flexowriters. So it had the "and" and "or" symbols, a "not" symbol, and non-escaping _ and | characters so you could construct ALGOL keywords by typing, say, _b_e_g_i_n or not-equal as |= . That allowed some non-standard characters, |< and |> for string delimiters for example. ALGOL 68 made the notion of different representations a formal part of the definition, so the Report spoke of "bold" symbols, leaving it up to an implementation to represent those as underlined symbols, "stropped" symbols meaning words enclosed in single quotes, or reserved words. All those were options chosen in various ALGOL 60 compilers but at that time it wasn't a specifically documented thing. paul

On 14/01/2025 19:42, Paul Koning via cctalk wrote: Yeah, I know there were fancy character set machines out there later. Look at APL keyboards, for example. ASCII spoiled all the fun. Baudot, of course, was several domain-specific versions. They didn't even all have the same letter/figure shift code, never mind the same symbols in the same place. You had to just know what the wierdnesses were on any teleprinter that wasn't an original Creed (as supplied by Elliott). I've still got a Baudot ASR33 in the shed, although I might have scavenged it for parts for the ASCII. Mostly common linkage parts on the Baudot - just fewer of them :-)

On 14/01/2025 20:59, Paul Koning via cctalk wrote: It could well be been a 32 - I don't think they're labelled. The thing is that I don't think it's much different from the ASCII 33 inside - it just looks like some of the control rods are missing. I don't think the keyboard is any different. But I don't think I've looked at it for 40 years... This isn't what you'd expect from a pre-ASCII model, unless they were planning ahead. Although thinking about it, it was the most modern Baudot machine in the building so perhaps they were designed together. Not a whole lot of use to me - I kept with a Data Dynamic 390 into the 1980s, which was a 33 in a heavy sound-proof box more suitable for a domestic environment. You couldn't hear it chattering away, but you could feel the rumble throughout the house even though I stood it on foam blocks. Where it remains today.

On 14/01/2025 19:42, Paul Koning via cctalk wrote: Yeah, I know there were fancy character set machines out there later. Look at APL keyboards, for example. ASCII spoiled all the fun. Baudot, of course, was several domain-specific versions. They didn't even all have the same letter/figure shift code, never mind the same symbols in the same place. You had to just know what the wierdnesses were on any teleprinter that wasn't an original Creed (as supplied by Elliott). I've still got a Baudot ASR33 in the shed, although I might have scavenged it for parts for the ASCII. Mostly common linkage parts on the Baudot - just fewer of them :-)

On 13/01/2025 22:19, Bill Gunshannon via cctalk wrote: More like not enough actual memory. You can fit an acceptable basic into a 4K ROM so it will work without a disk drive. Its an interpreter so can do checks as you type it in. Its far easier to learn than Algol. Thats not an 8-bit micro and needed a decent disk to run Algol Dave Dave

On 13/01/2025 23:29, ben via cctalk wrote: Yes but on an emulated IBM Mainframe, not an 8-bit CPU. I ran 4K tape Basic in 8K of RAM. It was enough to have fun. As for BASIC being easer to learn than Algol, well the things that make it a nasty language make it easier to learn. I expect it could be simpler but look at the CDC reference manual:- http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/Algol_68_version_1_Refere… 116 pages of total obfuscate and technical drivel.... and then the SWTPC products 8K basic manual.... https://deramp.com/swtpc.com/BASIC_2/SWTPC_8K_BASIC.pdf 32 pages of mostly plain English... .. remember at this time most people had no idea what a program was..... Dave

Paul Koning via cctalk [2025-01-14 01:42:00]: You'll find a couple here: <https://www.algol60.org/3translators.htm> -- Hilsen Harald

On 14/01/2025 13:56, Peter Corlett via cctalk wrote: As someone in the Atari 68000 camp I'd dispute the idea that 'C' wasn't used. Most of the OS was written in 'C' apart from DAS BOOT, and most of the shrink wrap applications (games being written in assembler, I believe). Originally it used the Alcyon 'C' compiler (whcih I think was produced by Motorola in some way) and it was pretty naff. There was also Lattice, and a couple of Tiny 'C's (I'd have said BCPL with pretensions). Then along came Megamax, which set the standard. You could, of course, cross-compile for Unix System V but internally we ate our own dog food! I defected from Apple to Atari when Uncle Jack "defected" from Commodore. The Apple II was Assembler but I did have a 'C' compiler for it (Aztec). Strangely, in 1984 you were faced with BCPL for developing for the Mac, as only the Lisa had a 'C' cross-compiler and no one could afford a Lisa. Running 'C' on a single system floppy drive wasn't practical (the second external floppy came later).

On 2025-01-16 19:12, Van Snyder via cctalk wrote: There's always going to be someone writing in Fortran. ;-) Looking back the ST got a lot of language support for enthusiasts - probably because it was one of the first affordable home computers with a suitable processor. There were a couple of BASICs around - I remember GFA BASIC was popular and we had one that came from DRI that was awful. And I do remember the Modula 2 - there was a buzz about it at Comdex in 1985 with some people saying it was the answer to the iffy Alcyon 'C' we all had to use, and others asking what Modula 2 was. But GEM was a 'C' operating system and I'm not aware of any mainstream software that didn't use it (except games). A couple of programs I had a hand in (Fastcom and Hyperchart) had a common source deck that compiled for the ST and PC. Not easy given pointers on an 8086, but they were hidden using macros. Yuck.