Re: A few more items on "Questions about specification and possible implementations"

[JonL.pa@XEROX.ARPA]

Oh, I forgot about this one
  ". . . to avoid consing a rest argument"
At the time that &rest arguments got standardized into Common Lisp, the
VAX/NIL was implementing them as vectors instead of lists. *** Thus
there was no consing for &rest args ***  and it's precisely the adoption
of a list versus a vector format that shafts a stock hardware
implementation (assuming stock hardware precludes cdr coding etc) to the
favor of the MIT Lisp Machine and it's descendents.

And
   "we could use the Vax SCANC instruction"
While having a string-scanning opcode is "nice" for a machine, that
doesn't necessarily mean that a function call to a function utilizing
that opcode is a burdensome overhead.  The "win" of a single opcode for
things like that is the low loop overhead (unless your implementation
simply cannot do any function call without incurring gross overhead).  A
"CAR" opcode, however, exhibits no "loop overhead".

The goal of PDP10 MacLisp was "speed at all costs"; to some degree, the
goal of Interlisp has been "programming aids at all costs".  I'll be the
first to admit that the perceived value of "speed at all costs" should
be diminished by 6 orders of magnitude compared to what it was 20 years
ago when the PDP10 architecture was being developed.  While TRACE may
not be the standard for "programming aids at all costs", still it is
useful not to have the compiler so effectively "hide" one's programs
that others cannot gain a good model of them from the source code.

-- JonL --