Re: issue COMPILED-FUNCTION-REQUIREMENTS

[David N Gray <Gray@DSG.csc.ti.com>]

I agree that the type COMPILED-FUNCTION currently lacks a portable
meaning, and some kind of clarification is in order.  While the
definition you propose sounds reasonable, I'm not sure how useful it
would be.  Having determined that an object satisfies
COMPILED-FUNCTION-P, you would know it possesses these characteristics,
but so what?  What would you do with it differently depending on that?

I hadn't thought about this before, but just off hand the only useful
portable interpretation for this I can think of would be:

 * An object that satisfies COMPILED-FUNCTION-P is a valid argument for
   DISASSEMBLE.
 * An object that satisfies FUNCTION-P but not COMPILED-FUNCTION-P is
   a reasonable argument to be passed to the COMPILE function.
   (However, it still might not be valid if it is an interpreter
   closure.)

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.

By the way, for the "current practice" section, on the 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.  So this proposal would be a change
for us, but now that I think about it, the current behavior doesn't seem
to fit too well with the definition of COMPILED-FUNCTION-P in CLtL.

Our implementation also has a confusion about whether microcoded
functions should be considered compiled or not.