Am Do., 20. Aug. 2020 um 14:45 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> (10) Why are there no reversed (little-endian) versions of the conversion functions to and from bytevectors?
>
>
> I never thought about them.  I'd rather not add them at this stage, since it's very late in the process and I don't think they are a substantial hole.  Another SRFI could do so.

Could we just add them in the process of voting SRFI 178 into
R7RS-large? (Writing a SRFI with just one or two procedures
complementing this SRFI sounds a bit cumbersome.)

It would be nice (but I know that it is hardly fulfillable but we
could think about it theoretically) if we had an efficient low-level
implementation (using, say, GMP) for this SRFI before finalization,
proving that the procedures defined here can be, in fact, implemented,
efficiently.

For example, what would be a convenient format to store bitvectors in
memory? With respect to such a format (which should handle things like
logical shifts efficiently and bitvector-first-bit), would
bitvector->bytevector be implementable in an efficient way? Or would
it be true for the reversed version? Or would it depend on the
endianness of the underlying hardware? Has anyone thought about these
things yet? Unfortunately, there are only very few names involved on
the mailing list.

Is an efficient implementation on top of SRFI 151 possible (a
bitvector would be a tuple of a length and a non-negative integer)?

PS: At the end of the SRFI, it says "Copyright John Cowan 2018". Don't
you want a 2020 there?