[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Speaking of issues left of the Ballots ...
- To: common-lisp at SU-AI
- Subject: Speaking of issues left of the Ballots ...
- From: MOON at SCRC-TENEX
- Date: Tue, 21 Dec 1982 01:37:00 -0000
- In-reply-to: The message of 2 DEC 1982 0504-PST from JONL at PARC-MAXC
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.