[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Incompatibility with SRFI-4
> 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!)
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.