[zik]

As a fan of Algol 68, I'm pretty excited for this.

For people who aren't familiar with the language, pretty much all modern languages are descended from Algol 60 or Algol 68. C descends from Algol 60, so pretty much every popular modern language derives from Algol in some way [1].

[1] https://ballingt.com/assets/prog_lang_poster.png

[somat]

Yes, massively influential, but was it ever used or popular?, I always think of it as sort of the poster child for the danger of "design by committee".

Sure it's ideas spawned many of today's languages, But wasn't that because at the time nobody could afford to actually implement the spec. So we ended up with a ton of "algols buts" (like algol but can actually be implemented and runs on real hardware).

[pjmlp]

Yes, for example UK navy had a system developed in Algol 68 subset.

https://academic.oup.com/comjnl/article-abstract/22/2/114/42...

[dboreham]

Used extensively on Burroughs mainframes.

[somat]

Wow, The Burroughs large system had special instructions explicitly for efficient algol use. You could almost say it was algol hardware. but algol 60 not 68.

https://en.wikipedia.org/wiki/Burroughs_Large_Systems

There is a large system emulator that runs in a browser, I did not get any algol written but I did have way to much fun going through the boot sequence.

https://www.phkimpel.us/B5500/webUI/B5500Console.html

[Taniwha]

Burroughs used an Algol60 derivative (not '68)

[pjmlp]

ESPOL initially, which evolved into NEWP.

[Taniwha]

ESPOL was (is?) simply a version of the standard Algol compiler that let you do 'system' sorts of things.

The Burroughs large systems architecture didn't really protect you from yourself, system security/integrity depended on only letting code from vetted compilers run (only a compiler could make a code file, and only a privileged person could make a program a compiler) - so the Algol 60 compiler made code that was safe, Espol could make code that wasn't, could do things a normal user couldn't - you kept the espol compiler somewhere safe away from the students ....

(there was a well known hole in this whole thing involving mag tapes)

[pjmlp]

As mentioned it evolved into NEWP, and you can get all the manuals from Unisys, as they keep selling it.

Given its architecture, it is sold for batch processing systems where security is paramount.

Yes, ESPOL and NEWP, being one of the first systems languages with UNSAFE code blocks, a binary that is compiled having unsafe is tainted and requires administrator configuration before being allowed to execute by the system.

One cannot just compile such code and execute it right away.

[Taniwha]

I would argue C comes from Algol68 (structs, unions, pointers, a full type system etc, no call by name) rather than Algol60

[adrian_b]

C had 3 major sources, B (derived from BCPL, which had been derived from CPL, which had been derived from ALGOL 60), IBM PL/I and ALGOL 68.

Structs come from PL/I, not from ALGOL 68, together with the postfix operators "." and "->". The term "pointer" also comes from PL/I, the corresponding term in ALGOL 68 was "reference". The prefix operator "*" is a mistake peculiar to C, acknowledged later by the C language designers, it should have been a postfix operator, like in Euler and Pascal.

Examples of things that come from ALGOL 68 are unions (unfortunately C unions lack most useful features of the ALGOL 68 unions. which are implicitly tagged unions) and the combined operation-assignment operators, e.g. "+=" or "*=".

The Bourne shell scripting language, inherited by ksh, bash, zsh etc., also has many features taken from ALGOL 68.

The explicit "malloc" and "free" also come from PL/I. ALGOL 68 is normally implemented with a garbage collector.

[Taniwha]

C originally had =+ and =- (upto and including Unix V6) - they were ambiguous (a=-b means a= -b? or a = a-b?) and replaced by +=/-=

The original structs were pretty bad too - field names had their own address space and could sort of be used with any pointer which sort of allowed you to make tacky unions) we didn't get a real type system until the late 80s

[adrian_b]

ALGOL 68 had "=" for equality and ":=" for assignment, like ALGOL 60.

Therefore the operation with assignment operators were like "+:=".

The initial syntax of C was indeed weird and it was caused by the way how their original parser in their first C compiler happened to be written and rewritten, the later form of the assignment operators was closer to their source from ALGOL 68.

[ErikCorry]

Yeah if you ever wondered why the fields in a lot of Posix APIs have names with prefixes like tm_sec and tm_usec it's because of this misfeature of early C.

[themafia]

> it should have been a postfix operator, like in Euler and Pascal.

I never liked Pascal style Pointer^. As the postfix starts to get visually cumbersome with more than one layer of Indirection^^. Especially when combined with other postfix Operators^^.AndMethods. Or even just Operator^ := Assignment.

I also think it's the natural inverse of the "address-of" prefix operator. So we have "take the address of this value" and "look through the address to retreive the value."

[adrian_b]

The "natural inverse" relationship between "address-of" and indirect addressing is only partial.

You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless.

Moreover, in complex expressions it is common to mix the indirection operator with array indexing and with structure member selection, and all these 3 postfix operators can appear an unlimited number of times in an expression.

Writing such addressing expressions in C is extremely cumbersome, because they require a great number of parentheses levels and it is still difficult to see which is the order in which they are applied.

With a postfix indirection operator no parentheses are needed and all addressing operators are executed in the order in which they are written.

