Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 7

[Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>]

    Date: Thu, 29 Dec 88  19:52:57 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    >     DEFSTRUCT: The compiler must make the structure type name recognized
    >     as a valid type name in subsequent declarations (as for DEFTYPE) and
    >     make the structure slot accessors known to SETF.  In addition, the
    >     compiler must save enough information about the structure type so that
    >     further DEFSTRUCT definitions can :INCLUDE a structure type defined
    >     earlier in the file being compiled.  The functions which DEFSTRUCT
    >     generates are not defined at compile time. 

    Shouldn't that last sentence say something like "... need not be defined
    ..."?  Since the accessor functions commonly default to INLINE, they
    often will be defined at compile time.

That doesn't follow:  they only need to be properly compiled, not executed.
Having something be defined just so it can be inlineable can be a bad idea.
Similarly, i'd suggest that wording similar to that used below that i have
marked be used for describing the availability of slots to SETF, so as to not
imply that compilation of a defsetf must side-effect the runtime environment.

    >     DEFCLASS, DEFMETHOD, DEFGENERIC, DEFINE-METHOD-COMBINATION:  More input
    >     is needed from the CLOS committee to decide what to do with these
    >     macros.

    Since I've been working on compiler updates for supporting CLOS, let me
    take a stab at this:

	DEFCLASS:  The compiler must make the class name be recognized as a
	valid type name in subsequent declarations (as for DEFTYPE) and be
	recognized as a valid class name for DEFMETHOD parameter
	specializers and for use as the :METACLASS option of a subsequent
->	DEFCLASS.  The compiler must make the class definition available to
->	be returned by FIND-CLASS when its environment argument is a value
->	received as the &ENVIRONMENT parameter of a macro.