Speaking of issues left of the Ballots ...

[MOON at SCRC-TENEX]

Sorry to be so slow in responding to this, the message got lost somehow.

    Date:  2 DEC 1982 0504-PST
    From: JONL at PARC-MAXC
    Subject: Speaking of issues left of the Ballots ...
    To:   common-lisp at SU-AI

    At the meeting in August, I mentioned that LOAD-BYTE and DEPOSIT-BYTE
    had been dropped without discussion.  
My memory is that it was discussed extensively.  Last spring, perhaps?
					  Around that time also,
    EAK and I offered reasons why they are better choices than LDB and
    DPB.  I hope that after considering them, you'll feel more inclined
    to at least include LOAD-BYTE in the white pages, regardless of the
    status of LDB.

    1) LDB presents us with a fatal flaw -- either we break compatibility
       with the LispMachine definition (and the PDP10 MacLisp definition)
       or we are stuck with a primitive which cant address more than 63
       bits worth of byte, nor any bits beyond the 64'th.  Despite the
       manual's best intention of abstracting the notion of a "byte
       specifier" (section 12.7), the LispM/MacLisp practice is to use a
       4-digit octal number.  When, in existing code, the bytespec
       isn't the PDP-10 determined 4 octal digits (say, some variable)
       then a mechanical converter *cant't* turn that code into
       the use of the BYTE function (unless "byte specifiers" are a new
       data type which will be type-certified by each use of LDB; for
       if such a conversion happened with out type-integrity, then assuming
       that a "byte specifier" is still some integer, there would be
       no guarantee that the conversion wasn't happening on an integer
       already converted elsewhere.
This is completely bogus.  The Lisp machine and Maclisp as they exist now
are not Common Lisp.  Of course all use of 4-digit octal numbers as arguments
to LDB will be replaced with use of the BYTE primitive.  I expect that
Symbolics will encourage this by using a different format of byte specifier
on each of its hardware lines.  And a macro named LDB can easily be
provided for programs that for some reason have not been converted to
Common Lisp but want to run in a Common Lisp system.  This incompatible
change to LDB is no worse than the incompatible change to MEMBER, which
also is not mechanically translatable in all cases.

    2) LDB and LOAD-BYTE tend to treat ingeters as sequences; as such, the
       syntax of subsequence specification is totally out of character with
       the other sequence functions.  At the very least, we should have
       (INTEGER-SUBSEQ <n> <start-position> &optional <end-position>)
       which would translate into something like a currently-defined LDB
       with bytespec of (BYTE (1+ (- <start> <end>)) <start>).  It may be
       that I've forgotten EAK's original complaint against LDB, but I
       thought it was essentially this.
This was discussed extensively last spring.  I think the conclusion was
that the analogy of integers to sequences was a false one, or that bit
vectors would be used in that case.  The problem with adding a SUBSEQ
function for integers is coming up with an excuse not to add all the
other sequence functions.  I would not be averse to adding such a function
if you really think it is important.  Note, however, that DPB has no analogue
among the sequence functions.

    3) the name Lid-ub (or Ell-dib, if you prefer) is the worst asssault on
       the reasonableness of names in the CommonLisp lexicon.  Who, who
       hasn't been contaminated with PDP10 lore, would think this an
       appropriate name?  How can a community as sensitive to the 
       implications of nomenclature as to change "haulong" into 
       "integer-length" not be swayed to prefer "integer-subseq" to L.D.B. 

Good names are hard to find, and heavily-used primitives (although perhaps
heavily-used only in systems programming) should have short names.  This is
why we renamed "DIFFERENCE" to "-".  LDB is not that good a name, but I
have seen no proposed alternatives that aren't inferior to it.  I think one
could do a lot worse in choosing a name for the byte extraction operation
than to follow the lead of the machine that was the standard Lisp engine
throughout the AI community for 15 years.

One reason for LOAD-BYTE that EAK brought up, which you did not include
in your message, is that it can be useful to specify the size and position
as separate arguments.  This is true.  I think you also pointed out that
LOAD-BYTE would generate better code on the VAX.  My feeling is that it
is extremely important that byte-specifiers be first-class data objects
(although no one has yet proposed that they print in a portable fashion),
and that (LDB (BYTE n-bits position) word) is slightly preferable to the
introduction of a new function LOAD-BYTE, and would generate precisely
the same code in any reasonable VAX compiler.