[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Date: Thu, 29 Dec 88  19:52:57 CST
 From: David N Gray <Gray@DSG.csc.ti.com>
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 7

> 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.

No, the processing of the accessor functions should expand to code which does
something equivelent to

    (progn
      (proclaim '(inline <accessor>))
      (defun <accessor> (structure)
        <code to access the appropriate element of structure>
        )
      ;; unless <accessor> is read-only
      (defsetf <accessor> (structure) (value)
        <expansion code to update the appropriate element of structure>
        )
      )

which does not make <accessor> defined at compile time (see DEFUN).

> 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.

> 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.  For example, if I compile a file containing
a defclass of fred, don't load it, and compile a file with a compile-time call
to find-class on fred with the appropriate compile-time &environment argument,
it should not be assumed that this will return the thing that got generated by
the first file (though I don't want to say it must not, since some
implementations seem to have different ideas about the survival of compilation
side-effects over multiple files). 

kab
-------