Am Mo., 16. Aug. 2021 um 17:49 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Mon, Aug 16, 2021 at 6:58 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

With SRFI 135, we have one recent SRFI that suggests using a non-ASCII character in the standard.  I hope it will be amended in the future to replace the suggested external variant with an ASCII version.

Well, there are no one-character alternatives left except { }, and I hate to use up the last available characters when they form a nice pair.  (Using [ ] would be a really gratuitous incompatibility with R6, and I really do try to avoid those, little though it may seem so.)  So the practical alternative is #?...?, where ? is some character or pair of characters.   #"..." is the obvious, but it has also been proposed by SRFI 207 bytestrings.  This is exactly why I want to keep all lexical issues for the end.

That sounds like a good idea to me.  As most strings in practice will probably be immutable and should thus be SRFI 135 texts, it doesn't make sense to assign SRFI 135 texts a lexical syntax that is (much) more complicated (in numbers of characters or in terms of non-ASCIIness) than the lexical syntax of mutable strings.  And as texts should be more common than bytestrings in sources, the latter should get the simpler lexical syntax.

So one could propose to finally use #"..." for texts and something like #u8"..." for bytestrings (modulo the discussion there about octets larger than 127) and maybe a reader flag that switches #"..." and "...".

 

There is a separate problem with guillemets: which way do they point, outward as in French, or inward as in German?  SRFI 135 presumes the first style, but I can see where it would cause confusion that "..." does not have. 

Indeed; this is especially unfortunate although this is no ASCII vs non-ASCII issue.