Hi,
When I unintern a symbol from a package, i was expecting it to disappear.
In Lispworks, it just seems to be unbound, it this correct behavior?
---
Cheers,
Chris "ski" Kacoroski "When we try to pick out anything by itself
···@grace.rt.cs.boeing.com we find it connected to the entire universe"
John Muir
Code for symbols in package problem
SIS 1 > (defpackage "A" (:use "COMMON-LISP"))
SIS 2 > (in-package "A")
A 3 > (defun list-package-symbols (&optional (pack *package*))
"ski-06/08/93: Function that returns all the symbols in a package,
not symbols inherited from other packages"
(loop for x being each present-symbol in pack
collect x into p-list
finally (return p-list)))
LIST-PACKAGE-SYMBOLS
A 4 > (setf test 10)
TEST
A 5 > (list-package-symbols)
(LIST-PACKAGE-SYMBOLS P-LISP X PACK TEST)
A 6 > (unintern 'test)
T
A 7 > (list-package-symbols)
(LIST-PACKAGE-SYMBOLS P-LISP X PACK TEST)
A 8 > (unintern 'TEST)
T
A 9 > (list-package-symbols)
(LIST-PACKAGE-SYMBOLS P-LISP X PACK TEST)
A 10 > test
Error: the variable TEST is unbound
1 (continue) Try evaluating it again
2 Return a value to use
3 Return a value to set it to
4 (abort) return to level 0.
5 return to top loop level 0.
6 Destroy process.
A 11 : 1 > :a
A 12
In article <······················@grace.rt.cs.boeing.com> ···@grace.rt.cs.boeing.com writes:
>When I unintern a symbol from a package, i was expecting it to disappear.
>In Lispworks, it just seems to be unbound, it this correct behavior?
No. Something seems to be causing a new symbol with the same name to be
created, which is why it's unbound. But I can't explain why that new
symbol would be getting created, and I can't reproduce your problem in
Lucid CL.
In article <······················@grace.rt.cs.boeing.com> ···@grace.rt.cs.boeing.com (Chris Kacoroski,none) writes:
When I unintern a symbol from a package, i was expecting it to disappear.
In Lispworks, it just seems to be unbound, it this correct behavior?
No, but I don't think this is exactly what's happening. See below.
Code for symbols in package problem
SIS 1 > (defpackage "A" (:use "COMMON-LISP"))
SIS 2 > (in-package "A")
A 3 > (defun list-package-symbols (&optional (pack *package*))
"ski-06/08/93: Function that returns all the symbols in a package,
not symbols inherited from other packages"
(loop for x being each present-symbol in pack
collect x into p-list
finally (return p-list)))
LIST-PACKAGE-SYMBOLS
A 4 > (setf test 10)
TEST
A 5 > (list-package-symbols)
(LIST-PACKAGE-SYMBOLS P-LISP X PACK TEST)
(That should be P-LIST, not P-LISP. But it's not the problem anyway.)
A 6 > (unintern 'test)
T
At this point TEST really has been uninterned, but...
A 7 > (list-package-symbols)
I'll bet you did not type this in yourself, but rather used the
history commands of LispWorks' Listener. Specifically, you probably
hit #\Control-\c #\Control-\p twice, the effect being to bring up the
previous input expression "(unintern 'test)", then the next previous
one "(list-package-symbols)". Well, the LispWorks Listener performs
incremental reading of input. When "(unintern 'test)" flashed back
into your input line momentarily, the Listener immediately read it in,
thereby re-interning the symbol TEST.
(LIST-PACKAGE-SYMBOLS P-LISP X PACK TEST)
A 8 > (unintern 'TEST)
T
TEST is uninterned again, but...
A 9 > (list-package-symbols)
Flashing through "(unintern 'TEST)" re-interns TEST.
(LIST-PACKAGE-SYMBOLS P-LISP X PACK TEST)
A 10 > test
Error: the variable TEST is unbound
1 (continue) Try evaluating it again
2 Return a value to use
3 Return a value to set it to
4 (abort) return to level 0.
5 return to top loop level 0.
6 Destroy process.
A 11 : 1 > :a
A 12
In general, uninterning symbols from a package--especially while
you're still in the package--is not as straightforward as one might
think.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
In article ·············@excalibur.flw.att.com, ···@excalibur.flw.att.com (Lawrence G. Mayka) writes:
>In article <······················@grace.rt.cs.boeing.com> ···@grace.rt.cs.boeing.com (Chris Kacoroski,none) writes:
>
> When I unintern a symbol from a package, i was expecting it to disappear.
> In Lispworks, it just seems to be unbound, it this correct behavior?
>
>No, but I don't think this is exactly what's happening. See below.
>
>I'll bet you did not type this in yourself, but rather used the
>history commands of LispWorks' Listener. Specifically, you probably
>hit #\Control-\c #\Control-\p twice, the effect being to bring up the
>previous input expression "(unintern 'test)", then the next previous
>one "(list-package-symbols)". Well, the LispWorks Listener performs
>incremental reading of input. When "(unintern 'test)" flashed back
>into your input line momentarily, the Listener immediately read it in,
>thereby re-interning the symbol TEST.
>
Well, what do you know, Lawrence is absolutely correct. I was re-interning
TEST. Thanks for the help.
---
Cheers,
Chris "ski" Kacoroski "When we try to pick out anything by itself
···@grace.rt.cs.boeing.com we find it connected to the entire universe"
John Muir
From: Bill Bohrer
Subject: Re: Unintern question
Date:
Message-ID: <C8qDIM.42v@mcc.com>
In article <······················@grace.rt.cs.boeing.com> ···@grace.rt.cs.boeing.com writes:
>Hi,
>
>When I unintern a symbol from a package, i was expecting it to disappear.
>In Lispworks, it just seems to be unbound, it this correct behavior?
>
>
It's a mistake to expect it to "disappear", all uninterning is
advertised to do is remove it from a given package (or *package*) If
you unintern it it's supposed to still exist, either in it's home
package or as an uninterned symbol, which is a symbol without a
package, like what you get as the result of doing a gensym, for
instance.
However, the behavior you describe still looks like a bug to me since
the symbol still exists in the package after you specifically
uninterned it from that package.
I tried it out in Lucid Common Lisp (DECstation version 4.0), same
bug:
> (symbol-package 'floo)
#<Package "B" 102202AE>
> (unintern 'floo "B")
T
> (symbol-package 'floo)
#<Package "B" 102202AE>
This should return nil, according to CLtL2, as well as CLtL1, Common
List the Reference, by Franz inc.
Bill Bohrer
······@mcc.com
--
*+ YEah sure my views are representative of my employer's
*+ And monkeys might fly out my butt.
In article <··········@mcc.com> ······@banach.mcc.com (Bill Bohrer) writes:
>
>It's a mistake to expect it to "disappear", all uninterning is
>advertised to do is remove it from a given package (or *package*) If
>you unintern it it's supposed to still exist, either in it's home
>package or as an uninterned symbol, which is a symbol without a
>package, like what you get as the result of doing a gensym, for
>instance.
>
>However, the behavior you describe still looks like a bug to me since
>the symbol still exists in the package after you specifically
>uninterned it from that package.
>
>I tried it out in Lucid Common Lisp (DECstation version 4.0), same
>bug:
>
>> (symbol-package 'floo)
>#<Package "B" 102202AE>
>> (unintern 'floo "B")
>T
>> (symbol-package 'floo)
>#<Package "B" 102202AE>
>
>This should return nil, according to CLtL2, as well as CLtL1, Common
>List the Reference, by Franz inc.
You must be careful not to recreate a new symbol (via the
CL reader) in your test:
B(5): (symbol-package 'b)
#<The B package>
B(6): (unintern 'b "B")
T
B(7): (symbol-package 'b)
#<The B package>
B(8): (setq sym 'b)
B
B(9): (unintern sym "B")
T
B(10): (symbol-package sym)
NIL
B(11): (symbol-package 'b)
#<The B package>
B(12): (eq 'b sym)
NIL
As you can see, the two symbols are not eq (and the first 'b WAS
uninterned).
From: Markus Fischer
Subject: Re: Unintern question
Date:
Message-ID: <6720@darmstadt.gmd.de>
In <··········@mcc.com> ······@banach.mcc.com (Bill Bohrer) writes:
>It's a mistake to expect it to "disappear", all uninterning is
>advertised to do is remove it from a given package (or *package*) If
>you unintern it it's supposed to still exist, either in it's home
>package or as an uninterned symbol, which is a symbol without a
>package, like what you get as the result of doing a gensym, for
>instance.
>I tried it out in Lucid Common Lisp (DECstation version 4.0), same
>bug:
>> (symbol-package 'floo)
>#<Package "B" 102202AE>
>> (unintern 'floo "B")
>T
>> (symbol-package 'floo)
>#<Package "B" 102202AE>
I don't think that's a bug. I suspect that in the test case you
described above, the reader is interning a FLOO symbol
into the package "B" again, when typing & evaluating the second
call to symbol-package; assuming you've made "B" the (current)
*package*.
--
Markus Fischer, ········@darmstadt.gmd.de
GMD - German National Research Center for Information Technology