Re: issue status, 12/12/88

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

      COMPILER-DIAGNOSTICS 
        The NOTICE condition type hasn't happened yet.  I was going to change
        references to the NOTICE condition to the STYLE-WARNING condition,
        which is a subtype of warning (allowing user condition handlers to use
        the MUFFLE-WARNING restart on it to suppress the messages).  Any 
        objections?
    
The NOTICE condition type is created by this proposal.  There is no
need for any other action.  I object to its removal on the grounds
that a separate issue to create it hasn't been passed in some other
place (are you thinking of Cleanup?).

      COMPILER-VERBOSITY
        Pierson indicated he wanted to submit an alternate proposal on this
        issue, but hasn't done so.  Can/should we go ahead with the current
        proposal?
    
A new (two proposal, sigh) version will immediately follow this reply.

      DEFINING-MACROS-NON-TOP-LEVEL
      EVAL-WHEN-NON-TOP-LEVEL
        There's been a suggestion that defining macros should only cause
        compile-time side effects at top level, and that (EVAL-WHEN
        (COMPILE)...)  should be a no-op except at top level.  Is this
        agreeable to everybody?
    
I have no objections.

      QUOTE-MAY-COPY
        Do we really need all three options in the latest writeup?
    
ALWAYS and NOT-EVAL (:-)) can go away as far as I'm concerned.

      FILE-COMPILATION
        same issue as CONSTANT-COMPILABLE-TYPES
    
I don't agree that this is just the same as CONSTANT-COMPILABLE-TYPES.
While I don't necessarily support FILE-COMPILATION as it stands, I do
support Kent and Jeff's belief that we need to simplify some of these
issues, provide some sort of unifying framework, and not sacrifice the
traditional strengths of Lisp to support simple file-compilation-only
implementations.