At Tue, 28 Sep 2004 13:34:44 -0700 (PDT), xxxxxx@autodrip.bloodandcoffee.net 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