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 12:05:34 MST
    
    > Date: Thu, 16 Mar 89 13:42:07 EST
    > From: Dan L. Pierson <pierson@mist.encore.com>
    > 
    > One of Kent's points in earlier discussion was that it should (read
    > MUST) be safe to blindly apply to COMPILE to any symbol with a
    > function definition.  I thought there was general agreement on this.
    > If the lastest draft contradicts this then it needs to be fixed.
    
    The current wording (from proposal COMPILE-ARGUMENT-PROBLEMS) says
    "it is an error".  My recollection is that we agreed to an editorial
    change to "the consequences are unspecified", assuming the error
    terminology ever gets sorted out.
    
    Now that I think about the interaction between the two proposals, it
    does seem like there is a problem -- we can't require a
    COMPILED-FUNCTION to be returned and leave the behavior unspecified at
    the same time.  I think we need to do one of two things:
    
    (1) Require COMPILE to signal an error if it can't return a 
        COMPILED-FUNCTION.
    
    (2) Say that COMPILE is required to return a COMPILED-FUNCTION only
        in the situations that are not unspecified.
    
    Any further thoughts on this?  My personal leanings are towards
    signalling an error.
    
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.  Specifically, it should be legal and safe to
attempt to speed up my current program(s) by doing:

    (DO-SYMBOLS (SYM <my-package>)
    	(WHEN (FBOUNDP SYM) (COMPILE SYM)))