> 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?).
With "serious" I actually meant that this is not just a scratched front-end for a toy language, but a proper implementation of a powerful programming language that is in fact notoriously difficult to compile, as I hope you will agree if you look at it. [That said, I have to confess that to me and to a few others this is also indeed a serious project, to the extent a tool can be taken seriously: we want to write programs in some given language and work with it, so we write a front-end for it. No more, no less.] > 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. If it comes to that we can certainly live with algol68 being excluded from --enable-languages=all. Being a second class citizen is still better than being off-tree, and nothing shameful about it: back-ends are also graded in primary, secondary, etc. It may be actually a good idea to do so, at least initially. As the maintainer of a non-primary-non-secondary target, I know well that not being on the front-line has its advantages ;) > 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. Hmm, I am afraid I cannot be of much help there, other that if the GCC project chooses to explicitly market or advertise the front-end as a fun retrocomputing side-project, I'm totally fine with that. > 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. On the contrary! You are very welcome, as always :) Salud! > > 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 >>
