[1] LIST* [2] LOAD-BYTE

[GLS at MIT-AI (Guy L. Steele, Jr.)]

CC: GLS at MIT-AI, (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI

[1] LIST* of zero arguments ought to be an error, as has
    already been pointed out.  I originally wanted (LIST* a) => a,
    but forget whether that was done originally or not.
[2] [a] Regarding byte pointers, the LISP Machine syntax still has the
    two severe disadvantages that (i) you can't parse it unless it is
    in octal notation, and (ii) the byte size is limited to 63 decimal.
    I have in the past suggested that a function BPTR be introduced
    such that (BPTR p s) takes two non-negative fixnums p and s and
    produces a byte pointer.  The nature of this pointer is machine-
    dependent, but may be given to the LOAD-BYTE etc. functions
    and be expected to work.  Probably also there would have to be
    functions BPTR-SIZE and BPTR-OFFSET to extract the s and p
    numbers from a byte pointer.
    The advantages of this are several.
    (i) Neither p nor s is limited in value by these definitions.
    (ii) The precise representation of a byte pointer can be machine-dependent
    for greater efficiency.  For example, the LISP Machine byte pointer
    format is not suitable for the VAX.
    (iii) When writing (BPTR p s) one can write p and s in whatever radix
    one pleases.
    [b] Regarding left-to-right versus right-to-left, I would suggest that
    bits always come out in right-to-left order *when converted to fixnums*
    for the reasons expounded by Moon.  Thus (LOAD-BYTE #B"0101100" (BPTR 2 3))
    produces the fixnum 6.  (Are not bits naturally numbered this way
    anyway in the VAX?)  For machine-@dependent crocks, a machine-dependent
    set of primitives may also extract byte in whatever way is convenient
    for the machine.
    The S-1 will store bits in left-to-right order (bag-biters they),
    but the compiler will gladly output bit-reverse instructions to keep
    this compatible interpretation (eliding them when possible).