Algol-68 seemed like a good idea
craftofcoding.wordpress.com
craftofcoding.wordpress.com
Some sample text from the report:
A "nest" is a 'NEST'. The nest "of" a construct is the "NEST" enveloped by the original of that construct, but not by any 'defining LAYER' contained in that original. (The nest of a construct carries a record of all the declarations forming the environment in which that construct is to be interpreted. Those constructs which are contained in a range R, but not in any smaller range contained within R, may be said to comprise a "reach". All constructs in a given reach have the same nest, which is that of the immediately surrounding reach with the addition of one extra "LAYER". The syntax ensures (3.2.1.b, 3.4.1.i,j,k, 3.5.1.e, 5.4.1.1.b) that each 'PROP' (4.8.1.E) or "property" in the extra 'LAYER' is matched by a defining. indicator (4.8.1.a) contained in a definition in that reach.)
They're trying to get hold of the concept of variable scope and lifetime, back when that was a new idea.
They were also trying to invent type theory, which they needed and which didn't exist yet. The first 50 pages of the report are all about the notation they invented to be used in the rest of the report. It's not a very good notation. It's like calculus before Leibniz, when people were trying to use Newton's fluxions.[4] Computer science just didn't have enough widely understood abstractions for people to even talk about this stuff clearly.
[1] https://www.softwarepreservation.org/projects/ALGOL/report/A...
[2] https://www.abebooks.com/servlet/BookDetailsPL?bi=3196204463...
[3] https://www.computinghistory.org.uk/det/8776/A-Very-Informal...
- awkward groping for how to explain things
- none of the words match how we talk about things now
Right now, large language models are in that state. They work, but why they work and why they fail is barely understood. As more systems are developed in that space and adjacent to it, more general understanding may emerge.
- awkward groping for how to explain things
- none of the words match how we talk about things now
Glad to hear it might not be utter incompetence.
Searching the Internet finds some scanned copies of that book.
E.g.
https://www.softwarepreservation.org/projects/ALGOL/book/Lin...
Even if Wirth is the author of some important innovations in programming language design, all his programming languages have been significantly inferior to ALGOL-68. Nevertheless, most of them have been more successful precisely because Wirth has written some simple and clear manuals for them, which were easily understood by any programmer.
The formal description used in the report about ALGOL-68 could have been very useful for implementers, but because the language included a lot of novelties it never had any chance of adoption without having, besides a formal description, an extensive tutorial and rationale of the design, accompanied by many programming examples.
This is very sad, because ALGOL-68 got a lot of things right, which are wrong in most later programming languages, but because of its reputation of being incomprehensible it has been very seldom a source of inspiration for the designers of programming languages, as it would have deserved.
Some popular languages, including C, the Bourne shell and C++, have taken various elements from ALGOL 68, but most of them have been superficial elements, like keywords or details of syntax, instead of taking more important elements.
For instance among the ALGOL 68 elements borrowed by C is the keyword "union", but the unions of C are barely better than the EQUIVALENCE of Fortran, and they are not comparable with the unions of ALGOL 68, which were based on the proposal of John McCarthy and which correspond to what are now more frequently called sum types. The "variant records" of Pascal were also much worse designed by Wirth than the unions introduced earlier in the ALGOL 68 that he had criticized.
I actually quite liked it, finding it easy to translate to / from C and A68, but that was mainly because he only described a subset (incl. nested functions), and didn't even describe REF.
So we got exposed to all of the various FOR/WHILE/DO/OD thing, IF's returning values (used like a C ternary op), etc. Some folks went off and acquired reference books for the language, and explored other areas. I never did as at the time I was comfortable with the K&R C compiler on our dept. unix machines.
The real paint point with A68 there was that the compiler was a batch submission one, took quite some time to run, and the machine doing the work was quite overloaded.
I assume this just refers to a conditional expression?
INT x;
x := IF y < 1 THEN 1 ELSE 2 FI;
There was also a short form available, but we were never actually told that, although some folks found it themselves from reference books.
x := ( y < 1 | 1 | 2 );
COMMENT
Algol 68 program to calculate the Sieve of Eratosthenes
for some upper limit N
COMMENT
PROC eratosthenes = (INT n) []INT:
(
[n]INT sieve;
FOR i TO UPB sieve DO
sieve[i] := i
OD;
INT k = ENTIER sqrt(n);
sieve[1] := 0;
FOR i FROM 2 TO k DO
IF sieve[i] NE 0 THEN
FOR j FROM i*i BY i TO n DO
sieve[j] := 0
OD
FI
OD;
sieve
);
INT n;
print("Upper limit to calculate sieve? ");
read(n);
print((eratosthenes(n), newline))
Syntax-wise, it looks like some mix of Go, C and Python. Nothing at all unusual. It would be pretty easy to learn to program in this, and comfortable too.
[Edit: The blogger later demonstrated a good understanding of the Sieve of Eratosthenes, but still expressed criticism of Algol68: https://craftofcoding.wordpress.com/2021/04/06/algorithm-35-...]
edit: I'm thinking of APL. It looks like it's the same kind of functionality as what the Matlab, R or numpy cohort provides.
Pascal (and its descendants) and Ada (and VHDL) seem closer syntactically to algol 60 than C is (begin/end as block delimiters, no parentheses needed for control structures, := for assignment, etc.) The example code at [1] (using bold keywords) should be understandable to most HN readers 64 years later.
But there is certainly a difference between c-like syntax (java, javascript...) vs. algol-like syntax (pascal, ada, ...)
> BCPL has been rumored to have originally stood for "Bootstrap Cambridge Programming Language", but CPL was never created since development stopped at BCPL, and the acronym was later reinterpreted for the BCPL book.
The descriptions of how the CPL compiler worked (eg Strachey’s paper on GPM, Richards more recent retrospectives) all talk about writing the compiler in CPL and translating it by hand to macro assembly.
I have not yet managed to look at Richards PhD thesis which contains the first draft description of BCPL, which he sketched after working on the CPL compiler and shortly before moving to MIT where he first implemented BCPL.
ALGOL 68 was certainly more readable than C or Pascal, even if it was somewhat more verbose.
A very good feature of ALGOL 68 was that all the syntactic structures were enclosed in brackets, so no ambiguities or editing errors were possible, like in C or ALGOL 60.
Moreover, each syntactic structure had its own pair of brackets, so you did not have the reading difficulties caused by all bracket pairs being the same, like "()" in LISP, "begin" and "end" in Pascal or "{}" in C.
Especially useful is having different bracket pairs for iterations ("do" and "od" in ALGOL 68, renamed as "do" and "done" in the Bourne shell, which sounds better) in comparison with the bracket pairs used for conditional statements ("if" and "fi" in ALGOL 68).
In C and derived languages, even the indentation is not enough to understand the code in many cases, especially when the lines are restricted to 80 characters, when you have a long loop body that cannot be seen inside a single page.
In ALGOL 68, you have distinct closing brackets for each syntactic structure, so it is easy to recognize their meaning.
Using keywords for brackets is more verbose than in C, but much less verbose than using terminating comments. Moreover, now we can use Unicode for program texts, so instead of keywords one could use different pairs of Unicode brackets that are graphically distinct. For instance one can use angular brackets for conditional statements and S-shaped bag delimiter brackets for iterations.
It really is.
> Syntax-wise, it looks like some mix of Go, C and Python. Nothing at all unusual. It would be pretty easy to learn to program in this, and comfortable too.
Or maybe a mix of Pascal, PL/I, and /bin/sh.
In designing the language interpreted by the shell, he has taken several features directly from ALGOL 68.
However he has also done one improvement, renaming the bracket pair keywords "do" and "od" to "do" and "done", responding thus to the criticism of many programmers towards ALGOL 68, that "od" sounds odd.
The operator ENTIER (French for “whole”) takes a REAL operand and likewise yields an INT result, but the yield is the largest integer equal to or less than the operand. Thus ENTIER 2.2 yields 2, ENTIER -2.2 yields -3
In the past, it was customary in the English mathematics texts, especially in the UK, to use the French word for the integer part of a number, because the usage of this function had been borrowed from French mathematicians.
ALGOL 60 had taken many notations from the standard mathematical notation of that time, including operators and function names, so it resembled much more a mathematical text than the American programming languages like Fortran, where the main criterion for designing the syntax was using the restricted character set of the IBM printers, which lacked most mathematical symbols, leading to notations like "*", "/" and "**" for multiplication, division and exponentiation, where ALGOL would use "×", "÷", and "↑".
One interesting thing: the sieve array does not have static bounds, the size of it is an argument. Presumably that means it’s stack-allocated dynamically a la ”alloca” (I doubt it’s heap-allocated, given there’s no freeing of it). C didn’t get that feature until C99 and adding it has been almost universally been seen as a mistake.
I imagine that’s an example of one of the many, many things that makes Algol-68 a pain to implement. Does make it easier for the developer though.
Sure, it was a complex thing in the late 60s/early 70s. Sure, Wirth came up with something simpler. But I'm missing a deeper analysis, especially with a more modern view point where basically any language is at least as complex as Algol 68[0].
> Arguably Wirth’s Algol-W was a better successor to Algol-60
I might not even disagree, but what were the arguments, and how are they holding up?
> and arguably did not have the same connections to industry as the likes of Fortran and Cobol
Sure. But neither did Algol-W or Pascal. And pretty much anything else in the 20th century.
One might almost call it a "blog" if it weren't for the fact that EWD started ~35 years before Frontier NewsPage.
The big problem was that the spec was essentially unreadable.
6-pass compiler for Algol-68 :) The telephone exchange was built on the base of the microcomputer (while developed in USSR/Russia, and ultimately that microcomputer was mostly used by the Russian military, the major customer for the exchange who funded the work at some point was Alcatel) which was like Tandem, only 3 instead of 2 systems in parallel because of low quality of electronics, the CPU was USSR-developed "Samson" [1], a kind of Elbrus offshoot. The exchange software was developed in SDL (Z.100, kind of like Erlang-by-European-commitee-in-1980ies) and compiled into Algol-68 which was compiled into that CPU codes.
[1] (in Russian) https://www.computer-museum.ru/articles/sistemi_kompleksi/90...
One problem with the language is that you can't parse declarations and expressions until after you have parsed the bracket structure of the language (because you can't tell whether a name is a type or an operator until you have processed their declarations (which do not have to be done before use) - that sort of means you have to do at least 2 lexical/parse passes
It was a surprisingly pleasant language to work with considering its age. The main annoyances were:
* Extensible arrays were fiddly to work with (which is understandable given that allocating arrays of arbitrary size barely makes sense on a 1968 computer).
* Formatted IO is weird. I never really understood how it worked and just tweaked examples till I got what I needed.
* No hashtables in the stdlib.
* Available implementations on modern hardware are not production quality.
I'm always inspired when someone (like the author of the Algol 68 compiler you used) decides to make a historically important – but obsolete and generally unavailable – software system usable and available on modern hardware.
I think if I did something like this again I would do it with an old Advent of Code to remove the competitive pressure. It was fun to start with but it ended up stressing me out quite a bit towards the end (which is not ideal over the Christmas vacation).
If you don't constantly have three dozen Requests for Implementation brewing, seven of which are going into the next release, you're a dead project.
There are surely lots of features the proposer would be willing to remove (although one also has to define how to count the number of features, or else every proposal, no matter how long, will be for one giant feature, and will propose removing one tiny feature in return). The problem is that what I consider dispensable in return for my essential proposal will conflict with what the next programmer over considers essential ….
They sound like a good idea "Lets get the best minds together and create the ideal standard" however because they are not based on anything built tend to be over engineered and hard to implement.
At the opposite end of the spectrum is posix, which is a sort of terrible "lets just glob what everyone is doing together" descriptive standard, at least it gets everyone operating on the same page. so I think of it as a good place to start, not the end result.
There is a reason the ieft was so successful with their "working code and rough consensuses". Which is why it worries me as they try to redefine them self as a "standards" body. as opposed to publishing standards.
https://public.support.unisys.com/framework/publicterms.aspx...
UK Navy also had a system programmed on it.
Also it was largely influential in PL/I and its dialects, which were used a bit everywhere, the most well known being PL.8, PL/S and PL/M.
And the competition that eventually lead to the Pascal tree of programming languages.
History would have been much different if Algol 68 hadn't existed in first place.
"History would have been much different if Algol 68 hadn't existed in first place."
Without the way Algol 68 went down, Algol W and the related events that gave birth to Pascal linage would never happened.
Likewise, PL/I adoption linage would most likely taken a different evolution.
* Fortran, Visual Basic, SQL — and even here, the way they've all evolved from their roots has been towards Algol 68.
At least with -fbounds-safety clang is finally catching up with what Pascal (including UCSD, Apple, and Turbo Pascal) and Ada (a rather more complicated descendant of Pascal) compilers had in the 1980s. (Delphi and Free Pascal still have range checking today.)
For me the best version of Oberon linage is Active Oberon, while I appreciate Wirth I think he went too far on his quest for language simplification. Even Go has more features than Oberon -07.
As for Modula-2, it is now a standard language on GCC, otherwise Zig and Odin are relatively similar for the curly bracket folks.
People should stop designing languages for notepad and classical UNIX V6 vi as editor experience.
Casts well, each language has its own nomenclature for type conversions.
Can you fix that problem now? Yes, but the window for Modula-2 closed decades back. It doesn't have any significant selling points now.
The two page spread showing a graph of the implicit type conversions was a masterpiece.
The big problem was that the language spec was incomprehensible (I've done a language implementation), trying to embed syntax and semantics into the one spec - the maths guys went a bit overboard there. The other main problem was trying to solve the reserved word problem by defining effectively multiple fonts/type faces for different parts of the language .... at a time when even lower case wasn't really an option for most people