Re: binary-io (was Re: rfc 2045 base64 encoding/decoding module)

[Ole Myren Rohne <ole dot rohne at cern dot ch>]

Gary Houston <ghouston@arglist.com> 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) 
"aaaaaaaaaa"
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.

        Regards,
        Ole