On 18 Aug 2020, at 18:12, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

> This is bad for implementations who want to extend SRFI 207 to the full Unicode repertoire of characters.

Implementations should not do this. (Or more accurately: implementations which
do this should not do so in the expectation that it will be interoperable.)

Bytes are bytes and codepoints are codepoints. Fairly often when processing
human-readable strings in Latin script, generally short ones, they happen to
roughly mean the same thing, which is why this SRFI exists for humans reading
and writing source code. But when they don’t match up, it should be as visually
obvious as possible.

> The above may not even work when the string lexer of the implementation is used and the implementation does not allow ASCII 0 as part of strings.

"\yC0" is an invalid string that the lexer should reject if we follow this line
of argument, but #u8"\yC0" (or #u8("\yC0"), in Alex’s spelling) is a perfectly
cromulent bytevector. (This is assuming our goal is to make #u8 strings a
notational equivalent to a call to string->utf8.)

The whole thing with \y (or whatever we’d call it) in normal strings reminds me
too much of how JavaScript pre-ES6 behaves with astral plane characters. (You
had to escape the surrogate pairs!) Who is asking to be able to write regular
strings in hex-escaped UTF-8 byte sequences? And why on earth should a SRFI
about bytevector notation have to go in and change the definition of string
notation too?

Even if the eventual notation is #u8() with string literals in it, I’m
following John and putting a firm no on the idea of calling the escape sequence
something different. This also, by implication, means equivalence with
string->utf8 won’t work. I think that idea was a non-starter.

Daphne