Re: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, v7

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

> No, the processing of the accessor functions should expand to code which does
> something equivelent to
> 
>     (progn
>       (proclaim '(inline <accessor>))
>       (defun <accessor> (structure)
...
> which does not make <accessor> defined at compile time (see DEFUN).

Yes, it could be recorded for inline expansion without making it
executable in the compile time environment, but our implementation uses
the same mechanism for both, so proclaiming it inline also makes it
available to be called at compile-time.  The question is whether the
standard intends to say that such an implementation approach is not
valid.

> > DEFCLASS:  ... and for use as the :METACLASS option of a subsequent
> > DEFCLASS.
> 
> No, because doing so would require that the class be instantiable, so that you
> can make instances whose class is the metaclass, for descrimination purposes.
> That's what having it available as a metaclass is all about.  I seem to
> remember somewhere in the CLOS spec the caveat that a class had to be fully
> defined before it could be used as a metaclass argument to defclass, presumably
> for this reason.

It could be fully defined in the compile-time environment.  It isn't
clear whether the designers of CLOS intended being able to use a
metaclass in the same file in which it is defined, but the concepts of
anonymous classes and looking up class definitions in the compile-time
environment means that it is certainly possible to instantiate classes
that are defined only in the compile-time environment.

> > 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. 
> 
> This should perhaps be tightened up a bit.  For example, the &environment
> argument should have been generated by the same invocation of the compiler as
> that which processed the defclass. 

Yes, I agree that environments should be viewed as having dynamic
extent.  I'm not sure, though, whether this proposal is the right place
to say that.