Am Mi., 7. Okt. 2020 um 11:08 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> On 6 Oct 2020, at 19:16, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> > I'm still very much in favor of adding #utf8"..." to the lexical
> > syntax as well (haven't got a definite reply on that). Not only is
> > this useful for UTF-8 encoded bytevector literals of a post-ASCII
> > world, it also makes it clear that u8"..." is *not* about UTF-8
> > encoding and thus helps to clarify the role of \xnn; in u8"..."
> > literals, which a number of people found otherwise non-obvious.
>
> I think a reasonable implementation should be able to evaluate
> (string->utf8 "...") at compile time to provide this as a friendly
> notation. By contrast, there was previously no easily-human-readable

Compile-time optimizations do not reach into expansion time. Macros
can understand and compare bytevector literals, but they cannot look
easily into (string->utf8 "..."). If you have a large data structure
with cycles that you want to write to a file (and you know that the
bytevectors included are UTF-8 encoded strings), literals (with datum
labels) are the obvious choice and programmatically building the data
structure through string->utf8, set-car!, etc. is no alternative.

> way to write bytestrings before. If I had known about John's bytestring
> procedure idea before proposing the reader notation, I would probably
> not have bothered with it — but even so, #u8"r\xE9;cursivit\xE9;" seems
> easier to me than (bytestring "r" #xE9 "cursivit" #xE9).

I really hope that this SRFI does *not* encourage to use legacy encodings.

> #utf8"récursivité" seems, comparatively, like a small gain compared to
> (string->utf8 "récursivité").

See above.

I hardly see a reason *not* to include utf8"..." when u8"..." is
included because the implementation cost doesn't become higher.

Alternatively, I would remove the reader notation from this SRFI
altogether to possibly place them in a separate SRFI. In fact, the
lexical syntax part of SRFI 207 is not really connected to the main
procedural part. Some Scheme implementations may want to implement the
procedures but do not (or cannot) implement the reader syntax; other
implementations may like the reader syntax but not the procedures.
Also, should we vote on this SRFI for inclusion in R7RS (large), there
should really be two votes: One about the syntax, and one about
bytestring interface. Having two SRFIs makes this easier.

Marc