Issue: FUNCTION-TYPE (version 3)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 11 May 1987  15:55 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Edit History:   Version 1 by RPG 02/26/87
		    Version 2 by cleanup committee 15-Mar-87
		    Version 3 by SEF 10-May-83

I (apparently somewhat belatedly!) approve of FUNCTION-TYPE:REDEFINE
except with the following two caveats:

    No sub-types of FUNCTION are defined in Common Lisp, but implementations
    are free to define subtypes of FUNCTION.  Examples might be
    COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.

Common Lisp currently defines a type-specifier named COMPILED-FUNCTION.
Is this a proposal to remove it?  I would probably support such a proposal,
but it should be explicit.

    If COMPILE is called with no definition supplied, then it will attempt
    to compile the current global definition of the symbol <name>, and will
    signal an error if it is unable to do so.  In some implementations, an
    interpeted function can be compiled individually only if it contains no
    references to lexical context outside the function definition.  If the
    symbol's definition is already compiled, no error is signalled.  An
    implemenation may choose to recompile the function if the original
    interpreted form is available; otherwise, this is a no-op.

The phrase "signal an error if it is unable to do so" is new.  My
problem is that the concept of "unable to compile" is not defined and is
open to varying interpretations.  For example, does this mean that if
any compiler warnings are issued, COMPILE should signal an error at the
conclusion of the compilation?  Also, if we assume that the word
"should" used on CLtL p.439 is covered by the discussion of "must" on
CLtL p.6, then right now this "is an error" rather than "signals an
error."  Also, the specification that COMPILE is a no-op if called with
one argument and the symbol's definition is already compiled appears to
be a change from CLtL, although CLtL is so ambiguous it's hard to be
sure.

Unless there are reasons that these changes to COMPILE must be
incorporated into this proposal, I think it would be better to deal with
them as a separate proposal.  For this proposal, I suggest confining the
discussion to how COMPILE defaults its second argument.  I would say
that if the second argument is not supplied, the first argument "should"
be a symbol that is FBOUNDP and for which the implementation is able to
reconstruct the lambda-expression corresponding to its definition.  So
the only change from CLtL would be to change "a definition that is a
lambda-expression" to "a definition from which the implementation is
able to reconstruct a lambda-expression".  Possibly we should try to state
some necessary conditions under which the implementation is required to
be able to recover the lambda-expression.  Possibly we shouldn't; this
only points out the inherent uselessness of 1-argument COMPILE in
portable programs.

Alternatively, we could take the coward's way out and make both
arguments to COMPILE be required, or, even better, make COMPILE take
only one argument, which must be a lambda expression, and neither read
nor write SYMBOL-FUNCTION.