So it is beyond reasonable doubt that a prefix "*" is a mistake.

The only reason why they have chosen "*" as prefix in C, which they later regretted, was because it seemed easier to define the expressions "*++p" and "*p++" to have the desired order of evaluation.

There is no other use case where a prefix "*" simplifies anything and for the postfix and prefix increment and decrement it would have been possible to find other ways to avoid parentheses and even if they were used with parentheses that would still have been simpler than when you have to mix "*" with array indexing and with structure member selection. Moreover, the use of "++" and "--" with pointers was only a workaround for a dumb compiler, which could not determine by itself whether it should access an array using indices or pointers. Normally there should be no need to expose such an implementation detail in a high-level language, the compiler should choose the addressing modes that are optimal for the target CPU, not the programmer. On some CPUs, including the Intel/AMD CPUs, accessing arrays by incrementing pointers, like in the old C programs, is usually worse than accessing the arrays through indices (because on such CPUs the loop counter can be reused as an index register, regardless of the order in which the array is accessed, including for accessing multiple arrays, avoiding the use of extra registers and reducing the number of executed instructions).

With a postfix "*", the operator "->" would have been superfluous. It has been added to C only to avoid some of the most frequent cases when a prefix "*" leads to ugly syntax.

[themafia]

> You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless.

This is due to the nature of lvalue and rvalue expressions. You can only get an object where * is meaningful twice if you've applied & meaningfully twice before.

    int a = 42;
    int *b = &a;
    int **c = &b;

I've applied & twice. I merely had to negotiate with the language instead of the parser to do so.

> and all these 3 postfix operators can appear an unlimited number of times in an expression.

In those cases the operator is immediately followed by a non-operator token. I cannot meaningfully write a[][1], or b..field.

> The only reason why they have chosen "*" as prefix in C, which they later regretted, was because it seemed easier to define the expressions "++p" and "p++" to have the desired order of evaluation.

It not only seems easier it is easier. What you sacrifice is complications is defining function pointers. One is far more common than the other. I think they got it right.

> With a postfix "*", the operator "->" would have been superfluous.

Precisely the reason I dislike the Pascal**.Style. Go offers a better mechanism anyways. Just use "." and let the language work out what that means based on types.

I'm offering a subjective point of view. I don't like the way that looks or reads or mentally parses. I'm much happier to occasionally struggle with function pointers.

[LeFantome]

I do not think that is what they meant.

**c is valid but &&b makes no sense.

[inkyoto]

> The only reason why they have chosen "" as prefix in C, which they later regretted, was because it seemed easier to define the expressions "++p" and "*p++" to have the desired order of evaluation.

There has been no shortage of speculation, much of it needlessly elaborate. The reality, however, appears far simpler – the prefix pointer notation had already been present in B and its predecessor, BCPL[0]. It was not invented anew, merely borrowed – or, more accurately, inherited.

The common lore often attributes this syntactic feature to the influence of the PDP-11 ISA. That claim, whilst not entirely baseless, is at best a partial truth. The PDP-11 did support pre-increment and post-increment indirect address manipulation – but notably lacked their symmetrical complements: pre-increment and post-decrement addressing modes[1]. In other words, it exhibited asymmetry – a gap that undermines the argument for direct PDP-11 ISA inheritance, i.e.

  MOV (Rn)+, Rm

  MOV @(Rn)+, Rm

  MOV -(Rn), Rm

  MOV @-(Rn), Rm

existed but not

  MOV +(Rn), Rm

  MOV @+(Rn), Rm

  MOV (Rn)-, Rm

  MOV @(Rn)-, Rm

[0] https://www.thinkage.ca/gcos/expl/b/manu/manu.html#Section6_...

[1] PDP-11 ISA allocates 3 bits for the addressing mode (register / Rn, indirect register (Rn), auto post-increment indirect / (Rn)+ , auto post-increment deferred / @(Rn)+, auto pre-decrement indirect / -(Rn), auto pre-increment deferred / @-(Rn), index / idx(Rn) and index deferred / @idx(Rn) ), and whether it was actually «let's choose these eight modes» or «we also wanted pre-increment and post-decrement but ran out of bits» is a matter of historical debate.

[adrian_b]

The prefix "*" and the increment/decrement operators have been indeed introduced in the B language (in 1969, before the launch of PDP-11 in 1970, but earlier computers had some autoincrement/autodecrement facilities, though not as complete as in the B language), where "*" has been made prefix for the reason that I have already explained.

The prefix "*" WAS NOT inherited from BCPL, it was purely a B invention due to Ken Thompson.

In BCPL, "*" was actually a postfix operator that was used for array indexing. It was not the operator for indirection.

In CPL, the predecessor of BCPL, there was no indirection operator, because indirection through a pointer was implicit, based on the type of the variable. Instead of an indirection operator, there were different kinds of assignment operators, to enable the assignment of a value to the pointer, instead of assigning to the variable pointed by the pointer, which was the default meaning.

