[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
non-top-level DEFUN
- To: franz!sail.stanford.edu!cl-compiler
- Subject: non-top-level DEFUN
- From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
- Date: Mon, 20 Jun 88 22:36:10 EDT
Perhaps I've been on another planet, but I just realized a serious
problem with non-top-level function-defining DEF* forms.
Our interpreter will already handle the following without problem:
(let ((*foo* 3))
(defun set-foo (x) (setq *foo* x))
(defun get-foo (y) (cons *foo* y)))
So will our COMPILE-FILE. The problem comes when the above forms are
entered interpreted and subsequently a (COMPILE 'GET-FOO) is executed.
Interpreted and compiled closures have entirely different
representation, and it is impossible for compiled and interpreted
functions to share a closure. It would appear that the original CLtL
rules on closures and compilation are designed to permit this freedom,
although use of (SETF (SYMBOL-FUNCTION XXX #'(...))) can obviously
create named interpreted closure functions which subsequently one
could attempt to compile. No one has yet complained ...
I wonder if any other implementations will suffer the same problem?
Has anyone yet thought about this? Is the non-top-level-defun change
less compatible than we thought? Obviously, the compiler and
interpreter could be unified, but efficiency might suffer.