Daphne Preston-Kendal <[email protected]> writes: >>> 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.
I would be sad to see them gone, since I am using them, but I understand your argument. If the maintainers decide to go this way, I would just implore that the deprecation period is sufficiently long (at least year seems reasonable) and, more importantly, that the minor version with the deprecation actually makes it into GNU Guix as the `guile' package (currently it is still 3.0.9, the project decided to skip the .10 completely). Related question, how should code handle the deprecation? I cannot just change the \xNN to \xNN;, since that would not work. Is it possible to enable the r6rs syntax on per-file basis? Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
