Newsgroups: comp.lang.lisp
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!defmacro.utah.edu!moore
From: moore%defmacro.utah.edu@cs.utah.edu (Tim Moore)
Subject: Re: compiling lambda-CLOSUREs
Date: 3 Apr 91 09:53:36 MST
Message-ID: <1991Apr3.095336.29725@hellgate.utah.edu>
Keywords: was monitoring functions
Organization: University of Utah CS Dept
References: <14172@medusa.cs.purdue.edu>

In article <14172@medusa.cs.purdue.edu> yeh@cs.purdue.EDU (Wei Jen Yeh) writes:
>(defun monitor_1fun (fname)
>  (if (fboundp fname)
>      (if (get fname 'monitored)
>          (format T "Function ~A is already being monitored." fname)
>          (let ((old_fun (symbol-function fname)))
>               (setf (get fname 'monitored) old_fun)
>               (setf (symbol-function fname)
>                     #'(lambda (&rest args)
>                               (start_bench fname)
>                               (multiple-value-prog1 (apply old_fun args)
>                                                     (end_bench fname))))
>;               (compile fname)
>               (setq *Monitor_List* (cons fname *Monitor_List*))
>               *Monitor_List*))
>      (format T "function ~A is not defined." fname)))
>
>However, the commented compile call failed.  Is there any reason (both
>in theory/implementation) why a lambda-closure cannot be compiled?  Why
>doesn't the standard (ep, ip) trick work?

If monitor_1fun is compiled, then the closure is also already
compiled. The result of calling COMPILE on a compiled function is
unspecified. (Indeed, the call to COMPILE is unecessary.)

However, if monitor_1fun is interpreted, then you are trying to
compile an interpreted closure. Although CLtL1 didn't say much on
this, X3J13 voted to not allow this in portable programs. From CLtL2
(pg 677): 

"It is an error if the function to be compiled was defined
interpretively in a non-null lexical environment. (An implementation
is free to extend the behavior of COMPILE to compile such functions
properly, but portable programs may not depend on this capability.)"

It should be obvious why compiling a closed "lambda expression" (as if
there was any such thing) doesn't work; same reason that they can't be
EVAL'ed. 

There are several problems that come up when compiling interpreted
closures. The biggest one I can think of is dealing with the object
that represents the closed-over environment. Normally, when compiling
files, if the compiler encounters an object (such as an array), it can
treat it as a constant and proceed. But in this case, not only is the
environment object not constant, it has to be the same (i.e., EQ)
object that was used in the interpreted function, because other
functions may be closed over it too. It may be unreasonable to make
the compiler deal with this special case.

Also, compiled and interpreted code may use different representations
of closed-over environments. In this case it would be impossible to
compile an interpreted closure because other interpreted functions
might be sharing the same environment.

Tim
-- 
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters