With talk of Guile 4.0 in the air, I’d like to propose that this version should be taken as an opportunity to enable --r6rs and --r7rs modes by default.
This means practically that at the very least, Guile will look for libraries with .sls and .sld suffixes by default, and support R6RS- and R7RS-style escapes in strings by default. Most of the rest of this mail will deal with justifying these changes, and discussing compatibility issues; I’ll mention a few other fairly simple things at the end which could be done to improve report conformance to strengthen this change. The first change is very easy to justify. At the moment, portable R7RS and R6RS libraries work pretty much fine in Guile, modulo a few bugs, but require support to be enabled explicitly. If you want to use R6RS and R7RS libraries in the same program, you have to start Guile with --r7rs --r6rs. The other way around (--r6rs --r7rs) doesn’t work, because --r7rs --r6rs runs the compatibility mode initialization procedures in the order install-r7rs! then install-r6rs! – and for some reason install-r7rs! removes the more R6RS-y .sls from the load extensions list before adding .sld, but install-r6rs! doesn’t remove the more R7RS-y .sld. So it works one way around, but not the other. <https://codeberg.org/guile/guile/src/commit/a1abc688872b0242e57fb3c0ec5c83451c12e823/module/ice-9/boot-9.scm#L4681> This is extremely unintuitive for users, and imposes an ugly global mode switch on programs – according not only to which libraries they directly import, but according to their transitive imports as well. Worse, due to the standard layout for many R7RS libraries (with a .sld declaration which includes a .scm source file of the same base name), Guile started in its default mode will try to load the wrong file when importing such libraries, which doesn’t actually include any library declaration – giving the illusion that Guile doesn’t support an R7RS library, when in fact it would probably work fine with the --r7rs flag. This standard layout means Guile’s new default would have to be to look for .sld files before .scm files. This might cause breakage or surprising results in the case of libraries which have a .scm version targeting Guile besides a .sld version targetting standard R7RS. I have created such a library myself (the SRFI 250 sample implementation), and I personally am willing to accept this. The damage is probably limited because in most cases, all you would likely miss out on would be some Guile-specific customizations and optimizations. (E.g. you wouldn’t get the more informative record printer for hash tables in the SRFI 250 sample impl.) The new way to provide such customizations would be through a .guile.sls file or a cond-expand for the ‘guile’ feature symbol in the .sld file. Apart from that, there should be no problems with having Guile look for .sls and .sld files by default when searching for a library. I note by-the-by that Hoot is written using a fairly free mixture of Guile-style, R6RS-style, and R7RS-style library definitions. The second change will be harder to make. I suggest that if possible, the next minor release of Guile should begin warning about the deprecation of \xNN string escapes with no semicolon when the reader encounters one; then Guile 4.0 can turn them off by default. The \u and \U string escapes are actually fine and could stay. I’m willing to write and submit patches for these changes. I’d also like to remind everyone about these patches to improve R7RS library support: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66046> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65363> I’d also like to work on patches improving R6RS support in general, ideally so that the Racket R6RS test suite can begin to run and pass more and more on Guile. (At the moment there’s one hold-up that should be simple to fix – let-syntax doesn’t work if it has no body, when it should be equivalent to a splicing begin with nothing in it.) But first, I’d like some feedback on this proposal. Daphne
