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

[Gary Houston <ghouston at arglist dot com>]

> From: Ole Myren Rohne <ole.rohne@cern.ch>
> 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) 
> "aaaaaaaaaa"
> 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
implementation).

> 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?