[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DISPLACE
- To: DLW at MIT-MC
- Subject: DISPLACE
- From: JONL at MIT-MC (Jon L White)
- Date: Fri, 21 Mar 80 01:32:00 GMT
- Cc: (BUG LISP) at MIT-MC, NIL at MIT-MC
- Original-date: 20 MAR 1980 2032-EST
Uh, after having read all my mail, I see what prompted
your enquiry. There is a point to what KMP has been
saying, which none of the discussion seems to have
noticed, that by making DISPLACE to be not very hairy
then:
1) it can serve as the canonical RPLACA and RPLACD
for **any** of the various macro-displacing schemes
which have abounded in the past two years - there is
the danger of one complicated macro-scheme thinking
that it is the *only* choice.
2) it can be the canonical place where the question of
clobbering a "pure" cell must be handled. RPLACA and
RPLACD are open-coded by maclisp, and one probably
wouldn't want the same pure-page-trap action/error to
be done for them as for DISPLACE. A close-compiled
function like DISPLACE can rather easily do a "purep?"
check by looking into the maclisp internal tables.
No, this purity check hasn't yet been done, but as you say,
"we should reason together about what the right thing is and
what should be done about it."
By the bye, I assume that everyone who has pitched in
a opinion so far is on one of the two mailing lists, BUG-LISP
and NIL. So it you didn't get this note, and had a strong
opinion, you should complain (I suppose).