The art of SRFI-writing, I've found, is in knowing what to leave out.  The methods I mentioned earlier (generators, vectors as intermediates, roll-your-own loops, etc.) for converting between sequences are pretty general.  For SRFI-160, conversions don't fit into any of the 12 libraries (other than (srfi 160 base)), and would require their own library with 132 procedures, few of which would be used in any one program.

I wish there were a way to make SRFI 160 types share storage, but that wouldn't work on the JVM or the CLR, where there is no low-level access to the bytes of primitive arrays.

On Wed, Dec 25, 2019 at 4:20 AM Duy Nguyen <xxxxxx@gmail.com> wrote:
On Wed, Dec 25, 2019 at 12:56 AM John Cowan <xxxxxx@ccil.org> wrote:
>> While in packed modes, 8 items in the bitvector becomes one
>> in u8vector. The packed mode could be useful for manipulating
>> compression/video bitstreams. But maybe bitvector is not the right
>> place for this.
>
>
> I think this does make sense, and I will add packng and unpacking conversions between bitvectors and bytevectors.  Note that SRFI 160 recommends that bytevectors and u8vectors be the same thing; however, in Guile they are disjoint.

Thinking a bit more about it, this may open a can of worms. If you
allow conversion between a bitvector and a u8vector, then what about
u8vector and u32vector (four u8 packed in one u32)? SRFI 160 does not
support conversion between homogeneous vectors of different types
either, so maybe we just leave it out and figure that out in a new
srfi (if it ever comes). I won't stop you from adding new conversions
in this srfi, of course :)
--
Duy