Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4

[Dan L. Pierson <pierson@mist.encore.com>]

    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
    Date: Thu, 16 Mar 89 13:09:11 MST

    > Date: Thu, 16 Mar 89 14:18:10 EST
    > From: Dan L. Pierson <pierson@mist.encore.com>
    > 
    > What I (and believe Kent) want is a guarantee that it won't signal an
    > error; if nothing else works COMPILE will simply apply #'IDENTITY to
    > the symbol's function.
    
    If this is the position people really want to adopt, I think we ought
    to flush the COMPILED-FUNCTION type.  I can't imagine it would be
    very useful in declarations if we always allow COMPILE to be a no-op
    and never require it to return a COMPILED-FUNCTION.
    
While I would expect that a COMPILE which resulted in IDENTITY would
not necessarily make the function a COMPILED-FUNCTION, I have absolutely no
objections to flushing the type.

    I still think that the minimum requirements for compilation specified in
    the proposal should apply to COMPILE-FILE, regardless of what happens
    to COMPILE and COMPILED-FUNCTION.
    
I agree.  I would also accept a requirement that COMPILE could cause a
function to become a COMPILED-FUNCTION iff it met the minimum
requirements in the proposal.  Note this could still mean, for a
function in which a prepass caused no changes, that IDENTITY could
cause the function to become a COMPILED-FUNCTION.  While this may
sound a bit absurd it's consistent with the position we seem to be
adopting that, COMPILE is "macroexpand-completely" in an
interpreted-only implementation.