[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incompatibility with SRFI-4

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!)

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.