[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

This page is part of the web mail archives of SRFI 66 from before July 7th, 2015. The new archives for SRFI 66 contain all messages, not just those from before July 7th, 2015.

*To*: srfi-66@xxxxxxxxxxxxxxxxx*Subject*: an alternative idea for general binary vectors*From*: Taylor Campbell <campbell@xxxxxxxxxxxxxxxxxx>*Date*: Wed, 23 Mar 2005 16:27:55 -0800 (PST)*Delivered-to*: srfi-66@xxxxxxxxxxxxxxxxx

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?

**Follow-Ups**:**Re: an alternative idea for general binary vectors***From:*Michael Sperber

- Prev by Date:
**Re: Also SUBSEQ and FILL!** - Next by Date:
**Re: an alternative idea for general binary vectors** - Previous by thread:
**Re: additional operations: COPY! and COPY** - Next by thread:
**Re: an alternative idea for general binary vectors** - Index(es):