This page is part of the web mail archives of SRFI 74 from before July 7th, 2015. The new archives for SRFI 74 contain all messages, not just those from before July 7th, 2015.
Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes: > 1. Please explain *exactly* what you mean by "little > endian"---unfortunately I have seen contradicting definitions in the > past (though most people agree on one), and also I keep forgetting > which one it is. I'll be happy to word it more precisely, even though I haven't seen conflicting definitions. (The Wikipedia article linked to from the SRFI also doesn't mention alternative interpretations.) Since this SRFI is about octet-addressed data, the definition seems pretty clear: endianness describes the ordering at the octet level. > 2. The external representation of an endianness options is undefined. Are > you sure you want that? Yes. > 3. Why is the 'native' endianness not just either (endianness big) or > (endianness little) but *another* option value? How do I find out > about the native endianness? Do have to write a program stuffing a > blob with data in 'native' and reading it out in 'little' or can I > just ask (eq? (endianness native) (endianness little))? You can't currently, but that seems like a good idea to add in the next revision. (This would also simplify the reference implementation.) > 4. While litte/big endian is the most important distinction, the > endianness issue is more complicated: Sure---and the SRFI gives you the means to implement just about any endianness on top of the operations defined here. The syntax of ENDIANNESS also gracefully extends to your suggestion. But it would increase the size of the specification and the reference implementation significantly for a benefit that isn't clear to me, which is why I'm inclined to hold off on that option. Maybe more people can chime in saying whether they'd want something like this. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla