CLHS: Issue CONSTANT-FUNCTION-COMPILATION Writeup

#

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

Copyright 1996-2005, LispWorks Ltd. All rights reserved.