[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: apparent problem with unintern

From: Camm Maguire
Subject: [Gcl-devel] Re: apparent problem with unintern
Date: 17 Jun 2005 09:18:59 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thanks for the report!

Of course, you know this works if you unintern 'temp::c, right?  'c
evals to a different symbol in the current package.  It is odd that
this works as you describe in clisp and cmucl.  Perhaps I'm misreading
something in the spec, the section of which is included below, but it
doesn't seem to indicate that this should work.  We pass all of Paul's
unintern tests in his ansi compliance suite.  Paul, is this an issue?
DO we need another test here?


11.2.15 unintern                                                         

`unintern'  symbol &optional package =>  generalized-boolean

Arguments and Values::

symbol--a symbol.

   package--a package designator.

   The default is the current package.

   generalized-boolean--a generalized boolean.


unintern removes symbol from package.  If symbol is present in package,
it is removed from package and also from package's shadowing symbols
list if it is present there.  If package is the home package for
symbol, symbol is made to have no home package.  Symbol may continue to
be accessible in package by inheritance.

   Use of unintern can result in a symbol that has no recorded home
package, but that in fact is accessible in some package.  Common Lisp
does not check for this pathological case, and such symbols are always
printed preceded by #:.

   unintern returns true if it removes symbol, and nil otherwise.


      (in-package "COMMON-LISP-USER") =>  #<PACKAGE "COMMON-LISP-USER">
      (setq temps-unpack (intern "UNPACK" (make-package 'temp))) =>  
      (unintern temps-unpack 'temp) =>  T
      (find-symbol "UNPACK" 'temp) =>  NIL, NIL
      temps-unpack =>  #:UNPACK

Side Effects::

unintern changes the state of the package system in such a way that the
consistency rules do not hold across the change.

Affected By::

Current state of the package system.

Exceptional Situations::

Giving a shadowing symbol to unintern can uncover a name conflict that
had previously been resolved by the shadowing.  If package A uses
packages B and C, A contains a shadowing symbol x, and B and C each
contain external symbols named x, then removing the shadowing symbol x
from A will reveal a name conflict between b:x and c:x if those two
symbols are distinct.  In this case unintern will signal an error.

See Also::

*Note Package Concepts::


Matt Kaufmann <address@hidden> writes:

> Hi, Camm --
> The following log shows a failure of unintern to remove a symbol from a
> package in GCL 2.6.6 (non-ANSI).
>   craigievar:~> gcl
>   GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 19 2005 20:24:14
>   Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
>   Binary License:  GPL due to GPL'ed components: (BFD UNEXEC)
>   Modifications of this banner must retain notice of a compatible license
>   Dedicated to the memory of W. Schelter
>   Use (help) to get some basic information on how to use GCL.
>   >(make-package 'temp :use nil)
>   #<"TEMP" package>
>   >'temp::c
>   TEMP::C
>   >(unintern 'c (find-package "TEMP"))
>   NIL
>   >(find-symbol "C" (find-package "TEMP"))
>   TEMP::C
>   >
> I tried the same experiment in Allegro CL and CMUCL; for example, here is the
> result in the latter.
>   * (make-package 'temp :use nil)
>   #<The TEMP package, 0/9 internal, 0/9 external>
>   * 'temp::c
>   TEMP::C
>   * (unintern 'c (find-package "TEMP"))
>   T
>   * (find-symbol "C" (find-package "TEMP"))
>   NIL
>   NIL
>   * 
> As far as I know there is no hurry at all on this, but I assume that you'll
> hear from the ACL2 user I'm copying if he is in need of a workaround.
> Thanks --
> -- Matt

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]