 |
 |
 |
In an interview not too long ago I confidently remarked that A68G would be feature complete. Almost feature complete, as it turns out. Somehow I cannot help improving the Genie, as users have come to call my interpreter. I have now posted version 3.14. I had not really expected to arrive at version number π someday, but here it is. This version is not a revolution, but a belated and rather academic evolution of one of the earliest parts of the implementation, namely the scanner.
The Revised Report defines a reference language. This is done at a high-level using abstract symbols, and requires another, practical layer to allow its symbols to be composed with, and represented on, actual hardware. For instance, half a century after the Revised Report was published, my keyboard still cannot compose bold-letters. Of course, the authors of the language lived in the real world, and envisaged representation languages that are mapped onto the Algol 68 reference language, in an unambiguous manner. This all plays at the level of the lexical analyzer, or scanner, of an Algol 68 implementation. The parser is not bothered by representation language details.
A report defining a standard for representation languages is The Report on the Standard Hardware Representation for ALGOL 68 by Wilfred Hansen and Hendrik Boom, published in the ACM journal SIGPLAN Notices 12(5) in 1977. The report was approved by the Algol 68 working group, which gives it golden-standard status. From here on, when I refer to the report in this post, I mean the above one and not the revised report defining Algol itself.
GA68, the recently released Algol 68 front-end to GCC, follows the report. In A68G (indeed, the names of the implementations are anagrams, which I think is cool) this aspect was not satisfactorily resolved since the Genie was published twenty-five years ago, and that is why I call this new release tardy. A68G implemented a subset of the report with ad hoc extensions, which was a workable situation. I never received remarks on this, so I took it as a non-issue and spent my time on more pressing A68G work. This aspect of the Genie however remained in need of attention, and it has finally come to pass.
Do not expect important changes to your daily routine, though. To give an idea of the impact - the regression test set for A68G comprises circa two thousand test programs, and less than a handful were in need of a minor edit. On the one hand, much Algol 68 coding in the last two decades would have been done using A68G, which might help explain why only few test programs were in need of attention. On the other hand, it confirms that extensions were essentially unused, resulting in only minor practical issues.
One deviation in the regression test set was caused by A68G previously not allowing digits in upper-case bold symbols, hence the term subset earlier. In that program the imaginary part of a complex number was written as I0. The report however allows a digit to represent a bold-digit and arranges that this cannot lead to ambiguity. Like GA68, A68G now accepts digits into upper-case bold words. Above imaginary part must henceforth be written as I 0, as I0 is a bold tag.
The new Genie embraces the report's concept of taggles, allowing underscores to intersperse identifiers. Also, by default A68G applies the nice GA68 extension bold taggles that extends this concept to bold tags. As you can imagine, taggle is jargon meaning part of a tag. Taggles can be terminated by a meaningless underscore, and are joined to form a tag. This way the report accomodates underscores in a language that does not consider them part of symbols.
Previous versions of A68G made underscores part of the word they appeared in (except for trailing ones, those were ignored). I admit that this was an ad hoc arrangement and after almost thirty years, I really do not recall the underlying reasoning. This is however not what the report intended for underscores, and it has been straightened out now. You can still write underscores, but those are for legibility and do not alter the symbol in which they appear. Please refer to the report and the documentation of both A68G and GA68 for details.
Note that in any implementation, underscores cannot appear in reserved keywords. This leads to the somewhat odd situation that IF_ and I_F are a same tag, but both cannot mean IF. In this post however I do not want to enter into esoteric discussion.
A68G does not completely follow the report as does GA68. The report suggests that implementations support, further to upper stropping as adopted by A68G and GA68, at least archaic variants point stropping and reserved stropping. Of the obsolete regimes, the Genie implements point stropping and a third variant, quote stropping. The latter variant is not in the report but was actually supported by vintage compilers.
The reason why the Genie supports archaic variants is the presence of a number of relevant 1970's programs in its regression test set, like the INRIA synthetic test set by Bernard Houssais that at the time were used to validate compilers. That vintage source code lacks a lower case alphabet, so might even have been punched at the time. For contemporary program development, the outdated regimes are considered no longer relevant.
In conclusion, version number π is an evolution at a formal rather than a practical level. The impact on existing code is expected to be very minor, and I dare say that most users will not notice the change at all. From an academic point of view however, this review of the Genie's lexical analyzer was long overdue.
