issue CONSTANT-FUNCTION-COMPILATION

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

Moon has suggested that we split off the issue of compiling constant
functions from issue CONSTANT-COMPILABLE-TYPES and call it
CONSTANT-FUNCTION-COMPILATION.  This would allow us to have real
proposals written down in advance instead of trying to compose
amendments on the fly at the meeting (which rarely seems to work out
very well), and keep the arguments over this from bogging down the
rest of issue CONSTANT-COMPILABLE-TYPES, which appears to be
noncontroversial. 

The issue is not only whether functions are dumpable, but if they are,
how COMPILE-FILE and LOAD arrange for the function to be
reconstructed.  If we can't arrive at a good definition of what
"similar as constants" means for functions, I contend we must leave
the entire question of their dumpability unspecified.

The current language from issue CONSTANT-COMPILABLE-TYPES says that
two (non-compiled, non-closed) functions are similar as constants if
their SOURCE-LAMBDA-EXPRESSIONs are similar as constants.  I assume
this was a typo for FUNCTION-LAMBDA-EXPRESSIONs, except that
FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
can't figure out what the original source code looked like.  My
feeling is that this definition of "similar as constants" is
unacceptable because of this.

So, if any of you have some specific language to propose here, 
speak up.  Otherwise I think we have no choice but to say that
constant functions are not supported.

-Sandra
-------