guile-devel
[Top][All Lists]
Advanced

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

Re: bytevector-copy creates srfi-4 vector with greater length


From: tantalum
Subject: Re: bytevector-copy creates srfi-4 vector with greater length
Date: Mon, 27 Oct 2014 13:36:06 +0100
User-agent: Posteo Webmail

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, address@hidden wrote:
Mark H Weaver <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]