Am Sa., 10. Okt. 2020 um 09:42 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Wed, Oct 7, 2020 at 12:15 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> 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".
>
>
> Strings may need to be padded or truncated.  Bytevectors generally do not.
>
>>
>> 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).
>
>
> That's something I should explain better in the SRFI, and I will.  The reason for giving the ASCII characters special treatment is their universality, not for representing text (at which they fail), but for representing binary values that have mnemonic properties.  As a very simple case, the first two bytes of a .zip file are 50 4B, or u8#"PK", the initials of the format's creator, Phil Katz.
>
> Four-character codes or 4CCs <https://en.wikipedia.org/wiki/FourCC> are likewise used to label binary data: they were used on the early Mac OS to label files with their types, and are now used to label the chunks out of which a PNG graphics file, an AIFF audio file, and various other binary formats are constructed.  For example, PNG uses #u8"PLTE" (palette), #u8"bKGD" (background color), and #u8"iTXt" (text) chunks among many others.  So as you can see, SRFI-207 can be used to construct binary information in formats that are already in use.
>
>> I would like to draw a much clearer line between bytes
>> and characters.
>
>
> That line is drawn: it is the line between strings and bytevectors.  It's when it's useful to blur the line that SRFI 207 comes into play.

For all these use cases, it seems farther-reaching to me to have a
separate "bytestring" data type that also knows about its encoding so
that, in particular, the user is aware of it. SRFI 207 would then be
about ASCII bytestrings.

Moreover, with such a type, we do not have to blur any line while all
the applications above are easy to accomplish.

(With the current design, u8"PLTE" is one thing, because it is, in
fact, binary data. But ci-lexicographic comparison treats raw ASCII as
text, although it should be binary.)