[Armedbear-devel] Strange behaviour of unexporting and defpackage
Hi ABCL developers, I found a strange behaviour of cl-colors happening only on ABCL. [Issue] Symbols won't be exported on ABCL https://github.com/tpapp/cl-colors/issues/6 Though cl-colors unexports all symbols before defpackage when reloading the system, the :export clause in defpackage seems to be ignored. https://github.com/tpapp/cl-colors/blob/master/package.lisp#L5-L19 Any ideas? Regards, Eitaro _______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
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))) #+sbcl (sb-ext:exit) #-sbcl (cl-user::quit) ---- $ sbcl --load unexport-test.lisp :EXTERNAL $ ccl --load unexport-test.lisp :EXTERNAL $ abcl --load unexport-test.lisp :INTERNAL 深町英太郎 (Eitaro Fukamachi) On Sun, Jan 11, 2015 at 6:50 PM, Eitaro Fukamachi <e.arrows@gmail.com> wrote:
Hi ABCL developers,
I found a strange behaviour of cl-colors happening only on ABCL.
[Issue] Symbols won't be exported on ABCL https://github.com/tpapp/cl-colors/issues/6
Though cl-colors unexports all symbols before defpackage when reloading the system, the :export clause in defpackage seems to be ignored. https://github.com/tpapp/cl-colors/blob/master/package.lisp#L5-L19
Any ideas?
Regards, Eitaro
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hi Eitaro, On Sun, Jan 11, 2015 at 6:30 PM, Eitaro Fukamachi <e.arrows@gmail.com> wrote:
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 http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defpac..., 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 DEFPACKAGE form... 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! Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. _______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hi Erik, Thank your for your response.
If cl-colors depends on this behaviour, it's depending on behaviour the cl spec explicitly named "undefined".
It explains clearly. Actually, I was not sure this was a bug of ABCL or not.
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.
Though it could cause a portability issue, as long as the behaviour isn't defined in the spec, I'm not willing to change the behaviour of ABCL for now. I'm gonna change cl-colors instead. Best, Eitaro On Mon, Jan 12, 2015 at 2:58 AM, Erik Huelsmann <ehuels@gmail.com> wrote:
Hi Eitaro,
On Sun, Jan 11, 2015 at 6:30 PM, Eitaro Fukamachi <e.arrows@gmail.com> wrote:
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 http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defpac..., 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 DEFPACKAGE form...
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!
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
participants (2)
-
Eitaro Fukamachi -
Erik Huelsmann