Issue:		COMPILE-ARGUMENT-PROBLEMS
References:	CLtL p. 438-439
		Issue FUNCTION-TYPE
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION, CHANGE
Edit History:   V1, Sandra Loosemore  (8 Aug 1988)
		V2, Sandra Loosemore  (21 Sep 1988)
		V3, Sandra Loosemore  (14 Oct 1988)


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. 


Proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY:

If the optional "definition" argument to COMPILE is supplied, it may
be either a lambda expression (which is coerced to a function) or a
function to be compiled.  Otherwise, the SYMBOL-FUNCTION of the symbol
is extracted and compiled.  It is an error if the function to be
compiled was defined interpretively in a non-null lexical environment.
The consequences of calling COMPILE on a function that is already compiled
are unspecified.

Clarify that a symbol which names a macro may also be passed to COMPILE.
(Both macros and functions may be compiled.)


Rationale:

Saying "it is an error" to try to compile the wrong kind of function
allows implementations that can compile functions defined in a
non-null lexical environment to go ahead and do so. 


Current Practice:

Implementations that do not allow sharing of lexical environments
between compiled and interpreted functions include VaxLisp, Allegro
CL, and Lucid.  Lucid and VaxLisp already accept an interpreted function 
object as the "definition" argument to COMPILE.


Cost to implementors:

Most of the changes required for this proposal are already necessary
to correctly implement the FUNCTION-TYPE proposal.  The primary addition
is that COMPILE must be extended to accept a FUNCTION object as well
as a lambda expression as the "definition" argument.


Cost to users:

None.  This is an upward-compatible change, since a lambda expression
can still be passed as an argument to COMPILE.  Also, since most
existing implementations refuse to compile a function with a non-empty
lexical environment, user code which depends on being able to do this
is already nonportable. 


Benefits:

An area of ambiguity in the language is resolved.


Discussion:

Acceptable behavior for COMPILE when it receives a function that is
already compiled might include doing nothing; performing more compilation
(if the function is only partially compiled); or retrieving the source
code and recompiling it.  It is not acceptable to "crash and burn" or
signal an error.