intern

[hpfclp!diamant@hplabs.ARPA]

   From: Rob MacLachlan <hplabs!RAM@C.CS.CMU.EDU>

   ...
First of all, I'm satisfied with what was apparently concluded several months
ago.  Unfortunately, I wasn't aware of the original discussion until I was
already deeply involved in the current one.  As long as the definition of
the verb "intern" is either cleaned up or separated from the function INTERN,
I would be satisfied, especially now that IMPORT has been defined to set
the package cell if necessary.
   
   There is a point against INTERN setting the home package which I
   believe was not discussed.  It is not obvious what package INTERN
   should choose at the home.  It is a bad idea to set the package
   to the one being interned in, since the symbol may not be present in
   that package; it may be inherited.  If the symbol was subsequently
   unexported, it would have a home package yet not be available in that
   package.  This could be fixed up by choosing some package which the
   symbol is present in, but the choice would have to be fairly
   arbitrary, since the symbol might be inherited from more than one
   package.
   
     Rob

That is exactly the point I made in my last message.  The reason I created
a print-read inconsitency is that I assumed INTERN would set the package cell
to the package in which the symbol was being interned.  We agree that this
is a good reason to prevent INTERN from setting the package cell.
   
   From: hplabs!NGALL@G.BBN.COM
       
   Since UNINTERN is the only other function that is allowed to modify
   the package cell, perhaps CLtL should state either that:
   
   1.  It is an error to UNINTERN a symbol from its home package if it is
   present in some other package; or,
   
   2.  An error is signaled in case 1 [I prefer this case.]
   
   Saying (1) would at least warn people that "all bets are off" if they
   create an accessible but unowned symbol and would allow
   implementations that were concerned about it to signal an error.
   Requiring (2) would be a bit more overhead, but since UNINTERN is
   rarely used (right?), I think it would be acceptable.
   
I'm not convinced that this is a good idea.  What if I want to move symbols
from one package to another, but I want all of the references from any other
location to point to the new place.  I just had to do something like this
recently to handle a bootstrap.  Because of the nature of packages and macros,
I had a case where I had to compile a system in which code may reference either
old or new locations during the compile.  I performed this move by doing
the following:

(defun move-symbol (sym pkg)
  (let ((old-pkg (symbol-package sym)))
    (unintern sym old-pkg) ; make sym have no home (a bastard?)
    (import sym pkg)	; give sym a new home package
    (import sym old-pkg)
    (export sym pkg)	; assumes sym was originally exported from old-pkg
    (export sym old-pkg)))

If you restrict UNINTERN to only work if the symbol has not been imported into
any other package, then move-symbol would probably not work (it is likely
that some of the symbols that were moving had been imported elsewhere).  It
seems to me that the operation I performed was perfectly valid (though not
for the weak of heart), and your restriction would limit it.  I think the
current approach of warning users that this situation may arise is better
than restricting its use.

	John