This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.
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