[Armedbear-devel] Strange behaviour of unexporting and defpackage

Erik Huelsmann ehuels at gmail.com
Sun Jan 11 17:58:25 UTC 2015

Hi Eitaro,

On Sun, Jan 11, 2015 at 6:30 PM, Eitaro Fukamachi <e.arrows at gmail.com>

> This is a reproducible script.
> ----
> (defpackage unexport-test
>   (:export :a))
> (eval-when (:compile-toplevel :load-toplevel :execute)
>   (when (find-package :unexport-test)
>     (do-symbols (symbol :unexport-test)
>       (unexport symbol :unexport-test))))
> (defpackage unexport-test
>   (:export :a))
> (prin1 (nth-value 1 (intern (string :a) :unexport-test)))
If cl-colors depends on this behaviour, it's depending on behaviour the cl
spec explicitly named "undefined". From the spec:

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
third sentence in the Description section)

the important bit is "an implementation *might* 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

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!




http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150111/63750385/attachment.html>
-------------- next part --------------
Armedbear-devel mailing list
Armedbear-devel at common-lisp.net

More information about the armedbear-devel mailing list