On Thu, 24 Mar 2005, Michael Sperber wrote:

> It's an intriguing idea.  However, note that as soon as you move
> beyond bytes (octets, whatever) you get into endianness issues.  These
> can be solved, but probably either complicate the API or compromise
> efficiency to a degree.

Sorry, I meant to add a note about endianness, but I completely forgot
to while writing that mail.  I don't think that it a very big issue: it
could work in a manner similar to SRFI 56 (binary I/O), where there is
one 'default endianness' (local to the machine), and all of the endian-
affected procedures accept an optional endianness parameter.  For
instance, the signature for BINARY-VECTOR-SET-S16! would be:

  (BINARY-VECTOR-SET-S16! binvector index signed-halfword [endianness])

This wouldn't be too much of a compromise on efficiency, and the API is
made hardly more complicated with the extra endianness parameter.