Upcoming Manual work, and Compatibililty issue.

[JonL.PA@PARC-MAXC.ARPA]

    Presumably you're just fixing errors in the manual and not soliciting
ballot-able questions.  Sooner or later the issue will have to be addressed about 
a formal mechanism for changes and additions -- wasn't it our idea early on that
at some infrequent interval (6 months, 1 year?) we'd open things up for some
hopefully conservative changes?

    Also, about a week ago I sent out a note to Common-Lisp%SU-AI@SU-SCORE
which hasn't appeared in my mail box yet, so I presume it to have been
lost in the shuffle.  The gist of this note was ask for re-confirmation of our
original mandate of remaining generally compatible with MacLisp/LispM,
unless there were verry good reason; thus APPEND remains for lists only (using
a new function CONCATENATE for the others), and the name change of
HAULONG to INTEGER-LENGTH was ocasioned only after a ballot vote.

    Since the deletion of LOAD-BYTE etc didn't go to the ballots, we may need
to re-consider it; especially if the only solution to the quagmire I pointed out
in December last is to force a totally incompatible change onto the MacLisp/
LispM world.  A change, I might  add, which would do them no good at all,
since they've had LOAD-BYTE etc for many years;  VAX/NIL had it from the
beginning, and merely used it to build up whatever semantics LDB required
(the VAX has a load-byte-indexed instruction -- EXTZV).
    Last fall, I put LOAD-BYTE and LDB (as specified in the "Laser Edition) into
Interlisp.   Since Interlisp-D has neither a load-byte-indexed nor a ldb
instruction,  I did it by macros which merely convert LDB into LOAD-BYTE
format, and others which convert LOAD-BYTE into more primitive Lisp (which
is fully adequate, given the bytelap instruction set).  
    There has frequently been a misconception that the "conversion" just
mentioned is a compiler question;  I haven't maintained this position, and I don't
know why it keeps popping up like a red herring; it is just macro-expansion.  
The only non-trivial functions needed by the expanders were one which tested 
a form for being a constant under EVAL, and another which tested if two forms
were EVAL-independent (and thus commutable when computing them).  These
two functions needn't be complete; simply being fail-safe is adequate, but the
more "complete" they become, the more efficient will be the output of the 
various macros.
    This code, although copyright by Xerox, would, I'm sure, be publicly
available to anyone who wants it.

    Ocasionally, there has been confusion as to the value of having
integers and bit-vector sequences as separate types.   I've long ago pointed
out the desirablilty of not constraining the way in which the various
implementations must implement integers.   But bit-vector semantics requires
updating, which would rule out "immediate" number formats; they also require
storage according to length, which would impose, say, zeros of differing
integer-lengths -- a most odd and non-canonical, but not entirely impossible,
situation for numbers.  Others have recently made similar points in these mails.
    The confusion comes by overkill -- the idea that since there are two
distinct data types, then integers can't be viewed as sequences.  For an
early counter to this notion, see Goedel's 1931 paper on the essential
incompleteness of axiomatic arithmetic.  Even the current notion, spawned
as it is by the existence of binary storage devices, is machine independent.
(Think about why we have INTEGER-LENGTH.)  The constraint is merely
that bit-vectors must not be limited to our efficiently-implemented integers.

    Incidentally, the pdp10 LDB instruction is surely a cretinous remnant of
the fact that the pdp6/pdp10 didn't have any notion of load-byte-indexed.
Evidentally, ILDB was the provision so that one could "walk" through a
sequence of bytes without doing the division inherent in load-byte-indexed;
LDB was an obvious "corollary".  It should be no surprise that division on
the pdp6 was abysmally slow.
    Newer hardware often has a single instruction to do the load-byte-indexed,
indicating its utility over the ldb format.  In Lisp, there  is no particularly
good reason to have a byte specifier as an independent data type -- a cons
of two indices would serve just as well -- just as there is no reason to
suppose that a "subsequence specifier" (used, say, to specify the 3rd through
5th elements of a vector) is a pressingly useful concept.