[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 7
- To: SEB1525@draper.com, cl-compiler@SAIL.STANFORD.EDU
- Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 7
- From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
- Date: Fri, 30 Dec 88 15:18 EST
- In-reply-to: The message of 30 Dec 88 07:50 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
Date: Fri, 30 Dec 88 07:50 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.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.
I guess i should have added "in the compilation environment".
>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?
Yes. But
(defstruct foo bar baz)
(defmacro frobnicate (...)
...
(frobulate #'foo-bar a)
...)
an expansion of a call to frobnicate can reasonably fail during
the compilation of a file containing those forms.
I should say this is my opinion on how this sort of stuff should work.
I didn't mean it to sound like i'm clarifying someone else's statements,
although hopefully I am.