Sebastian Egner <xxxxxx@philips.com> 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