This page is part of the web mail archives of SRFI 66 from before July 7th, 2015. The new archives for SRFI 66 contain all messages, not just those from before July 7th, 2015.
> 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