[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 7
- To: cl-compiler@SAIL.STANFORD.EDU
- Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 7
- From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
- Date: Fri, 30 Dec 88 07:50 EST
> 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.
Don't the DEFSTRUCT functions have to be compiled so that is it possible to
have things like
(defstruct foo bar baz)
(let ((a (make-foo)))
(frobulate #'foo-bar a))
...assuming that frobulate is unknown at compile time or otherwise cannot be
expanded inline? This is the basic reason that DEFSTRUCT accessor forms
were changed from macros to functions in CL, right?