Issue CONSTANT-FUNCTION-COMPILATION Writeup

Forum:		Compiler

Issue:		CONSTANT-FUNCTION-COMPILATION

References:	Issue CONSTANT-COMPILABLE-TYPES

Category:	CLARIFICATION

Edit History:   V1, 22 Mar 1989, Sandra Loosemore (split from issue

			CONSTANT-COMPILABLE-TYPES)

Status:		**DRAFT**



Problem Description:


Can objects of type FUNCTION (or some subset of FUNCTIONs) appear as

quoted or self-evaluating constants in compiled code?  


There are two questions that must be answered:


- How does one test whether a particular function is a member of the

  subset of functions that are dumpable?


- For those functions that are dumpable, how do COMPILE-FILE and LOAD

  arrange for an "equivalent" copy of the function in the source code to

  be created in the compiled code?


This writeup uses terminology from issue CONSTANT-COMPILABLE-TYPES:

"source code", "compiled code", and "similar as constants".



Proposal CONSTANT-FUNCTION-COMPILATION:NO:


  Objects of type FUNCTION are not supported in compiled constants.


 Rationale:


  Nobody has been able to come up with a well-defined specification of

  how the compiler and loader would be required to reconstruct

  function constants that would work for all functions.


  Nobody has been able to come up with a well-defined specification of

  some subset of functions that could be dumped.



Current Practice:


  Coral can dump compiled functions, but not foreign functions.

  

  The TI Explorer cannot dump closures (either compiled or evaluated),

  but can dump non-closure compiled functions.


  Symbolics Genera can't dump closures either.


  Kyoto Common Lisp can't dump any functions.



Cost to implementors:


  None.  Implementations that can dump (some subset of) functions may

  continue to do so, since issue CONSTANT-COMPILABLE-TYPES permits

  implementations to extend the notion of "similar as constants".



Cost to users:


  None.  Programs that depend on being able to dump functions are

  already nonportable, since not all implementations can dump all

  functions and there is no portable way to construct or test for

  functions that are dumpable in those implementations.



Benefits:


  Users will know what to (or what not to) expect when using functions

  in compiled constants.



Discussion:


This issue was split from issue CONSTANT-COMPILABLE-TYPES because it

appeared to be controversial enough to merit separate discussion.


Cris Perdue originally suggested:


  Only function constants that are not compiled-functions and do not

  close over any (lexical) variables are supported in compiled

  constants.


  Two such functions are similar as constants if their

  SOURCE-LAMBDA-EXPRESSIONs are similar as constants.


Dick Gabriel responded:


  I guess I pretty strongly object to leaving functions out of the list

  of constants that can appear in compiled code. The part that's

  disturbing is that such non-Lispy things like arrays, hashtables, and

  pathnames get better treatment than functions, the most Lispy part of

  Common Lisp. I wonder how many implementations will be forced to come

  within an inch of the required functionality to implement a first-rate

  CLOS?


  The specification of the subset of functions that are acceptable as

  compiled constants cannot be tested for within Common Lisp itself.


  I suggest we ask implementors (Lucid included) to bite the bullet and

  handle this case correctly. Won't our grandchildren appreciate us

  treating Common Lisp like Lisp and not like PASCAL?


If we were to specify that all functions could appear as constants, we

would also need to clarify whether the closed-over variable bindings

become immutable, and also deal with whether bindings that are closed

over more than one function retain their uniqueness.  Also, the cost

to implementors to add support for dumping non-interpreted functions

may be quite high.