<div>Your problem is related to a similar one, namely the use of DEFPACKAGE forms in compiled files. It is commonly agreed that DEFPACKAGE (and by that rational other package changing forms) should be compiled in separate files, precisely because otherwise there are problems like the one you find.</div>
<div><br>What is the problem then? The ANSI specification says that COMPILE-FILE must create a file that is used by the loader in a two-step way: reconstruct literal objects and execute forms. The order in which the object reconstruction happens is unclear and not specified. ECL, GCL and probably other lisps create the objects before ANY form is executed. Then any use of those objects is done by reference to the created objects.</div>
<div><br>Object creation must happen by a notion of "similarity" : <a href="http://www.lispworks.com/documentation/HyperSpec/Body/03_bdbb.htm">http://www.lispworks.com/documentation/HyperSpec/Body/03_bdbb.htm</a> For instance if the compiler finds a symbol hu.dwim.common::in-package in the compiled file, it will look up at load time an object with the same name IN-PACKAGE that is accessible from that package.</div>
<div><br></div><div>Note that the specification says "at load time" but it does not says at the time the form is executed. It is explicitely vague about when objects are created. Otherwise it would impose inefficient object creation mechanisms, such as lookup by name for *every* symbol in the file.</div>
<div><br></div><div>The problem in your example is that the file where hu.dwim.common::in-package appears is changing the symbol that this printed representation denotes. It does so at execution time, and in the case of ECL after a reference to a similar object has been resolved. In other words, you are changing what is "similar" while executing the first form.</div>
<div><br></div><div>In the case under question, I would advise to use DEFPACKAGE in a separate file and forge about explicit package manipulations.</div><div><br></div><div>Juanjo<br><br><div class="gmail_quote">On Sat, Feb 13, 2010 at 9:01 AM, Alexander Gavrilov <span dir="ltr"><<a href="mailto:angavrilov@gmail.com">angavrilov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Could you also comment on the troubles that happen over here?<br>
<br>
<a href="http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.def;a=headblob;f=/integration/common.lisp" target="_blank">http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.def;a=headblob;f=/integration/common.lisp</a><br>

<br>
Namely (and in case the above link is temporarily<br>
unavailable), the original non-ecl code is as follows:<br>
<br>
#-ecl<br>
(eval-when (:compile-toplevel :load-toplevel :execute)<br>
  (unintern 'common-lisp:in-package :hu.dwim.common)<br>
  (shadow "IN-PACKAGE" :hu.dwim.common))<br>
<br>
#-ecl<br>
(eval-when (:compile-toplevel :load-toplevel :execute)<br>
  ;; this export is not inside the above eval-when for a reason.<br>
  (export 'hu.dwim.common::in-package :hu.dwim.common)<br>
  (assert (not (eq 'hu.dwim.common::in-package 'common-lisp:in-package))))<br>
<br>
#-ecl<br>
(def macro hu.dwim.common::in-package (package-name)<br>
   ...)<br>
<br>
When one tries to use it with ECL, the compiling part seems<br>
to work as expected, and the symbol is recorded in the fasl<br>
as hu.dwim.common::in-package. However, when it is loaded,<br>
the references are resolved before any code is executed,<br>
so the assertion fails - and if it is removed, the macro<br>
definition overwrites the original common-lisp macro with<br>
disastrous consequences.<br>
<font color="#888888"><br>
Alexander<br>
</font><div><div></div><div class="h5"><br>
> The error is very subtle. You have to go here<br>
>    <a href="http://www.lispworks.com/documentation/HyperSpec/Body/03_bcaa.htm" target="_blank">http://www.lispworks.com/documentation/HyperSpec/Body/03_bcaa.htm</a><br>
><br>
> define-symbol-macro does not have compile-time side effects. That means that<br>
> when the compiler reaches the form (defvar a m) it does not know that M is a<br>
> macro! This causes a load time error because the code is designed to find<br>
> out the value of the variable "M", not to use "tstst".<br>
<br>
</div></div></blockquote></div><br><br clear="all"><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>

</div>