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"
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
