Greetings, all,

(1) I'm unsure of the distinction between "bytestrings" and
"bytevectors" in this SRFI.  Procedures use one name or the other
(both, in a few cases), but the values are interchangeable.  For
example, the same Scheme object can be created with `bytestring' or
with `string->bytevector', yet the naming seems to suggest a
difference.  I notice that "bytestring" constructors tend to raise
errors satisfying `bytestring-error?', whereas "bytevector"
constructors like `hex-string->bytevector' do not.  Otherwise, I don't
see any clear explanation for the naming differences.  Perhaps this is
just a "seam" in the SRFI.)

Could we eliminate the "bytestring" term altogether without loss of
clarity?  Some procedures like bytestring-pad are "stringy", but this
doesn't seem to justify a different name.  Bitvectors, for example,
have "string-processing" forms like pad and trim, but we call those
procedures bitvector-pad and bitvector-trim, not bitstring-pad, etc.

(2) In implementing the recently-added string->bytevector procedure, I
chose to have it raise bytestring-errors, in the sense of
`bytestring-error?', if its arguments contain invalid elements.  Since
this is symmetrical with the `bytestring' and `list->bytestring'
constructors, I thought this sensible.  In the context of the above
discussion, though, I'm not so sure.  Should we consider
string->bytevector a "bytestring" procedure in this sense?

(3) `bytestring' should adopt the same interpretation of string
arguments that string->bytevector uses.  That is, if s is a valid
string-notated bytevector, we have

    (bytestring s) == (string->bytevector s).

(4) Is there any way we can get rid of the `v' argument to
bytevector->string?  Maybe this has been discussed already, but it
seems like a very clunky way to get R6RS compatibility.

Regards,

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

"Never do programs contain so few bugs as when no debugging tools
are available." --Niklaus Wirth