Re: Function constants

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

[CC'ed to cl-compiler.]

> Date: Sun, 23 Apr 89 20:52:30 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
> 
> The first question is what it means to be a function constant.  It
> doesn't mean a constant function, which is a function that returns the
> same thing every time it's called. But, does it mean that it has
> an alterable environment?

I would define a function constant as an object of type FUNCTION that
appears as a quoted or self-evaluating form.  (This is quite distinct
from a FUNCTION special form.)

> The second question is how do you dump such a thing as a function.
> Well, if your compiler can compile-file this you are part way there:
> 
> (defun f (x y) (+ x y))
> 
> That is, you can dump and load functions.

No, this is a FUNCTION special form, not a function constant.  What
you are dumping and loading is code which will create a function
object when executed, not the function object itself.

> So the remaining problem is how to dump ``code vectors.'' This is
> simple if you have position-independent code, because then you just
> dump the bits as if it were a bit-vector. The question is whether we
> wish to support machines that have no such thing as position
> independent code or do we wish to require implementations to keep
> relocation information around (which they will anyway if they can
> garbage collect code and compact the space). [Note that the
> environments have to be put in something other than a readonly space,
> one that the GC sees.]

I agree this is the main question from an implementation point of
view.  I know that for some implementations (i.e., UCL), this
requirement would be a major headache. 

I'd argue that since this isn't compatible with current practice, and
is a lot of work to implement, that it probably isn't a good thing to
require unless doing so would provide some desperately needed
functionality that is now missing from the language.  I question
whether the need for the ability to dump function constants is really
all that great.  I'm having a hard time even coming up with a
realistic example that could not also be handled using
LOAD-TIME-VALUE.

There is also a problem with dumping closures that you didn't mention.
Unless the object is looked up "by name" by the loader, the dump/load
process inherently creates a copy of the original object.  Closure
environments are no exception to that rule, which could lead to some
unexpected behavior.

> An alternative to the function constant problem is as follows: We
> state that compilation is meaningful in only two situations: COMPILE
> in an image with no dumping allowed and COMPILE-FILE in a fresh Lisp
> where the compilation will not load any compiled code, where only one
> compilation unit will be compiled, and where the result will be loaded
> in a copy of the same fresh Lisp that was used to do the compilation.
> Calls to COMPILE are allowed in the second scenario.  (That is, you
> start a lisp, compile-file, quit, start afresh that same Lisp, load.)
> 
> In these two cases we can allow the free use of functions as constants
> because either there is no need to dump stuff, or else all the source
> code that is needed can be made available. That is, in this case, all
> the functions that could be constants have either had their source
> examined and saved by the very compiler doing all the work or else are
> functions in the Common Lisp package, which can be dumped by name.

We've already said that it's OK for function constants to appear in
code processed by COMPILE or EVAL -- issue QUOTE-SEMANTICS said that
constraints on what kinds of objects can appear in constants apply
only to COMPILE-FILE, and that COMPILE never copies. 

I'd accept a statement that your second case is the only situation in
which function constants seen by COMPILE-FILE make sense, but saying
that's the only situation in which compilation with COMPILE-FILE is
meaningful seems like it's going way too far in the wrong direction.
Random people picking up the Common Lisp standard would get a very bad
impression of the language from seeing a restriction like that, and
it's certainly not consistent with current practice.

-Sandra
-------