| ▲ | GCC SC approves inclusion of Algol 68 Front End(gcc.gnu.org) |
| 123 points by edelsohn 8 hours ago | 43 comments |
| |
|
| ▲ | 0xpgm 5 hours ago | parent | next [-] |
| 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 Rust (architectures unsupported by Rust lose support). |
| |
| ▲ | JoshTriplett 3 hours ago | parent | next [-] | | > 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 say, is that many projects essentially provide the equivalent of Rust's "tier 3" ("the code is there, it might even work") without documenting it as such. | | |
| ▲ | uecker 3 hours ago | parent | next [-] | | 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. | |
| ▲ | FrankenApps 2 hours ago | parent | prev [-] | | The Rust Community is working on gcc-rs for this very reason. |
| |
| ▲ | gldrk 4 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | keepamovin 4 hours ago | parent | prev | next [-] | | It's funny, I have a different view. Corporates often need LT maintenance and support for weird old systems. The majority of global programming community often chases shiny new trends in their personal tinkering. However I think there's the retro-computing, and other hobby niches that align with your hacker view. And certainly there's a bunch of corp enthusiasm for standardizing shiny things. | | |
| ▲ | uecker 3 hours ago | parent [-] | | I think you both are partially right. In fact, the friction I see are where the industry relies on the open-source community for maintenance but then pushes through certain changes they think they need, even if this alienates part of the community. |
| |
| ▲ | fithisux 3 hours ago | parent | prev [-] | | You nailed it. I am in the process in my spare time to maintain old Win32 apps, that corporates and always-the-latest-and-greatest crowd has abandoned. Most people don't care about our history, only what is shiny. It is sad! |
|
|
| ▲ | zik 8 hours ago | parent | prev | next [-] |
| 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 5 hours ago | parent | next [-] | | 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). | | | |
| ▲ | nine_k 7 hours ago | parent | prev | next [-] | | 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 7 hours ago | parent [-] | | 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. |
| |
| ▲ | Taniwha 5 hours ago | parent | prev | next [-] | | I would argue C comes from Algol68 (structs, unions, pointers, a full type system etc, no call by name) rather than Algol60 | | |
| ▲ | adrian_b an hour ago | parent | next [-] | | 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 16 minutes ago | parent | next [-] | | 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 | |
| ▲ | themafia an hour ago | parent | prev | next [-] | | > 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 24 minutes ago | parent [-] | | 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. |
| |
| ▲ | inkyoto 36 minutes ago | parent | prev [-] | | 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. |
| |
| ▲ | inkyoto 5 hours ago | parent | prev [-] | | That is indeed correct. Kernighan in his original book on C cited Algol 68 as a major influence. |
| |
| ▲ | j2kun 6 hours ago | parent | prev | next [-] | | > I'm pretty excited for this Aside from historical interest, why are you excited for it? | | |
| ▲ | ofalkaed 5 hours ago | parent | next [-] | | 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. | | |
| ▲ | Y_Y 30 minutes ago | parent | next [-] | | 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? | |
| ▲ | uecker 3 hours ago | parent | prev | next [-] | | 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? | |
| ▲ | inkyoto 5 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | zik 6 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | dhosek 8 hours ago | parent | prev [-] | | Finally. |
|
|
| ▲ | pjmlp 4 hours ago | parent | prev | next [-] |
| I find this great, finally an easy way to play with ALGOL 68, beyond the few systems that made use of it, like the UK Navy project at the time. Ironically, Algol 68 and Modula-2 are getting more contributions than Go, on GCC frontends, which seems stuck in version 1.18, in a situation similar to gcj. Either way, today is for Algol's celebration. |
|
| ▲ | NooneAtAll3 6 hours ago | parent | prev | next [-] |
| any algol tutorial recommendations? just to feel what's it all about |
|
| ▲ | Onavo 8 hours ago | parent | prev | next [-] |
| They can just fork off the Golang frontend and it would be the same, maybe patch the runtime a bit. |
| |
| ▲ | pjmlp 4 hours ago | parent | next [-] | | Being an old dog, as I mention elsewhere, I see a pattern with gcj. GCC has some rules to add, and keep frontends on the main compiler, instead of additional branches, e.g. GNU Pascal never got added. So if there is no value with maintenance effort, the GCC steering will eventually discuss this. | |
| ▲ | MangoToupe 7 hours ago | parent | prev [-] | | Does gcc even support go? | | |
| ▲ | wahern 7 hours ago | parent | next [-] | | Until a few years ago, gccgo was well maintained and trailed the main Go compiler by 1 or 2 releases, depending on how the release schedules aligned. Having a second compiler was considered an important feature. Currently, the latest supported Go version is 1.18, but without Generics support. I don't know if it's a coincidence, but porting Generics to gccgo may have been a hurdle that broke the cadence. | | |
| ▲ | ratmice 6 hours ago | parent [-] | | Seems doubtful, given that generics and the gccgo compiler were both spearheaded by Ian Lance Taylor, it seems more likely to me that him leaving google would be a more likely suspect, but I don't track go. | | |
| |
| ▲ | ameliaquining 7 hours ago | parent | prev [-] | | Yes, though language support runs behind the main Go compiler. https://go.dev/doc/install/gccgo |
|
|
|
| ▲ | lanstin 5 hours ago | parent | prev | next [-] |
| Wow that is cool. Pass by name. I always wanted to try it. |
| |
| ▲ | Taniwha 11 minutes ago | parent | next [-] | | Algol60 had call by name, Algol68 doesn't really, it does have "proceduring" which creates a function to call when you pass an expression to a parameter that's a function pointer that has no parameters, you can use that to sort of do something like call by name but the expense is more obvious | |
| ▲ | Y_Y 24 minutes ago | parent | prev [-] | | Just pass a string and `eval` it. |
|
|
| ▲ | MangoToupe 7 hours ago | parent | prev [-] |
| Where might one look to find examples of such code? I've never found algol outside of wikipedia |
| |
