an alternative idea for general binary vectors Taylor Campbell (23 Mar 2005 23:55 UTC)
Re: an alternative idea for general binary vectors Michael Sperber (24 Mar 2005 06:41 UTC)
Re: an alternative idea for general binary vectors Taylor Campbell (24 Mar 2005 20:50 UTC)
Re: an alternative idea for general binary vectors Michael Sperber (29 Mar 2005 14:28 UTC)
Re: an alternative idea for general binary vectors Taylor Campbell (29 Mar 2005 20:36 UTC)
Re: an alternative idea for general binary vectors Michael Sperber (30 Mar 2005 13:29 UTC)

Re: an alternative idea for general binary vectors Michael Sperber 29 Mar 2005 14:28 UTC

>>>>> "Taylor" == Taylor Campbell <xxxxxx@bloodandcoffee.net> writes:

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

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

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

Do you mean that the endianness parameter defaults to the
machine-native endianness?  That'd be a sure-fire recipe for
portability hell.  Cf. how many times people forget htonl(3).

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla