<div class="gmail_quote">On Thu, Mar 18, 2010 at 1:36 AM, Robert Goldman <span dir="ltr"><<a href="mailto:rpgoldman@sift.info">rpgoldman@sift.info</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">Is it possible that somehow the compilation of asdf-ecl is recording</div>
some information about the package that is somehow damaged by the<br>
package surgery?<br></blockquote><div><br></div><div>I will dig into that later during the weekend. I think the point is something we discussed long at the ECL mailing list, namely that symbols are NOT created as a compiled file is run. Symbols are constants and as such a compiler is allowed to coalesce all references to symbols in the same compiled file.</div>
<div><br></div><div>The problem would thus be the following. The compiler loads the file, it resolves all references to symbols, storing them in the array of constants, including PERFORM. The code is executed. PERFORM is uninterned and a new symbol is created. We reach the DEFMETHOD forms, which now are executed but since they reference the *old* version of the symbol, the method is installed with the wrong name in the wrong generic function.</div>
<div><br></div><div>In other words, one can not expect the side effects that operations have in packages work the same for a compiled and a source file. It is just as if you expect that the side effects that aare caused by changing the readtable would also affect the way a cmpiled file behave.</div>
<div><br></div><div>Juanjo</div></div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>