[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lisp; new recent
- To: MOON at MIT-MC
- Subject: lisp; new recent
- From: Robert W. Kerns <RWK at MIT-MC>
- Date: Thu, 22 Nov 79 05:28:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 22 November 1979 00:28-EST
Some things I leave to JONL to answer, but...
Date: 21 November 1979 17:54-EST
From: David A. Moon <MOON at MIT-MC>
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
I don't know why you think the value will be a form evaluated for some kind of
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
&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.