195 lines
12 KiB
HTML
195 lines
12 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue CLOS-MACRO-COMPILATION Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss050_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss051.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss052_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss050_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss051.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss052_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue CLOS-MACRO-COMPILATION Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Compiler<P>
|
|
<B>Issue:</B> <A HREF="iss051.htm">CLOS-MACRO-COMPILATION</A><P>
|
|
<B>References:</B> CLOS chapters 1 & 2 (88-002R)<P>
|
|
CLOS chapter 3 (89-003)<P>
|
|
Issue <A HREF="iss059.htm">COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS</A><P>
|
|
Issue <A HREF="iss104.htm">DEFINING-MACROS-NON-TOP-LEVEL</A><P>
|
|
<B>Category:</B> CLARIFICATION<P>
|
|
<B>Edit History:</B> V1, 10 Mar 1989, Sandra Loosemore<P>
|
|
V2, 13 Mar 1989, Sandra Loosemore<P>
|
|
V3, 21 Mar 1989, Sandra Loosemore (fix error language)<P>
|
|
V4, 11 Jun 1989, Sandra Loosemore (Gregor's amendment)<P>
|
|
V5, 23 Jun 1989, Sandra Loosemore (wording changes per Pitman)<P>
|
|
<B>Status:</B> Proposal MINIMAL passed, June 89<P>
|
|
Recommendation to drafting committee: clarify that the <P>
|
|
provisions listed under <A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A> are intended to affect <P>
|
|
warnings emitted by the compiler.<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Do the CLOS defining macros (<A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A>, <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A>, <A REL=DEFINITION HREF="../Body/m_defgen.htm#defgeneric"><B>DEFGENERIC</B></A>, and<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defi_4.htm#define-method-combination"><B>DEFINE-METHOD-COMBINATION</B></A>) have compile-time side-effects similar<P>
|
|
to those for <A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> or DEFMACRO?<P>
|
|
<P>
|
|
A part of the problem is that we do not currently have a full<P>
|
|
understanding of all the issues involved. In particular, work on<P>
|
|
defining the CLOS meta-object protocol is still in progress. The goal<P>
|
|
of this proposal is to say enough about the behavior of these macros<P>
|
|
in the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> so that users can use them portably in compiled code,<P>
|
|
but to leave as much of the behavior as possible unspecified to avoid<P>
|
|
placing undue restrictions on the meta-object protocol.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal CLOS-MACRO-COMPILATION:MINIMAL:<P>
|
|
</B><P>
|
|
State that top-level calls to the CLOS defining macros have the<P>
|
|
following compile-time side-effects. Any other compile-time behavior<P>
|
|
is explicitly left unspecified.<P>
|
|
<P>
|
|
DEFCLASS:<P>
|
|
<P>
|
|
* The <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> name may appear in subsequent type declarations.<P>
|
|
<P>
|
|
* The <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A> name can be used as a specializer in subsequent <P>
|
|
<A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> forms.<P>
|
|
<P>
|
|
DEFGENERIC:<P>
|
|
<P>
|
|
* The generic function can be referenced in subsequent <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> forms. <P>
|
|
<P>
|
|
* <A REL=DEFINITION HREF="../Body/m_defgen.htm#defgeneric"><B>DEFGENERIC</B></A> does not arrange for the generic function to be callable<P>
|
|
at compile time.<P>
|
|
<P>
|
|
DEFMETHOD:<P>
|
|
<P>
|
|
* <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> does not arrange for the <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> to be callable at compile<P>
|
|
time. If there is a generic function with the same name defined at<P>
|
|
compile time, compiling a <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> does not add the <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> to that <P>
|
|
generic function. (That is, the <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> is added to the generic<P>
|
|
function only when the <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> is actually executed.)<P>
|
|
<P>
|
|
The error-signalling behavior described in the specification of<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> in CLOS chapter 2 (if the function isn't a generic function<P>
|
|
or if the lambda-list is not congruent) happens only when the defining<P>
|
|
form is executed, not at compile time.<P>
|
|
<P>
|
|
The forms in <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> specializers are evaluated when the defining form<P>
|
|
is executed. The compiler is permitted to build in knowledge<P>
|
|
about what the form in an <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> specializer will evaluate to in cases<P>
|
|
where the ultimate result can be syntactically inferred without<P>
|
|
actually evaluating it.<P>
|
|
<P>
|
|
DEFINE-METHOD-COMBINATION:<P>
|
|
<P>
|
|
* The <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> combination can be used in subsequent <A REL=DEFINITION HREF="../Body/m_defgen.htm#defgeneric"><B>DEFGENERIC</B></A> forms. <P>
|
|
<P>
|
|
The body of a <A REL=DEFINITION HREF="../Body/m_defi_4.htm#define-method-combination"><B>DEFINE-METHOD-COMBINATION</B></A> form is evaluated no earlier <P>
|
|
than when the defining macro is executed and possibly as late as <P>
|
|
generic function invocation time. The compiler may attempt to<P>
|
|
evaluate these forms at compile time but must not depend on being able<P>
|
|
to do so.<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
The compile-time behavior of <A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A> is similar to <A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> or<P>
|
|
<A REL=DEFINITION HREF="../Body/m_deftp.htm#deftype"><B>DEFTYPE</B></A>. <P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defgen.htm#defgeneric"><B>DEFGENERIC</B></A> and <A REL=DEFINITION HREF="../Body/m_defmet.htm#defmethod"><B>DEFMETHOD</B></A> are similar to <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A>, which doesn't add the<P>
|
|
function definition to the compile-time environment. Since generic<P>
|
|
functions may be freely redefined between compile and run time (just<P>
|
|
like any other function), a <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> may end up "belonging" to a<P>
|
|
different generic function at load time than at compile time. This<P>
|
|
is why it is inappropriate to signal errors about congruency problems<P>
|
|
(etc) until the <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> is actually added to the generic function at<P>
|
|
run time.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
The items listed under <A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A> in proposal MINIMAL are fairly <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A><P>
|
|
programming style.<P>
|
|
<P>
|
|
Flavors does not support compile-time instantiation of classes. It<P>
|
|
does not make <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> combinations available at compile-time either, but<P>
|
|
Moon considers that to be a bad design choice.<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Unknown.<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Unknown, but probably fairly small.<P>
|
|
<P>
|
|
Wrapping an (<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> (<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> <A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>) ...) around the appropriate<P>
|
|
definitions will make sure they are fully defined at compile-time.<P>
|
|
Alternatively, the definitions could be placed in a separate file,<P>
|
|
which is loaded before compiling the file that depends on those<P>
|
|
definitions.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Programmers can rely on programs that use the CLOS defining macros <P>
|
|
being able to compile correctly in all implementations, without having<P>
|
|
to wrap explicit EVAL-WHENs around every macro call.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This writeup is based on discussions between Moon, Gray, and<P>
|
|
Loosemore, who are mostly in agreement on the things presented in<P>
|
|
proposal MINIMAL. We have purposely avoided saying anything about<P>
|
|
whether meta-objects representing the classes, methods, etc. get<P>
|
|
created at compile-time, or whether such meta-objects are fully or<P>
|
|
partially defined. The basic questions addressed by this issue are<P>
|
|
what kinds of things can be defined and then used during compilation<P>
|
|
of the same file that defines them, and what restrictions might apply.<P>
|
|
<P>
|
|
These proposals are not completely compatible with the meta-object <P>
|
|
protocol document (89-003). Gregor Kiczales says:<P>
|
|
No one believes that what is written in draft 10 of the MOP is valid.<P>
|
|
<P>
|
|
Sandra Loosemore says:<P>
|
|
Although I admit I don't understand all of the issues involved with<P>
|
|
the meta-object protocol, I prefer proposal MINIMAL over <P>
|
|
NOT-SO-MINIMAL. I don't think leaving the issue of whether or not<P>
|
|
classes can be instantiated at compile-time unspecified places an<P>
|
|
undue burden on users, and it does leave more freedom for the<P>
|
|
meta-object protocol to decide what the right behavior really is.<P>
|
|
<P>
|
|
Dick Gabriel notes:<P>
|
|
The question I have about the process going on with respect to the<P>
|
|
<A HREF="iss051.htm">CLOS-MACRO-COMPILATION</A> issue is whether the fine-grained behavior of<P>
|
|
CLOS under various compilation/evaluation situations is being<P>
|
|
over-specified. <P>
|
|
<P>
|
|
At this stage of the game I worry that we might go a little too far in<P>
|
|
one direction in specification when we are actually engaged in design<P>
|
|
work. This isn't intended to be a criticism of any committees, but I<P>
|
|
would feel a lot more comfortable with a conservative specification<P>
|
|
that defined well-formed programs being loaded or compiled in fresh<P>
|
|
Common Lisps with a pretty simple <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>eval-when</B></A> model that is easier to<P>
|
|
specify and which makes it easy for all but the hairiest<P>
|
|
compilation-environment-frobbing programs to be written.<P>
|
|
<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|