At Tue, 28 Sep 2004 13:34:44 -0700 (PDT), campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>
> But what I'd really rather see is not the use of the symbols BIG-ENDIAN
> versus LITTLE-ENDIAN but instead unique tokens for endianness. There
> would be (HIGH-ORDER-ENDIAN) & (LOW-ORDER-ENDIAN), or (BIG-ENDIAN) &
> (LITTLE-ENDIAN), procedures that would return tokens denoting the
> endianness to use. The exact representation of the tokens is left
> unspecified. This permits, for instance, them to be small fixnums, on
> which computed gotos can be performed in the READ-... procedures for
> even better speed than symbol comparison & branching. It also permits
> other, more sophisticated representations, such as some structure
> containing the actual reader function for maximal extensibility.
I thought some more about this. The advantages of symbols
vs. constants are
1) namespace
- can't override/be overridden
- allows shorter names
2) serializability
- portable
- maintains meaning when displayed in a debugger
The only advantage of constants is that some compilers may be able to
gain a small performance boost from this, but we're already assuming
for best optimization you'll want to determine the endian being used
at compile time, so I don't think it makes enough of a difference to
warrant the change.
--
Alex