<div dir="ltr">Hi Eitaro,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 11, 2015 at 6:30 PM, Eitaro Fukamachi <span dir="ltr"><<a href="mailto:e.arrows@gmail.com" target="_blank">e.arrows@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>This is a reproducible script.</div><div><br></div><div>----</div><div>(defpackage unexport-test</div><div>  (:export :a))</div><div><br></div><div>(eval-when (:compile-toplevel :load-toplevel :execute)</div><div>  (when (find-package :unexport-test)</div><div>    (do-symbols (symbol :unexport-test)</div><div>      (unexport symbol :unexport-test))))</div><div><br></div><div>(defpackage unexport-test</div><div>  (:export :a))</div><div><br></div><div>(prin1 (nth-value 1 (intern (string :a) :unexport-test)))</div><div><br></div></div></blockquote><div><br></div><div>If cl-colors depends on this behaviour, it's depending on behaviour the cl spec explicitly named "undefined". From the spec:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition. (see <a href="http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defpackage.html">http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defpackage.html</a>, third sentence in the Description section)<br></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>the important bit is "an implementation <i>might</i> choose to modify"; ABCL currently is an implementation that doesn't modify. Essentially this means you can - in ABCL's current implementation - just leave out the second DEFPACKAGE form...</div><div><br></div><div>Of course, if you say this is pretty rare when compared to other implementations, I think we should seriously consider accepting a patch to change the behaviour. Do you know what the *exact* behaviours of SBCL and CCL are? Maybe it's not too hard to implement one of the two. Patch submission always very much welcome as well, of course!</div><div><br></div><div><br></div><div>Regards,</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</div></div>