from the explanations in the manual i interpret the definition of the
srfi-4 compatibility to be "can work on srfi-4 vectors because the
storage is the same, even though it regards the data as 8-bit values"
i looked at the code and it seems to work just like this for the read
and write part of the copy. for the creation part it uses
make-bytevector with the input type copied in a generic way - i think
this is sound so far because it does not include any special cases for
working with srfi-4 types.
the main problem may be that SCM_BYTEVECTOR_LENGTH returns the wrong
length - that it does not follow 8-bit interpretation
if bytevector-copy would have a input/output type discrepancy, then the
general bytevector/srfi-4 compatibility as i understand it would be in
question - read supported, but not create or write.
bytevector-copy! has the same issues
On 27.10.2014 12:00, taylanbayi...@gmail.com wrote:
Mark H Weaver <m...@netris.org> writes:
Thoughts?
I have no experience with SRFI-4 so don't know what would be most
pragmatic, but reading the specification, I see s8vector, u8vector,
s16vector, etc. are all distinct data types, though u8vector
corresponds
to u8vector from SRFI-66, bytevectors from R6RS, and bytevectors from
R7RS. Thus I would expect those four to be the same data type, and
distinct from the other SRFI-4 types. Correspondingly, I'd expect the
SRFI-4/66 u8vector and R6/7RS bytevector APIs all to work on that type
and only that type. Other types from SRFI-4 should have their
dedicated
APIs, including a copy procedure.
That seems like the relatively obvious Right Way to me, unless I'm
missing something.
If useful, there could be a separate API of procedures that work on
both
u8vector (i.e. bytevector) and other SRFI-4 data types, but otherwise
I'm of the opinion that any distinct data type exposed to Scheme users
should also have its dedicated API that works on no other types.
Taylan
