Issues from last meeting

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

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
 from Steve:

  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
    lexical environment.

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

-Sandra
-------