Hi GCC Steering Committee! Please consider accepting into GCC this new -- old? ;-) -- Algol 68 front end (awaiting conclusion of the ongoing technical review), and appointing José as its maintainer. (At FOSDEM last weekend, we were briefly discussing this contribution, and I offered to raise and champion this formality, which he was happy to hear.)
Grüße Thomas On 2025-01-01T03:09:44+0100, "Jose E. Marchesi" <jose.march...@oracle.com> wrote: > Hello people, happy GNU year! > > This WIP is a GCC front-end for Algol 68, the fascinating, generally > poorly understood and often vilified programming language. It is > common knowledge that Algol 68 was well ahead of its time back when it > was introduced, and anyone who knows the language well will suspect > this probably still holds true today, but more than fifty years after > the publication of the Revised Report the world may finally be ready > for it, or perhaps not, we shall see ;) At the very least having > support in GCC will make it easier for Algol 68 enthusiasts to write, > share and use their programs in modern systems. > > This is work in progress, but the front-end can already compile most > of the main language constructs and many full programs. > > Most of the predefined operators provided by the standard prelude are > still missing. Adding these is a matter of filling in the gaps and > should not require any fundamental change in the implementation. > > There is no transput, so the programs that can currently be compiled > and ran are not terribly useful since they cannot operate on files. A > proper transput implementation that integrates well in modern POSIX > systems is in the works. > > The Revised Report didn't concern itself with mundane topics as > separated compilation, so at this point each compilation unit is a > full program. Early Algol 68 compilers supported separated > compilation, each on its own way. The WG 2.1 also produced a proposal > for a standard modules system for Algol 68, never implemented to my > knowledge. A proper modules system is also in the works. > > The goal is for GNU Algol 68 to be a strict super-language of Algol > 68, as blessed by the Report. > > At this point I am confident the implementation is viable and it is > reasonable to continue the development in public without risking > wasting anyone's time in vaporware. > > Speaking about the implementation. > > This is my first GCC front-end and I am still only moderately familiar > with the applicable lore. Up to now I have focused in functionality > rather than efficiency in order to assess the feasibility of the task > and to get something working and suitable to be published. Therefore > there are many parts of the implementation that are crude and can be > made smarter, and places where I may have simply used the wrong > approach, out of ignorance. The FE is also awfully slow and I haven't > paid much attention to not leak memory. All of this will be fixed. > In the meanwhile any feedback from actually knowledgeable FE gurus > would be highly appreciated! > > The parser used in this front-end has been borrowed and adapted from > Algol 68 Genie, an Algol 68 interpreter written by Marcel van der > Veer. It is worth noting that this parser is not your typical garden > variety parser, as it is capable of effectively parsing the two-level > grammar of Algol 68, which is no small deal. Parsing Algol 68 is > notoriously difficult, and without Marcel's careful work of many years > this front-end would most probably not exist. It is also a beautiful > implementation that is a delight to both read and work with. I > certainly have learned a lot from it. The syntax tree built by the > parser is then lowered into a GENERIC tree by a lowering pass, which > then invokes the gimplifier and hands the resulting gimple IR over to > the rest of the compilation, down the rabbit hole all the way to > optimized assembly code. > > The DWARF currently generated by the compiler is not very useful. > Emitting DWARF that accurately describes the Algol 68 data structures > is still to be done. As is GDB support and its corresponding > expressions parser, which by the way will be lots of fun to do, > considering the language in question ^^ > > The mangling of symbols is currently very dumb. This is because we > need to design and decide on a separated compilation model first in > order to determine what information to encode in the symbols. > > The compiler driver is called `gac', for GNU Algol 68 Compiler. > The compiler proper is called `a681'. > The run-time library is called `libgac'. > > The front-end includes a testsuite for catching regressions, as well > as an user manual and an internals manual, all of which is being > expanded as the work progresses. A couple of tests are currently > failing, sorry about that. > > Note that auto re-generated files like configure are not included in > the series to not bloat the emails. These can be re-generated > normally using autoreconf and the like. I have also dispensed with > ChangeLog entries in this WIP patch series, as well as with detailed > commit messages. These will be incorporated in a subsequent version > if/when the front-end gets officially proposed for incorporation in > GCC. > > All the C and C++ code is formatted following the GNU Coding > Standards. > > The original parser is copyright Marcel van der Veer. The rest of the > code is either copyright of yours humble or boilerplate taken from > other GCC front-ends. All the code is licensed under GPLv3+, with the > GCC Runtime Library exception for run-time components. The manuals > are licensed under the GNU FDL like the rest of the documentation > shipped with GCC. > > As to where to host the project, the obvious choice is perhaps a > project at sourceware, but it would be nice if we could develop the > front-end in a branch in the GCC git repo, to have a mailing list > under gcc.gnu.org and to use a page in the GCC wiki to track the FE > progress... please let me know if that is feasible. > > An Emacs mode for editing Algol 68 programs can be found at > https://git.sr.ht/~jemarch/a68-mode. It supports automatic > indentation, pretty-printing of bold tags, an auto-stropping minor > mode and other useful features. > > The Algol 68 Jargon File at https://jemarch.net/a68-jargon aims to > provide a comprehensive list of definitions for technical and > non-technical terms used in the context of Algol 68, which are many. > It contains few entries at the moment but I am progressively expanding > it as time allows. > > Finally, I am using the #gnualgol channel in irc.oftc.net. Everyone > is welcome to join and have fun with Algol 68. > > Salud! > > PS: many thanks to Iain, Andrew, Segher and others for their help and > patience answering my FE related n00b questions in the IRC > channel. You are the best.
