"Jose E. Marchesi via Gcc" <[email protected]> writes: > 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.
I'd just like to give a short statement of support. Jose's enthusiasm for Algol 68 is infectious. I didn't have a particular interest in it before, other than wanting GCC to succeed and bring in people from all sorts of communities (including languages I know very little about), but I've started learning Algol 68 as a result, and Jose is very serious about evolving the language and supporting it fully. As for workload: I don't expect Algol 68's integration to cause problems. Jose has been around a long time, he knows how things work. As a testament to this: I started wiring up Algol 68 in our packaging and had *zero* issues on a first run, and a single test failure (VERY rare to have so few on anything new) which has now been resolved. It integrated perfectly with the build system and GCC's conventions. I couldn't believe it at first. I genuinely don't expect us to regret including Algol 68 at all. For another distributor perspective, I believe doko has been testing it on the Debian side for quite some time too. We also all know how GCC is designed. Maintaining frontends out-of-tree isn't easy, especially not for distributors like myself to then ship. Having it in-tree is IMO the best outcome for everybody involved. And, as richi says, if it becomes a problem, if (and I think this is unlikely) we can't work it out with Jose and any other interested contributors, at worst, we remove it. > [...] sam
