> Marc> I wonder why you did not use the SRFI-4 names for your byte-vector
> Marc> procedures.
>
> Because I wanted the names to make sense in a context where SRFI 4 is
> not available, or the user doesn't know about it.  "u8vector" seemed
> too much of a mouthful if the others aren't there.

I would argue that u8vector is actually clearer than byte-vector,
after all the elements in these vectors are really unsigned octets (8
bit non-negative integers), so the name unsigned-octet-vector would be
more precise.  The term u8vector captures these aspects concisely.

> Marc> I just don't see any good reason to invent a new SRFI-4
> Marc> incompatible API for byte-vectors given that many Scheme
> Marc> implementations currently support SRFI-4.
>
> There's no incompatibility, as the names I use are completely disjoint
> from those of SRFI.  Both can co-exist peacefully.

I meant "inconsistent".  This is a portability issue because when
someone writes a piece of code they have to decide whether to use the
SRFI-4 names or the SRFI-66 names, and hence that code will only work
on some systems that support SRFI-4 xor SRFI-66.

Moreover, there is a non-trivial cost for adding support for SRFI-66
in a system supporting SRFI-4.  If you do the obvious

(define byte-vector-ref u8vector-ref)
(define byte-vector-set! u8vector-set!)
...etc

then error messages will not be as precise as they should (i.e. the
call (byte-vector-ref (make-byte-vector 5) 10) in Gambit would report
that the error was detected by u8vector-ref, which is not what the
user wrote).  So to provide precise error messages the error checking
has to be duplicated in byte-vector-ref, etc and there is very little
left to share between the implementation of byte-vectors and u8vectors.

Marc