[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.