There are many things that got taken from Algol, but it's also important to distinguish Algol-60 and Algol-68. Although some things from the former were still in the latter, they have little in common.
Algol-60 gave us:
- semicolons as statement terminators
- begin/end
- chain assignment (a := b := c)
- conditional expressions (like ?: in C)
- the "type name;" variable declaration syntax.
- while loops (technically both "while" and "for" were syntactic elements of a single loop structure, and could be combined)
Algol-68 mostly influenced other languages via C, which appropriated quite a few of its keywords: void; struct; union; long and short (in A68, you could chain arbitrarily many "long" and "short" before "int" or "real" - the implementations were required to distinguish short int / int / long int, but additional modifiers could be used in an implementation-defined way to designate larger or smaller types if an implementation chose to provide them - if there was a need for 128-bit ints, for example, they'd be "long long long int"). Abbreviated type names as well: int, char, bool all come from A68. Also, compound assignment like += and -= (except it was +:= and -:=), and the notion of assignments as expressions yielding the assigned value.
Go arguably takes the consistently left-to-right composite type syntax from A68: arrays were declared as e.g. [0:9]int, although variable name still followed type. Something like "ref []bool x" would mean "x is a pointer to an array of Booleans".
Regarding := specifically, it was an assignment operator in Algol-60 (and thence in Pascal language family). In Algol-68, you would use = to initialize an immutable variable in a declaration, and := to assign to them if they are mutable, while Go is the reverse.
Bourne shell took reversed-spelling terminator keywords like "fi", "od", "esac" etc from A68.
C++ seems to have gotten its operator overloading from A68.
It's very interesting to read both specs today. Even Algol-60 was amazingly powerful in some respects - it already had nested functions closing over outer function's variables, and functions passed as arguments, for example (although they weren't first-class, since you couldn't return functions). Then there was crazy stuff like call-by-name, computed gotos, and passing labels as arguments (to which the callee could then goto across stack frames! basically, setjmp/longjmp as an intrinsic language feature). It can be an interesting exercise to try to devise an efficient implementation of all this stuff.
And Algol-68 pretty much reads as a modern programming language, except for some weird terminology that they invented just for it that didn't get adopted by the industry - e.g. "transput" for input and output, or "mode" for types. From modern perspective, it's hard to understand why it was considered overcomplicated in its day, but it makes more sense when you look at its competitors at the time. The most funky thing about it from modern perspective is that pointers were implicitly dereferenced, and so it needed to have a bunch of extra operators to disambiguate things (e.g. "=" for value equality with implicit dereferencing, and "is" for pointer equality).
Here are the actual reports, for those curious. This one is for Algol-60, as revised in 1963 (there was a later "modified report" in 1975, which codified a bunch of extensions and features standardized elsewhere - but reading the original reports is more interesting given the historical context):
>> Bourne shell took reversed-spelling terminator keywords like "fi", "od", "esac" etc from A68. <<
One difference between Bourne shell and Algol 68 is that Bourne uses “done” instead of “od”, because “od” was already used by the octal dump command! The Bournegol source used DO-OD though - https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd...
> ... pointers were implicitly dereferenced, and so it needed to have a bunch of extra operators to disambiguate things
Funny as it has always annoyed me that static objects and dynamic objects used different syntax (a.b vs a->b) so that if you ever changed one, you'd have to go edit ALL uses. It would IMO have made sense to have a->b work for both (better still "a.b" if the syntax could be worked out).
I didn't mean implicit dereference on member access, but rather implicit dereference in most non-pointer contexts. For example, suppose you have:
INT x := 0
REF INT p := x
p is a pointer here ("name" in Algol-68 parlance). Now if I want to read x via p, I can just write something like:
p + 1
No dereference operator - because + is not defined for names, the implicit dereferencing is applied (it works for multiple levels, too - REF REF INT would have been dereferenced twice).
On the other hand, the left side of := does not implicitly dereference; instead, it requires the operand to be a REF, and rebinds it. So I could do:
INT y := 1
p := y
and now p references y instead of x. If I wanted to actually mutate x, I'd have to dereference explicitly on the left side, which you do by casting, removing as many REFs as needed.
It all is actually somewhat more consistent than C, in that in C, they had to come up with that whole "value category" thing for expressions - lvalue, rvalue etc - that is orthogonal to its type. E.g. if you have "int x", the reason why you can use x on the left side of assignment is because it's an lvalue, while something like 123 is an rvalue; but the type is just int for both. In Algol, this is reflected in the type - when you say:
INT x := 1
this is actually syntactic sugar for:
LOC INT x := 1
which is in turn sugar for:
REF INT x = (LOC INT := 1)
where LOC is an operator that's kinda like a typed version of alloca() - i.e. LOC INT returns a value of type REF INT that is allocated on the stack (there's also HEAP, which is the equivalent of C++ "new", but garbage-collected). So all mutable variables actually have type REF T, and := requires the left operand to be a REF (and changes what it refers to).
OTOH if you write something like this:
INT x = 1
then x is just a binding, not a name; its type is just INT; and therefore it does not have a valid type for the left operand of assignment. Which means that technically all variables in Algol-68 are immutable - it's just that some of them can be bound to values that are names, and the name can then made to reference a different value.
I'd say that Algol 68's greatest influence is probably "void", given how often C, C++, Java and C# developers have to write that keyword to this day. ~
