Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC SC approves inclusion of Algol 68 Front End

gcc.gnu.org

Post reply on HN
Print view View original

51–60 of 115 posts

Re: GCC SC approves inclusion of Algol 68 Front End

#51

Post by SkiFire13 »

FrankenApps wrote: post #38
JoshTriplett wrote: post #35

Earlier quoted context omitted.

> while FOSS influenced by corporate needs is about standardizing around 'blessed' platforms like is happening in Linux distributions with adoption of Rust Rust's target tier support policies aren't based on "corporate needs". They're based, primarily, on having people willing to do the work to support the target on an ongoing basis, and provide the logistics needed to make sure it works. The main difference, I would…

The Rust Community is working on gcc-rs for this very reason.

gcc-rs is far from being usable. If you want to use Rust with gcc-only targets you're probably better off with rustc_codegen_gcc instead.

Re: GCC SC approves inclusion of Algol 68 Front End

#52

Post by jemarch »

MangoToupe wrote: post #5

Where might one look to find examples of such code? I've never found algol outside of wikipedia

You can find some modern Algol 68 code, using the modern stropping which is the default in GCC, at https://git.sr.ht/~jemarch/godcc

Godcc is a command-line interface for Compiler Explorer written in Algol 68.

Re: GCC SC approves inclusion of Algol 68 Front End

#55

Post by pjmlp »

somat wrote: post #24
zik wrote: post #2

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

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).

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

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

Re: GCC SC approves inclusion of Algol 68 Front End

#56

Post by pjmlp »

inkyoto wrote: post #41
adrian_b wrote: post #39

Earlier quoted context omitted.

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 desig…

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.

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

Re: GCC SC approves inclusion of Algol 68 Front End

#58

Post by pjmlp »

uecker wrote: post #37
ofalkaed wrote: post #22

Earlier quoted context omitted.

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 t…

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?

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

Re: GCC SC approves inclusion of Algol 68 Front End

#59

Post by jemarch »

gldrk wrote: post #31
0xpgm wrote: post #23

In my mind this highlights something I've been thinking about, the differences between FOSS influenced by corporate needs vs FOSS driven by the hacker community. FOSS driven by hackers is about increasing and maintaining support (old and new hardware, languages etc..) while FOSS influenced by corporate needs is about standardizing around 'blessed' platforms like is happening in Linux distributions with adoption of Ru…

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.

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/

Re: GCC SC approves inclusion of Algol 68 Front End

#60

Post by bhaak »

uecker wrote: post #36
JoshTriplett wrote: post #35

Earlier quoted context omitted.

> while FOSS influenced by corporate needs is about standardizing around 'blessed' platforms like is happening in Linux distributions with adoption of Rust Rust's target tier support policies aren't based on "corporate needs". They're based, primarily, on having people willing to do the work to support the target on an ongoing basis, and provide the logistics needed to make sure it works. The main difference, I would…

The issue is that certain specific parts of the industry currently pour in a lot of money into the Rust ecosystem, but selectively only where they need it.

How is that different than scratching one’s own itch?
Post reply on HN