This is the mail archive of the
mailing list for the Guile project.
Re: binary-io (was Re: rfc 2045 base64 encoding/decoding module)
Gary Houston <firstname.lastname@example.org> writes:
> Define a new "byte-vector" type. "byte" would be defined to be the
> same thing as a C char, since Guile is supposed to be good at
> interoperating with C. Possibly call it something else out of
> respect for Common Lisp usage of "byte". It's true that bit-vectors
> already exist, but I think byte-vectors would be more convenient.
> Also introduce a "shared byte-vector". This would generally behave
> like a byte-vector but wouldn't free its memory when garbage
> collected. It would be created by specifying an address (from C
> again, a char * expressed as an integer) and a length.
In fact, guile already has "byte-vectors", which are different from strings:
guile> (make-uniform-vector 10 #\a)
guile> (make-uniform-vector 10 #\nul)
#y(0 0 0 0 0 0 0 0 0 0)
BTW, I think octet is the proper name for 8-bit bytes.
This is not to say that guile's uniform vectors couldn't use a
rewrite... Here is my wishlist
* Support all SRFI 4 types (signed and unsigned exact numbers of 8 to 64
bits, inexact numbers) and strings and scm-values in a unified way.
* Shared version of all types. Currently, only strings (== unsigned
char) can be shared. This would be nice for certain types of ffi work.
* Get rid of uniform-vector-ref in favour of vector-ref- a non-uniform
vector is nothing but a uniform vector of scm-values anyway. A setter
for vector-ref would be cool.
* Multi-dimensional arrays built cleanly on top of vectors. It might
be only naming, but having `dimensions->uniform-array' to create a
uniform vector confuses me. I'd like an array to be something that
inherits its underlying vector's type and data.