[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Names and primitives in SRFI 56

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