Am Mi., 7. Okt. 2020 um 17:15 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Wed, Oct 7, 2020 at 6:01 AM Shiro Kawai <xxxxxx@gmail.com> wrote:
>
>> I understand the whole point of "bytestring" is an alternative external representation.
>
>
> Well, it's twofold: the external representation is one thing and the construction of bytevectors from integers, characters, strings, and existing bytevectors is another.  Where some will write #u8"abc\x1f;def", others will prefer (bytestring "abc" #x1F "def").  These ideas were independently conceived and have been joined together.  I have enlarged the abstract to help with this.
>
>>
>> I don't quite understand why the procedures that don't involve external representation are named 'bytestring-something', as if they deal with 'bytestring' objects.

I have to agree with Shiro that the "bytestring" prefix is a bit
confusing. For example, "bytevector-pad" makes as much sense as
"bytestring-pad".

Only if you want to add a "bytevector-pad" where the pad-byte argument
is restricted to an u8, it makes sense to distinguish the two, I
think.

Actually (but this is a general critique about one direction of this
SRFI), I don't like that ASCII characters are given special treatment.
For legacy code, yes, but not for code that does not yet exist (i.e.
code that uses SRFI 207). Thanks to characters like Ä. Ö. Ü, and ß in
my native language, I have been plagued enough by incompatible
encodings or encodings ignorant of characters outside the American
English that I would like to draw a much clearer line between bytes
and characters.