lisp; new recent

[Robert W. Kerns <RWK at MIT-MC>]

Some things I leave to JONL to answer, but...
    Date: 21 November 1979 17:54-EST
    From: David A. Moon <MOON at MIT-MC>
    To:   BUG-LISP
    cc:   MOON
    Re:   lisp; new recent


    SETF has to be a macro, not an FSUBR.  Or else MACROEXPAND has to know
    about it specially.
I assume you hold the same view of PUSH and POP?  I sort of feel the same way,
but don't have good arguments.  Perhaps you can supply same.  In particular,
why is it important that MACROEXPAND expand SETF/PUSH/POP ?  I'd really feel
much better if you could convince us.

    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.

The main reason for it being a different name is because it operates
differently.  It's rather complicated, so I'll write it up elsewhere, but what
it's all about is avoiding multiple evaluations of arguments to PUSH and POP.
DEFSETF hides this hair from the user.

    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.

Should we make + work on bignums too, like the Lisp Machine?  Admitedly, this
isn't quite as clear as that, but I'm not sure we want to give up the
efficiency...  Maybe optimizing the case where the arguments are declared
fixnums is enough though.

    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?
I don't know why you think the value will be a form evaluated for some kind of
side-effects!!

    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.
Yes, I thought this was what JONL and I agreed was the right thing.

    EOF-COMPILE-QUEUE  (This supersedes EOC-EVAL, doesn't it?)
I dunno.  I never did figure out what EOC-EVAL was for, so I don't know
if it superscedes it.  It might be kind of awkward to use EOF-COMPILE-QUEUE
for EOC-EVAL's.

    &WHOLE in DEFMACRO but not in DEFUN (we probably already have this).
I think &WHOLE in DEFUN was a documentation bug.  I'll change it.