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 can add the lexical syntaxes to Unsyntax's reader so that we then
have a full sample implementation.

Am Di., 6. Okt. 2020 um 17:37 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> Okay.  Are there any more issues before I request a last call?
>
> On Tue, Oct 6, 2020 at 1:43 AM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>>
>> On 2020-10-05 20:21 -0400, John Cowan wrote:
>> > On Mon, Oct 5, 2020 at 3:18 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
>> > wrote:
>> >
>> > > But I'm wondering now if perhaps string->bytestring is a confusing
>> > > idea, at least in name.  string->bytestring and bytestring->string are
>> > > basically read/write with string-port I/O, respectively.
>> >
>> > I modeled them on string->bitvector and bitvector->string from SRFI 178.
>> > But now I think that xxxxxx@vector and xxxxxx@vector from SRFI 160 is a
>> > better model, so I've changed it thus:  read-textual-bytestring reads the
>> > bytestring format from a port and returns a bytevector;
>> > write-textual-bytestring writes a bytevector to a port in the bytestring
>> > format; write-binary-bytestring is the former write-bytestring.
>>
>> Thanks, I *vastly* prefer these port procedures.  I've updated my copy
>> of the sample implementation.
>>
>> > As for #vu8"foo", let's drop it.  Just because ordinary bytevector literals
>> > are #vu8(...) on R6RS doesn't mean that bytestring literals have to be
>> > #vu8"..."; they can be uniform for both R6 and R7 implementations.
>>
>> Looks good to me.
>>
>> --
>> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>>
>> "Prolonged contact with the computer turns mathematicians into
>> clerks and vice-versa." --Alan J. Perlis