[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Poor SETF, revisited ["yea, me worry"]
- To: JONL at MIT-MC
- Subject: Poor SETF, revisited ["yea, me worry"]
- From: George J. Carrette <GJC at MIT-MC>
- Date: Wed, 29 Oct 80 19:20:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 29 October 1980 14:20-EST
Date: 29 OCT 1980 1401-EST
From: JONL at MIT-MC (Jon L White)
cc: (BUG LISP)
Re: Poor SETF, revisited ["yea, me worry"]
Uh, George, the problem just can't be laid at the feet of SETF, no
matter what system facilities it uses.
I'm not laying them at the feet of SETF, I am laying them at the
feet of JONL! The provided system facilities are not sufficient
to handle SETF.
That the problem is still more general should have been evident from
the FIND-PROJECTION example, but to help visualize it again, just
imagine redefining the function LAST.
Redefine LAST? Are you feeling O.K. today?
Your proposal re SETF -- that of never memoizing -- would
be a narrow (and very costly!) solution.
Hey, I said you might as well just DISPLACE. Which costs even less than
memoizing, and takes a lot less crufty code in your defmacro's.
But you didn't comment on my two suggestions, which would work for
a rather wide variety of environment changes; did you understand them?
I did comment, I said "why should you have to do stuff like that
by HAND?" The comparison with UUOLINKS was a real win too. I never
did understand why DEFUN didn't take care of UUOLINKS for you either!!!
Why reset the UUOLINKS for the world when you only want to do it for
a single function?
p.s. I think it goes without saying that the "GENERAL PROBLEM"
deals with what files/functions need to be recompiled when
macros are changed etc. Already dealt with quite well on the
lisp machine. My main comment is that this MACROMEMO stuff is
an ill-working special case of that.