BCPL has made many changes in the syntax of CPL, whose main reason was the necessity of adapting the language to the impoverished character set available on American computers, which lacked many of the characters that had been available in Europe before IBM and a few other US vendors have succeeded to replace the local vendors, also imposing thus the EBCDIC and later the ASCII character sets.

Several of the changes done between BCPL and B had the same kind of reason, i.e. they were needed to transition the language from an older character set to the then new ASCII character set. For instance the use of braces as block delimiters was prompted by their addition into ASCII, as they were not available in the previous character set.

The link that you have provided to a manual of the B language is not useful for historical discussions, as the manual is for a modernized version of B, which contains some features back-ported from C.

There is a manual of the B language dated 1972-01-07, which predates the C language, and which can be found on the Web. Even that version might have already included some changes from the original B language of 1969.

[zozbot234]

A postfix "*" would be completely redundant since you can just use p[0] . Instead of *p++ you'd have (p++)[0] - still quite workable.

[fastaguy88]

You're kidding, right? (p++)[0] returns the contents of (p) before the ++. Its hard to imagine a more confusing juxtaposition.

[psychoslave]

A dash instead of a dot would be so much more congruent with the way Latin script generally render compounded terms. And a reference/pointer (or even pin for short) is really nothing that much different compared to any other function/operator/method.

some·object-pin-pin-pin-transform is not harder to parse nor to interpret as human than (***some_object)->transform().

[inkyoto]

C's «static» and «auto» also come from PL/I. Even though «auto» has never been used in C, it has found its place in C++.

C also had a reserved keyword, «entry», which had never been used before eventually being relinquished from its keyword status when the standardisation of C began.

[pjmlp]

C23 also has reused auto as C++, although type inference is more limited.

[inkyoto]

That is indeed correct. Kernighan in his original book on C cited Algol 68 as a major influence.

[j2kun]

> I'm pretty excited for this

Aside from historical interest, why are you excited for it?

[ofalkaed]

Personally, I think the whole C tangent was a misstep and would love to see Algo 68 turn into Algo 26 or 27. I sort of like C and C++ and many other languages which came, but they have issues. I think Algo 68 could develop into something better than C++, it has some of the pieces already in place.

Admittedly, every language I really enjoy and get along with is one of those languages that produced little compared to the likes of C (APL, Tcl/Tk, Forth), and as a hobbyist I have no real stake in the game.

[uecker]

I wonder about what you think is wrong with C? C is essentially a much simplified subset of ALGOL68. So what is missing in C?

[pjmlp]

Proper strings and arrays for starters, instead of being pointers that the programmer is responsible for doing length housekeeping.

[uecker]

Arrays are not pointers and if you do not let them decay to one, they do preserve the length information.

[pjmlp]

They surely behave like one as soon as they leave local scope.

Kind of hard when passing them around as funcion parameters, and the static trick doesn't really work in a portable way.

Lets seen how far WG14 gets with cybersecurity laws with this kind of answers being analysed by SecDevOps and Infosec experts.

[ordu]

    int arr[4];
    foo(arr);

We can look at this code like it passes an array by reference, but how to pass `arr` by value?

[ofalkaed]

I think what C is missing is everything that people fall back onto clever use of pointers and macros to implement. Not that I think C should have all those things, Zig does a decent job of showing alternatives.

[uecker]

Yeah, but I meant specifically from ALGOL68.

[ofalkaed]

I don't think C is missing anything from Algol 68, but, FLEX and slices would be nice, although Algol's slices are fairly limited but even its limited slices are better than what C offers. Algol 68 operators are amazing but I don't see them playing well with C.

[inkyoto]

Whilst I think that C has its place, my personal choice of Algol 26 or 27 would be CLU – a highly influential, yet little known and underrated Algol inspired language. CLU is also very approachable and pretty compact.

[GhosT078]

Consider exploring Ada 2022 as a capable successor to Algol. Its well supported in GCC and scales well from very small to very large projects. Some information is at https://learn.adacore.com/ and https://alire.ada.dev/

[Y_Y]

Is like to order a complementary question to the sibling one. What are you going to add to (/remove from?) Algol 68 to get Algol 26?

[ofalkaed]

That task would be beyond my skills, as I said, I am just a hobbyist. I think it would be interesting to see what would result from going back to one of those early foundational languages and developing a modern language from it. With a language like Algol we don't have the decades of evolution (baggage) which are a big part of languages like C and C++ and trickle into the languages they inspired even if they are trying to remove that baggage. So, what would we get if we went back to the start and built a modern language off of Algol? What would that look like?

[vintagedave]

Wouldn't that be some form of Pascal?

[zik]

I've actually been toying with writing an Algol 68 compiler myself for a while.

While I doubt I'll do any major development in it, I'll definitely have a play with it, just to revisit old memories and remind myself of its many innovations.

[nine_k]

If PL/I was like a C++ of the time, Algol-68 was probably comparable to a Scala of the time. A number of mind-boggling ideas (for the time), complexity, an array of kitchen sinks.

[int_19h]

It certainly has quite a reputation, but I suspect it has more to do with dense formalism that was quite unlike everything else. The language itself is actually surprisingly nice for its time, very orthogonal and composable.

[dhosek]

Finally.