[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issues from last meeting
- To: email@example.com
- Subject: Issues from last meeting
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Sun, 7 Aug 88 12:12:29 MDT
Well, our suggested August 1 deadline for comments on the three
proposals that were distributed at the last meeting has come and
gone, and the only comment I'm aware of getting is the following
Date: Mon, 20 Jun 88 22:36:10 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Subject: non-top-level DEFUN
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.
I agree that this is a problem. I see three possible solutions:
(1) Require all implementations to be able to have closures shared by
interpreted and compiled functions.
(2) State that it is an error to COMPILE a function defined in a non-null
(3) Throw out our current proposal for DEFINING-MACROS-NON-TOP-LEVEL and
go back to the drawing board.
I believe that solution (2) is a reasonable compromise between the
other two extremes. In fact, I think this should be a proposal
separate from DEFINING-MACROS-NON-TOP-LEVEL since the issue can come
up even without using a DEFUN inside of a LET (as by SETF'ing the
SYMBOL-FUNCTION to a function defined in a non-null environment). The
current language in CLtL is not very clear on this issue anyway -- if
you provide a definition to COMPILE it must be a (quoted) lambda
expression, and if you don't it says the symbol's definition must be a
lambda expression. This is already nonsensical because the
FUNCTION-TYPE proposal accepted at the last meeting states that the
SYMBOL-FUNCTION must contain a FUNCTION, not a lambda expression.
I'll sketch out a proposal on this unless somebody comes up with a
better idea in the next couple of days.