[Armedbear-devel] Strange behaviour of unexporting and defpackage

[Eitaro Fukamachi]

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 at gmail.com> wrote:

> Hi Eitaro,
>
> On Sun, Jan 11, 2015 at 6:30 PM, Eitaro Fukamachi <e.arrows at 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_defpackage.html,
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150112/ebd49f5e/attachment.html>
-------------- next part --------------
_______________________________________________
Armedbear-devel mailing list
Armedbear-devel at common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel