This is the mail archive of the
mailing list for the Guile project.
Re: binary-io (was Re: rfc 2045 base64 encoding/decoding module)
> From: Ole Myren Rohne <email@example.com>
> Date: 11 Feb 2000 10:03:42 +0100
> > 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)
Yes, I'd forgotten that. BTW, I think it's a mistake to define
ref/set! routines for a byte-vector, since the bits can be
interpreted in any way you like. There seems to be no reason to
favour a particular conversion (to characters, in the current
> BTW, I think octet is the proper name for 8-bit bytes.
I thought it would be better to specify that the byte size be the same
as C is using on the platform. It would be inconvenient to support
8-bit bytes on a machine where the byte size and C char were some
other size, such as 16 to 64 bits (I don't know if it's likely that
such machines will be (re)-introduced in the near future, even for
niche markets, but it seems like a useful thought experiment. Does
anyone have a PDP-10 emulator?)
> This is not to say that guile's uniform vectors couldn't use a
> rewrite... Here is my wishlist
Yeah, I think somebody has been working on something.
> * 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.
If you already need to pack integers in the 8 to 64 bit range, it
seems like you may as well generalise it to any multiple of the byte
size and pass the size as a parameter.
> * 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.
Uniform vectors seem to have only two uses: a memory-saving substitute
for regular Scheme vectors and for accessing foreign data.
The first use is not all that exciting, since it seems like just a
work-around for a limitation in the conception of Scheme vectors or in
the Scheme implementation. The vectors are not used to provide any
new facilities and maybe only a limited range of types is required.
The second use raises a question: what benefit does the use of (typed)
uniform vectors provide if you can already access the data by applying
pack/unpack routines to a byte-vector?