On 2020-10-07 18:15 +0200, Marc Nieper-Wißkirchen 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".

I expressed a similar opinion in
https://srfi-email.schemers.org/srfi-207/msg/15222872/  I still don't
see a need for new terminology.  As I mentioned in that previous email,
previous SRFIs haven't introduced "string" names for "stringy"
procedures (e.g. in SRFI 178 we have bitvector-pad, not bitstring-pad).

bytestring=? is particularly confusing here.  It's just bytevector=?,
word for word.

> 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.

Agreed.  ASCII-only bytestrings are a legacy kluge, given that
utf8->/<-string are already present in the standard.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"It from bit." --John Wheeler