lisp; new recent

[MOON at MIT-MC (David A. Moon)]

## is no longer used and should be flushed.
#\FORM should be defined; this is what is written on the key on
 Knight and LM keyboards, and therefore should be the preferred
 name of the key.
#\BACK-NEXT is missing.

I don't see how the change to the order of evaluation of STORE
can work, particularly in compiled code.  Has this really been tested?
Does (STORE (APPLY ...) ...), which Macsyma uses, still work?

SETF has to be a macro, not an FSUBR.  Or else MACROEXPAND has to know
about it specially.  The property which controls SETF should be called
SETF, not SETF-X.  This is for Lisp machine compatibility and because
it is useless to introduce another name when the name of the property
can reflect the function which it controls.

LDB and DPB in the Lisp machine work on bignums.  Much of our software
that runs in Maclisp (where they are sometimes called LOGLDB and LOGDPB)
depends heavily on this.  Evidently yours only accept fixnums?  The pp
field in a byte-pointer should not be limited to 2 octal digits, but should
simply be (// ppss 64.); this is important when dealing with bignums.

LOAD-BYTE and DEPOSIT-BYTE do not work exactly as documented.  The
documentation needs to make clear that the bit position is the number
of the high-order bit counting from LEFT TO RIGHT, i.e. the number of
bits to the left of the byte IN A FIXNUM.  Better than this crockish
machine-dependency would be to number the bits from right to left in
the standard way, as LDB and DPB do, avoiding dependency on machine
word-length.  Consider what LOAD-BYTE and DEPOSIT-BYTE would do in NIL.

I fail to understand this example; &WHOLE is meaningless in anything
other than DEFMACRO.
	    (DEFUN FOOM (&WHOLE X) <mumble>)  would bind X just like
	    (MACRO FOOM (X) <mumble>)

Why do useratoms-hooks NCONS their return values, since the value,
being a form evaluated for some kind of side-effects, will surely
be non-NIL?

The change to eliminate automatic insertion of CR's seems wrong.
Isn't what you want to retain automatic insertion of CR's, but NEVER
within an atom?  Thus formerly extra-long atoms would be broken with
a CR in the middle, but now they would result in extra-long lines,
but normal output will not contain extra-long lines.

The following features seem reasonable to adopt in the Lisp machine.
I'll put them in when I return to the east coast.

SPRIN1
EOF-COMPILE-QUEUE  (This supersedes EOC-EVAL, doesn't it?)
STATUS FILESYSTEM-TYPE, OPSYSTEM-TYPE, SITE(?)
Hacking of + in read-eval-print loop.
&WHOLE in DEFMACRO but not in DEFUN (we probably already have this).