GCC SC approves inclusion of Algol 68 Front End

Original Article ↗ Hacker News Discussion ↗

Excitement and Purpose of Algol 68 in GCC

  • Many are pleased to see an official GCC front end, mainly for historical interest and as an easier way to “play with” Algol 68 today.
  • Some hope it could be a base for a modern “Algol 2x” language free of C/C++’s accumulated baggage.
  • Others question its practical value beyond nostalgia, noting it won’t suddenly become a mainstream development language.
  • The GNU Algol 68 maintainers note they are adding GNU extensions as a strict super‑language, as explicitly allowed by the Revised Report.

Algol 68, C, and Language Design Debates

  • Several comments stress Algol 68’s influence: C is seen by some as closer to Algol 68 than Algol 60, with PL/I and BCPL also important ancestors.
  • Discussion of what C “misses” from Algol 68: proper first‑class strings/arrays, slices/FLEX, richer unions, and more powerful operators.
  • Others argue C already has proper arrays if you avoid decay, and that its real problems lie elsewhere (overreliance on macros, clever pointer tricks).
  • There’s interest in alternative “Algol descendants” such as CLU, Ada 2022, and Pascal‑like languages.

Pointers, Arrays, and Operator Syntax in C

  • Long subthread on C array decay, static array parameters, and security:
    • Examples show how to preserve array length in function signatures, but concerns remain that compilers only warn, not error.
    • Some argue ignoring warnings is analogous to abusing unsafe in other languages; tools exist but can be misused.
  • Another subthread debates prefix * vs postfix indirection:
    • One side calls prefix * a historical mistake that complicates complex expressions and forces ->.
    • The other prefers symmetry with &, accepts complexity around function pointers, and dislikes Pascal‑style postfix dereference.
    • Historical lineage (CPL/BCPL/B, PDP‑11, early manuals) is argued in detail, with requests for better sourcing.

Historical Use and Code Availability

  • Skepticism about whether Algol 68 was ever widely used; counterexamples include Burroughs systems (mostly Algol 60 derivatives) and at least one UK Navy system based on an Algol 68 subset.
  • Pointers to modern examples: RosettaCode, GitHub repositories, and an Algol 68 tool (godcc). One commenter claims there’s “no interesting code”, others object that “interest” is subjective.
  • Tutorials/resources: the “Informal Introduction to Algol 68” and algol68‑lang.org are recommended.
  • A question about whether GNU Algol 68 uses a garbage collector is raised but not answered in the thread (status: unclear).

GCC Frontends, Go, Rust, and FOSS Dynamics

  • Observation that recent GCC front ends are Algol 68 and COBOL, while LLVM has attracted newer languages (Swift, Zig, Rust, Julia).
  • gccgo: once tracked upstream Go closely but is now stuck at Go 1.18 without generics; reasons speculated include generics complexity and loss of key maintainers.
  • Some value gccgo for its C‑like ABI and low FFI overhead compared to standard Go’s cgo; others note newer Go versions have reduced FFI costs.
  • Concern that GCC language front ends without strong communities (gcj, gccgo, potentially gcc‑rs) risk stagnation.
  • Broader discussion on corporate vs “hacker” FOSS:
    • One view: hacker‑driven projects preserve old hardware/languages; corporate‑driven efforts converge on “blessed” platforms (e.g., Rust support affecting which architectures remain viable).
    • Another view: corporate users also need long‑term support for weird old systems; the main limit is maintainers, hardware access, and demand.
    • Rust’s tiered target support is cited as being driven by available maintainers/logistics rather than purely by corporate needs, though corporate funding shapes which gaps get filled.

Semantics: Call‑by‑Name, Proceduring, and Knuth’s Test

  • Some enthusiasm for Algol 60’s call‑by‑name; clarification that Algol 68 instead uses “proceduring” (wrapping expressions as nullary procedures), which can emulate some behaviors but with more explicit cost.
  • Knuth’s “Man or Boy” test is discussed:
    • The original is for Algol 60; Algol 68’s different semantics mean the GCC front end isn’t expected to pass it as‑is.
    • A C++ translation using std::function and lambdas is provided to illustrate how self‑referential, higher‑order procedures behave.