In addition, the implementation includes a portable version of (rnrs bytevectors) by Will Clinger.  The name is changed to (r6rs bytevectors) to avoid collisions with the native R6RS library, and the procedure bytevector-copy!, which has incompatible semantics in R6RS and R7RS, is renamed r6rs:bytevector-copy!.  This implementation requires only the primitive bytevector procedures make-bytevector, bytevector?, bytevector-length, bytevector-u8-ref, and bytevector-u8-set!.  There are tests for Chicken (R5RS, using u8vectors as bytevectors), Chibi (R7RS), Guile (R6RS), and Ypsilon (R6RS).

Neither of these implementations are likely to be as efficient as native ones, and should be used only on Schemes that do not provide them natively.  Note also that there is no support for SRFI 4 lexical syntax.

I am now writing a new library (srfi 4ish), which extends SRFI 4 to the three new homogeneous vector types required by SRFI 160; these are u1vectors (bit vectors), c64vectors (complex numbers stored as single-floats), and c128vectors (complex numbers stored as double-floats).  This library will also be available as part of SRFI 4's repo, and depends only on SRFI 4 (either native or portable).

When (srfi 4ish) is complete I will finally be ready to tackle SRFI 160 proper.  I have already done some preliminary work on adapting parts of SRFIs 133 (vectors) and 152 (strings), but there is still more to be done.  Nevertheless, the end is finally in sight.

--