On Tue, 2025-10-21 at 22:32 +0200, Jose E. Marchesi via Gcc wrote: > > Hello Steering Committee! > > Back in January a WIP patch series incorporating an Algol 68 Front- > End > [1] to GCC was sent to gcc-patches. Shortly after, in February, a > request to the Steering Committee was made to consider officially > accepting the Front-End in GCC, if perhaps a bit prematurely. The SC > decided to not merge the front-end at that time, the reasons for > rejection being a) a concern about the potential additional > maintenance > and development burden of having the incipient front-end in a release > of > GCC and b) a cost-benefit analysis that somehow resulted as > non-favorable towards Algol 68. > > So we did no make it to GCC 15. > > We were allowed, however, to use a branch in the GCC forge and to use > the project's wiki and other resources. This has allowed us to > continue > working on the Front-End off-tree, completing the language support, > fixing many bugs, improving the integration, adding tests, writing > the > user and internals manual and designing and implementing several GNU > extensions to the language. > > The result of this work has been sent to gcc-patches as a series of > 47 > patches, the last iteration of which can be found at [2]. In this > last > iteration all the patches touching any sort of common code were > approved > by either a global reviewer or the corresponding area maintainer, of > course subjected to SC approval. > > We have also added support for ga68 to other tools so we can have a > working complete environment environment. This includes autoconf, > automake, Emacs and compiler explorer. The compiler is also already > packaged by some distros, pulling from the off-tree branches we > maintain > in the forge. > > Finally, we have made an effort to try convey to the GCC hackers and > maintainers how this front-end is a serious project, how we really > want > to use this language and use GCC to compile our programs, and how > having > this front-end can benefit GCC as a whole. I believe the response > has > been generally positive, but that is up for the SC to judge.
Jose: I've been meaning to talk about this, and wish I'd done it face to face at Cauldron, rather than doing this over email (and, indeed, I hope it's OK to do this on-list). With the caveats that I'm not on the Steering Committee, and that this is just my personal opinion: Algol 68 strikes me as a fun hobby project, and so describing it as you did above as a "serious project" is IMHO rather off-putting. To me, it reminds me of the MMIX backend: clearly we gain kudos points for implementing Knuth's imaginary processor, and it has academic interest (both literal and metaphorically); similarly a68 seems like a cool retrocomputing hack that does indeed have some benefits for gcc in terms of shaking out our frontend interface, and proving that we can scale the Mount Olympus of parsing challenges, as it were. It appeals to the part of me that is interested in e.g. PDP-11 reconstructions, multitasking OSes for the 6502, etc ...but considering it as a "serious project" feels misguided. I don't expect to see a meaningful uptick in usage of Algol 68 in 2025; it feels like a dead language that had its time; I don't see why an end-user would use it, except academic/curiosity. Another analogy might be this old proposal to add the invented "Tengwar" script to Unicode: https://web.archive.org/web/20240213234446/https://std.dkuug.dk/JTC1/SC2/WG2/docs/n1641/n1641.htm I wonder to what extent does the number of Algol68 programs in existence compares to the number of "authentic" documents in Tengwar found supposedly in the Red Book of Westmarch (but actually written by the late Professor Tolkien) (although perhaps there was a temporary rush of new documents using that script when they were producing the LotR movies?). So it's an awesome demo, appeals to my inner nerd, and a neat showcase of a piece of computing history, and it does have some benefit to GCC in that it's one more example of a frontend and the bits that go with it, both for people to study, and so that we can expose assumptions that we're making in our frontends, but... ...there are two significant drawbacks to accepting a68 that I can see: (a) "developer velocity" for everyone else not working on a68 (b) messaging around whether this is something important to the gcc project For (a), my builds and bootstraps always seem to take longer with each release as we add new stuff (and I'm guilty of this too). For frontends, I'm happy to take the hit for rust as it seems important for the future, and likewise given the vast corpus of cobol code out in the world, I'm happy to take the hit for cobol. I wonder if a compromise position here might be some kind of "secondary frontend" status that isn't in --enable-languages=all, and that the rest of us aren't expected to bootstrap/regression-test with, or, indeed greatly care about. For example if I'm refactoring code below gcc/diagnostics/ maybe I shouldn't have to care about whether the change I'm checking in is breaking the build of the a68 FE; that if I do break the build of a68, that Jose and team will fix it for me. (not sure if this is a good idea; I'm just brainstorming). Going back to the MMIX analogy, given the way that our target support works, the user has to actively opt-in to choose mmix as the target when configuring a build of gcc, so arguably the analogy doesn't quite work. For (b), messaging, for example, I see news sites picking up on your patch postings and there's been discussion in related forums that could be paraphrased about whether the gcc devs don't have better things to do with their time. I wonder if we need to explicitly state that this is intended as a fun retrocomputing side-project that serves the greater good of ensuring that GCC can support many kinds of programming language, and to make it clear that what we're spending the bulk of our cycles on as upstream developers for GCC 16 are things like C++ improvements (reflection support, better template errors), better code generation in general, and on specific targets, better support for the Linux kernel, etc. I hope this is constructive criticism; I'm sorry if it comes across as dunking on your project, and again, this is just my personal opinion. Dave > > Stage 1 of GCC 16 is almost over, so hereby we are asking the SC to > please consider accepting the contribution of the front-end in its > current form, which hopefully this time will be considered mature > enough > as to not be a burden once integrated. > > There is still a lot of work to do and it is not our intention to nag > the committee nor the community with this; we could certainly stay > off-tree for more cycles, and we will do it if we have to, but we > really > are eager to be in-tree as it would make implementing modules and > other > advanced features, that are next in our TODO now that the support for > the core language has been completed, so much easier. > > I of course offer my personal commitment to maintain the front-end > responsibly and timely, to the best of my limited abilities and even > more limited availability. > > Thank you for considering! > > [1] Front-end homepage: > https://gcc.gnu.org/wiki/Algol68FrontEnd > > [2] Version 4 of the patch series in gcc-patches: > > https://gcc.gnu.org/pipermail/gcc-patches/2025-October/698011.html >
