Am Mi., 14. Okt. 2020 um 10:20 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> This is a restatement of the point I raised before, but I'd like to push it one more time.  I suggest the following 4 procedures to be renamed using 'bytevector' in the palace of 'bytestring'.
>
>   bytestring->hex-string
>   hex-string->bytestring
>   bytestring->base64
>   base64->bytestring
>
> These are useful for general bytevectors, regardless of how the user views them.  For example, if one wants to print binary data held in a bytevector in hex-string format, he would look for 'bytevector->something'.   It is unintuitive that such a procedure is provided with 'bytestring' names.
>
> An alternative suggestion is to drop these 4 procedure, and let them be provided from base64 or hex-string library instead, which would cover both strings and bytevectors.   The user who's looking for a way to convert bytevector to base64 may not look at "String-notated bytevectors" library.
>
> I'm also uneasy for list->bytestring[!] and bytestring->list, for their names strongly suggest as if there were a bytestring object, but alternative names maybe be too verbose (e.g. bytestring-fragments->bytevector).

I agree. I wouldn't overload the meaning of "->" in R7RS-small unless necessary.

For example, in SRFI 1, we have append and we have concatenate.
Bytestring is to append what is list->bytestring to concatenate.
Hopefully, this example makes sure why I agree with Shiro that these
names are far from optimal.

bytestring->list is also a questionable naming. Moreover, to me, it
looks too underspecified to be useful.