<br><div class="gmail_quote">On Tue, Aug 7, 2012 at 9:09 PM, Erik Huelsmann <span dir="ltr"><<a href="mailto:ehuels@gmail.com" target="_blank">ehuels@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>> What happens is that the second form expands into:<br></div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>

><br>
> (PROG1 (SYSTEM:%DEFGENERIC 'DMC-TEST-ARGS-WITH-OPTIONAL.4A<br>
>                            :LAMBDA-LIST<br>
>                            '(X &OPTIONAL B)<br>
>                            :METHOD-COMBINATION<br>
>                            '(DMC-TEST-ARGS-WITH-OPTIONAL.4))<br>
>        (PUSH (DEFMETHOD DMC-TEST-ARGS-WITH-OPTIONAL.4A<br>
>                         (X &OPTIONAL B)<br>
>                         (PROGN X B))<br>
>              (SYSTEM:GENERIC-FUNCTION-INITIAL-METHODS (FDEFINITION 'DMC-TEST-ARGS-WITH-OPTIONAL.4A))))<br>
><br>
> Because the macro expander continues to expand the forms before compiling them, it'll expand the DEFMETHOD above. When the DEFMETHOD gets expanded however, it's expansion is dependent on the existence of the generic function. However, since the form as a whole hasn't been interpreted yet, there *is* no generic function: after all, that's being created in the first form of the PROG1.<br>


><br>
> Something similar probably happens during compilation.<br>
><br>
><br>
> I'm now wondering what the next step should be to resolve this situation...<br>
><br>
><br>
> Ah. Going back 10 months and looking at the DEFMETHOD macro there, I see now what the difference is between then and now: back then we didn't depend on the GF existing during the macro expansion. Now we do. Can we generate a different macroexpansion which defers the GF-being-defined requirement to evaluation time?<br>


<br>
</div></div>Cute.  I think we can beef up %defgeneric to accept a list of method descriptions and the macro environment (for make-method-lambda) and call ensure-method inside %defgeneric, after creating the generic function.  I can have a look at that.<br>

</blockquote><div><br></div></div><div>I can see how doing that would work at run-time, ie where %defgeneric would be called without the image having been exited (simply grab the environment and tuck it in a closure, or even simply stick it in the expansion). However, how do you expect to do the same at file-compilation time where the %defgeneric gets called after the image (possibly) has been closed and cleanly started up?</div>

<div></div></div></blockquote></div><br><div>Reading this quote:</div><div><br></div><div><b style="font-family:'Times New Roman';font-size:medium">Note:</b><span style="font-family:'Times New Roman';font-size:medium"> The body of methods can also appear in the </span><b style="font-family:'Times New Roman';font-size:medium">:initial-methods</b><span style="font-family:'Times New Roman';font-size:medium"> option of </span><b style="font-family:'Times New Roman';font-size:medium">defgeneric</b><span style="font-family:'Times New Roman';font-size:medium"> forms. Initial methods are not considered by any of the protocols specified in this document.</span>
</div><div><span style="font-family:'Times New Roman';font-size:medium"><br></span></div><div><span style="font-family:'Times New Roman';font-size:medium">from </span><a href="http://www.alu.org/mop/concepts.html">http://www.alu.org/mop/concepts.html</a></div>
<div><br></div><div>leaves me wondering if we're too strict to apply the requirement to use DEFMETHOD and MAKE-METHOD-LAMBDA processing the way we do now. Does this provide a way out?</div><div><br></div><div>Bye,</div>
<div><br></div><div><br></div><div>Erik.</div>