issue COMPILE-ARGUMENT-PROBLEMS

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I took the liberty of writing a version of this based around the
comments I made following your last proposal. The Proposal part
is very different, but I think it is "doable" in most implementations.
Personally, I think this proposal will be a lot more useful in
practice. I hope others will agree.
 -kmp

------
Issue:		COMPILE-ARGUMENT-PROBLEMS
References:	CLtL p. 438-439
		Issue FUNCTION-TYPE
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION, CHANGE
Edit History:   08-Aug-88, Version 1 by Sandra Loosemore
	        02-Jan-89, Version 2 by Pitman

Problem Description:

 The description of what arguments can legitimately be passed to the
 function COMPILE in CLtL is too vague.  There are two specific
 problems:
 
 (1) Acceptance of the FUNCTION-TYPE proposal makes it nonsensical to
     speak of a lambda-expression being an interpreted function (it is not)
     or to require a symbol to have a lambda-expression as its definition
     (the SYMBOL-FUNCTION must be a true FUNCTION object).

 (2) Many implementations cannot correctly compile functions that are
     defined interpretively in a non-null lexical environment, because the
     compiler and interpreter use different representations for closures.
     Although this problem arose in conjunction with the
     DEFINING-MACROS-NON-TOP-LEVEL proposal, the situation can also arise
     if SETF is used to store a lexical closure in the SYMBOL-FUNCTION of
     the symbol. 

 (3) Compiled-only implementations are caught in a bind because the
     one-argument case as described in CLtL can never not signal an error:
     the contents of the function cell are always compiled.

Proposal (COMPILE-ARGUMENT-PROBLEMS:HARMLESS):

 Change the description of COMPILE to say that the function to be
 compiled may be either a lambda expression (as permitted by CLtL)
 or a function (as described by the FUNCTION-TYPE proposal). If the
 definition is a lambda expression, it is coerced to a function.

 If the definition to be compiled is already compiled, the implementation
 is permitted to treat the compilation step as an identity. In any case,
 the implementation must not signal an error.

 If the definition to be compiled is a function which was enclosed in
 a non-null lexical environment and the compiler cannot compile the
 function, the compiler is permitted to treat the compilation step
 as an identity.

 If the definition to be compiled is a macro or special form definition,
 the compiler is permitted to treat the compilation step as an identity.

 If an implementation is interpreted-only, the compiler is permitted
 to treat the compilation step as an identity.

 The intent is that the COMPILE function should signal an error only if
 it receives an argument which is not the name or definition of a valid
 function, macro, or special form.

 The intent is that COMPILE should be a permissible way to attempt to
 `speed up' any operator definition. Implementations are encouraged to
 implementation useful facilities toward this end. However, if a 
 definition cannot be `sped up' for some reason (for example, the
 definition is already compiled, or there is some limitation of the
 compiler), the original definition should be used where feasible.

 For example, it should in general be permissible to do:
   (DO-SYMBOLS (SYMBOL package)
     (IF (FBOUNDP SYMBOL) (COMPILE SYMBOL)))
 to `speed up' the functions in some PACKAGE.

Rationale:

 This provides a consistent interpretation of COMPILE which is useful
 in portable code in interpreted-only, compiled-only, or hybrid 
 interpreted/compiled implementations.

 The definition is flexible enough to permit implementations to skip
 compilation in situations where the implementor deems it unreasonable.

Current Practice:

 Implementations that do not allow sharing of lexical environments
 between compiled and interpreted functions include VaxLisp, Allegro
 CL, and Lucid.

 Lucid and Symbolics already accept an interpreted function object
 as the "definition" argument to COMPILE.

 Symbolics Genera signals an error if you try to compile an 
 already-compiled function.

Cost to implementors:

 Very small. This is really just a change in the COMPILE function
 interface, not in the compiler itself.

Cost to users:

 None. Some cases which used to signal an error will no longer signal
 an error.

Benefits:

 This definition makes for a more useful interpretation of the
 one-argument case of COMPILE in compiled-only implementations.

 Uses of COMPILE will be more portable. 

Cost of Non-Adoption:

 The definition of COMPILE will be a real mess.

Discussion:

 Pitman supports this proposal.