issue COMPILED-FUNCTION-REQUIREMENTS, version 3

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

It didn't seem like proposal FLUSH had much support, so I've FLUSHed it.  :-)
In its place I've added proposal TIGHTEN-COMPILE, which retains the
COMPILED-FUNCTION type but doesn't place quite as many restrictions on
it as proposal TIGHTEN.  (This is the proposal I sketched out verbally
at the January meeting.)  I also made a few minor clarifications to the
wording of proposal TIGHTEN.


Forum:		Compiler
Issue:		COMPILED-FUNCTION-REQUIREMENTS
References:	CLtL p. 32, 76, 112, 143, 438-439
		Issue FUNCTION-TYPE (passed)
		Issue COMPILER-LET-CONFUSION
		Issue EVAL-WHEN-NON-TOP-LEVEL
		Issue LOAD-TIME-EVAL (passed)
Category:	CLARIFICATION
Edit History:   V1, 3 Jan 1989 Sandra Loosemore
		V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
		V3, 10 Feb 1989, Sandra Loosemore (new proposal)
Status:		**DRAFT**


Problem Description:

There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs.  Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs?  Are implementations required to
distinguish between compiled and non-compiled functions?

CLtL defines a COMPILED-FUNCTION as "a compiled code object".  (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.)  Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.

The description of COMPILE in CLtL says that "a compiled-function object
[is] produced".  It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions.  CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.


Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:

(1) Clarify that if a function is of type COMPILED-FUNCTION, the
    following are guaranteed about the function:

    - All macro calls appearing lexically within the function have 
      already been expanded and will not be expanded again when the
      function is called.  (See CLtL p. 143.)

    - COMPILER-LETs nested lexically within the function will not bind 
      any variables when the function is called (CLtL p. 112).

    - If the function contains lexically nested EVAL-WHENs, only the 
      LOAD (and not the EVAL) situation is applicable.

    - If the function contains lexically nested LOAD-TIME-VALUE forms,
      these have already been pre-evaluated and will not be evaluated
      again when the function is called.

(2) Implementations are free to classify all functions as 
    COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
    listed in item (1).  It is also permissible for interpreted FUNCTIONs
    to satisfy the above criteria but not be distinguished as
    COMPILED-FUNCTIONs.

(3) Clarify that COMPILE always produces an object of type 
    COMPILED-FUNCTION.  Clarify that when functions are defined in a 
    file which is compiled with COMPILE-FILE, and the compiled file is
    subsequently LOADed, objects of type COMPILED-FUNCTION result.


  Rationale:

  This proposal allows users to count on COMPILE and COMPILE-FILE always
  producing objects that are COMPILED-FUNCTION-P.

  It assigns some specific properties to compiled functions.  Users would
  be able to rely on any function which is of type COMPILED-FUNCTION having
  really been (at least partially) compiled.

  It also states what many people believe to be the minimum functionality 
  required of a compiler.


Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN-COMPILE:

(1) Clarify that functions produced by COMPILE, or defined in a file
    that is compiled with COMPILE-FILE and then LOADed must satisfy
    the same requirements listed in section (1) of proposal TIGHTEN.

(2) Clarify that COMPILE always produces an object of type 
    COMPILED-FUNCTION.  Clarify that when functions are defined in a 
    file which is compiled with COMPILE-FILE, and the compiled file is
    subsequently LOADed, objects of type COMPILED-FUNCTION result.

  Rationale:

  This proposal allows users to count on COMPILE and COMPILE-FILE always
  producing objects that are COMPILED-FUNCTION-P.

  It also states what many people believe to be the minimum functionality 
  required of a compiler.
  
  However, it allows functions that have not been compiled also to be of
  type COMPILED-FUNCTION.  For implementations that do not use different
  representations for interpreted and compiled functions, it would still
  allow COMPILED-FUNCTION and FUNCTION to be synonymous, even if
  interpreted functions do not satisfy the requirements for compilation.



Current Practice:

It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation.  It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.

A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.

On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.


Cost to implementors:

Unknown, but probably small for either proposal.  Proposal 
TIGHTEN-COMPILE is probably most consistent with current practice.


Cost to users:

Probably minimal.  Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.


Benefits:

The specification of what the compiler must do is made more explicit.


Discussion:

The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers.  Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.

David Gray notes:

  We make good use of the type COMPILED-FUNCTION in our implementation,
  but all of the accessor functions for objects of that type are
  non-standard, which makes me wonder if it might be best to just remove
  this type from the standard along with BIGNUM.

One use of the COMPILED-FUNCTION type is in declarations.  A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION.  However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION.  Both of the proposals presented require COMPILE
and COMPILE-FILE to construct compiled functions.
-------