Comment by gldrk

25 days ago

The big difference is that Algol 68 is set in stone. This is what allows a single dedicated person to write the initial code and for it to keep working essentially forever with only minor changes. The Rust frontend will inevitably become obsolete without active development.

Algol 68 isn’t any more useful than obsolete Rust, however.

2 comments

gldrk

jemarch 25 days ago

The core Algol 68 language is indeed set in stone.

But we are carefully adding many GNU extensions to the language, as was explicitly allowed by the Revised Report:

  [RR page 52]
  "[...] a superlanguage of ALGOL 68 might be defined by additions to
   the syntax, semantics or standard-prelude, so as to improve
   efficiency or to permit the solution of problems not readily
   amenable to ALGOL 68."

The resulting language, which we call GNU Algol 68, is a strict super-language of Algol 68.

You can find the extensions currently implemented by GCC listed at https://algol68-lang.org/

dfawcus 24 days ago
I had a small programming task a while ago, and decided to try doing it algol68 (using the algol68 genie interpreter) simply because I'd had some exposure to the language many years ago at Uni.
It was an AWK like task, but I decided up front it was too much trouble to do in AWK, as I needed to build a graph of data structures from the input data.
In part the program had an AWK like pattern matching and processing section, which wasn't too awkward. I found having to use REF's more trouble that dealing with pointers, in part due to the forms of auto dereferencing the language uses; but that was expected.
The real problem though was that I ended up needing something like a map / hash-table, and I concluded it was too much trouble to write from scratch.
So in the end I switched the program to be written in Go.
That then suggests a few things to me:
- it should have an extension library (prelude) offering some form of hash table. - it would be useful to add syntax for explicit pointers (PTR keyword) which are not automatically dereferenced when used. - maybe have with either something like the Go (or Zig) style syntax for selecting a member of a pointed to struct (a.b) and maybe Zig like explicit defer (ptr.\*).
That latter pointer suggestions because I found the "field OF struct" form too verbose, and especially confusing when juggling REFs which may or may not get auto dereferenced.