On 6 Oct 2025, at 12:09, Dr. Arne Babenhauserheide <[email protected]> wrote:
>> 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 > > How many libraries of each kind are there? Good question. In most cases, as mentioned, parallel .scm and .sld files belong together as part of the same (R7RS) portable library. SRFI sample implementations are special only really because Guile has its own convention for naming those, different from all other Scheme implementations. So it’s possible that my SRFI 250 code might be the only real example of such a library. > Would a smaller change of using the .scm first and .sld second by > default and changing --r7rs to only change the order be sufficient? That could be a reasonable compromise if the original proposal does break too many things. In part because of the transitive import issue, if this is a global switch at all, there may be no way to fix this entirely. Enabling --r7rs in this model might make one portable library, which should use .sld before .scm, work – while breaking another which should use .scm before .sld. >> 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. > > What’s the advantage of removing support for those escapes? The problem is that the Guile syntax is incompatible with the R6RS and R7RS syntax. R6RS and R7RS use ‘\xNN;’, ‘\xNNN;’, ‘\xNNNN;’ etc. – with any number of hex digits, but a semicolon at the end. Guile uses \xNN always with two digits, C-style. Without disabling the C-style escape, ‘\xNN;’ is ambiguous – does it mean hex character NN followed by a semicolon, like in C, or just hex character NN, as the reports say? This is why you had to enable the RnRS syntax in the past. Daphne
