an alternative idea for general binary vectors Taylor Campbell (23 Mar 2005 23:55 UTC)
Re: an alternative idea for general binary vectors Michael Sperber (24 Mar 2005 06:41 UTC)
Re: an alternative idea for general binary vectors Taylor Campbell (24 Mar 2005 20:50 UTC)
Re: an alternative idea for general binary vectors Michael Sperber (29 Mar 2005 14:28 UTC)
Re: an alternative idea for general binary vectors Taylor Campbell (29 Mar 2005 20:36 UTC)
Re: an alternative idea for general binary vectors Michael Sperber (30 Mar 2005 13:29 UTC)

an alternative idea for general binary vectors Taylor Campbell 24 Mar 2005 00:27 UTC

Recently, as I was thinking about homogeneous vectors & arrays, it
occurred to me that differently-sized binary data is often manipulated
similarly, not really in the same way as general vectors or flonum
vectors are.  This led me to wonder why there must be many different
new disjoint types for homogeneous vectors as in SRFI 4 or a somewhat
limited single byte vector type.  Instead, why not have one single,
unified binary vector type, on which accessors for elements of varying
sizes are defined, like SRFI 4 except with a single binary vector type?
This could also equally well work as a bit vector type as suggested in
SRFI 33, like MIT Scheme's bit strings.

There could be several constructors for varying length metrics, such as
MAKE-BIT-VECTOR, MAKE-BYTE-VECTOR, &c.; length accessors in different
metrics -- BINARY-VECTOR-BIT-LENGTH, &c. --; accessors for the chunks
of varying sizes, such as BINARY-VECTOR-BIT-SET?, BINARY-VECTOR-REF-U8,
BINARY-VECTOR-REF-S8, BINARY-VECTOR-REF-U16, &c.; and modifiers for the
chunks of varying sizes: BINARY-VECTOR-SET-BIT!, BINARY-VECTOR-SET-U8!,
&c.

I'm just throwing this idea out there, however, somewhat in response to
the objections raised about inconsistency with SRFI 4, not suggesting
that this SRFI be changed to this new idea.  Does this idea have merit,
or am I missing something important about it?