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.
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.