Am Mi., 19. Aug. 2020 um 22:38 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> One problem of having \xHH; mean different things in string liberal and bytevector literal is that when you're editing source and happens to want to change an existing string literal to a bytevector literal, you'd *almost always* be able to do so by just inserting #u8 before it.   Except for the rare case that string contains \xHH; sequence.  You may not always be careful enough (suppose you're editing auto-generated data, for example).  It silently changes the content of the literal unintentionally, and may go undetected for a long time.
>
> If you have two conceptually corresponding structures and they look almost always identical except for rare cases, I feel a pitfall is waiting.

Indeed.

While I still don't like the same sequence "\xHH;" for two different
things, nevertheless, as I said before, your problem can be mitigated
by specifying a #utf8"..." bytevector literal as well where "\xHH;"
retains its meaning. When you translate strings to bytevectors, you
will always want to use #utf8"..." then (assuming that you are fine
with UTF-8 encoding) and you won't run into the u8"..." problem.

>
>
> On Tue, Aug 18, 2020 at 12:30 PM John Cowan <xxxxxx@ccil.org> wrote:
>>
>> I should hope that they would be intelligent enough to figure it out.  OId age is not for sissies, and Scheme programming is not for the incurious.
>>
>> On Tue, Aug 18, 2020 at 2:49 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>>
>>> Am Di., 18. Aug. 2020 um 20:25 Uhr schrieb Daphne Preston-Kendal <xxxxxx@nonceword.org>:
>>>>
>>>> > On 18 Aug 2020, at 19:00, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>>> >
>>>> > With your proposal, the same escape sequences mean something different in different contexts. That's worse. And it does not follow the Python model.
>>>>
>>>> If I understand your objection correctly, it’s only true if you assume that regular Scheme strings are UTF-8. They’re not. It's up to an implementation to decide an internal representation, and — as in Python — semantically, they’re just bags of codepoints like #u8-vectors are bags of bytes.
>>>
>>>
>>> I don't assume that strings are internally represented as UTF-8. But if I want to interpret strings as a sequence of bytes, the only thing that R7RS offers me is string->utf8.
>>>
>>>> \x80; in a string-notated bytevector means the byte 0x80; \x80 in a normal string means the codepoint U+0080. Those are two different things, but they can only be two different things. It's no different from the difference between  anything else in the notation: the ASCII character A in a string-notated bytevector means the byte 0x41; the ASCII character A in a string means the codepoint U+0041.
>>>
>>>
>>> If we lived in an isolated space, I would have to agree with you. But we don't and so we have certain expectations.
>>>
>>> Think of a newcomer who knows R7RS and a bit of C and that newcomer stumbles over some code written for SRFI 207 that contains the literal u8"bla\x80;blubb".
>>>