<div class="gmail_quote">On Sat, Feb 13, 2010 at 3:23 PM, Waldek Hebisch <span dir="ltr"><<a href="mailto:hebisch@math.uni.wroc.pl">hebisch@math.uni.wroc.pl</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">Juan Jose Garcia-Ripoll wrote:<br>
> Your problem is related to a similar one, namely the use of DEFPACKAGE forms<br>
> in compiled files. It is commonly agreed that DEFPACKAGE (and by that<br>
> rational other package changing forms) should be compiled in separate files,<br>
> precisely because otherwise there are problems like the one you find.<br>
><br>
<br>
</div>Hmm, maybe the file changed, but I do not see DEFPACKAGE<br></blockquote><div><br></div><div>I did not say that DEFPACKAGE was there, but that the issues are related.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
: A file containing compiled code is called a compiled file. Loading a<br>
: compiled file is similar to loading a source file, except that the file<br>
: does not contain text but rather an implementation-dependent<br>
: representation of pre-digested expressions created by the compiler.<br>
<br>
AFAICS this implies seqential treatment of top-level form, unless<br>
some other parts gives explicit permission for more loose<br>
interpretation.  In particular one can expect side effect on package<br>
system to take place before "similarity" is used to restore object<br>
from next top level form.</blockquote><div><br></div><div>This implies sequential EXECUTION of toplevel forms. It does not imply that the constants referenced in the toplevel forms have to be created sequentially. There is a difference between the forms that are executed and the content of those forms. The predigested forms do contain all constants and objects which are needed. In particular, symbols. The previous paragraph only imposes that the forms are executed sequentally, not WHEN the objects that constitute those forms are created.</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
</blockquote><div>What you are asking is something similar to changing the readtable between two forms which are sequentially read from a source file. This can be done in a source file but not in a compiled file. Or would you expect it to behave the same?</div>
<div><br></div><div><div>Furthermore, the same expectations that motivate this discussion would also lead newbies to think that if I compile function</div><div>   (defun foo (x)  'my-changing-package:some-symbol)</div>
<div>the output should change if I decide to shadow my-changing-package:some-symbol and replace it with some other reference.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> It is explicitely vague about when objects are<br>
> created. Otherwise it would impose inefficient object creation mechanisms,<br>
> such as lookup by name for *every* symbol in the file.<br>
><br>
<br>
</div>Well, surely you need to lookup every _symbol_ in the file: if at<br>
compile time symbols are different you expect to get different<br>
symbols after loading.  If you mean lookup at every occurence of<br>
a symbol, then there is no such need: just keep translation table<br>
during loading and do lookup for first occurence (more precisely<br>
before evaluating toplevel form with the first occurence).</blockquote><div><br></div><div>Yes, we do lookup objects but you are imposing that references to objects must be created every time they are used, because previous forms may change the similarity relation. That means for instance that object creation must happen as the binary file is executed, maybe before each toplevel form, that constant coalescion is not possible, that we would have to insert explicit C statements to create objects instead of a using global table, and other things that enlarge code and make it less efficient.</div>
<div><br></div><div>I think ECL is consistent in its behavior: all constants are created at load time and shared by the whole compiled file. This includes symbols. If a constant must depend on the precise order in which toplevel forms are executed then it is not a constant and should be replaced with a variable or some other lisp expression.</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://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>