Re: intern

[NGALL@G.BBN.COM]

    Date: Mon, 17 Feb 86 12:47:35 pst
    From: hpfclp!diamant@hplabs.ARPA
    To: common-lisp@su-ai.ARPA
    Subject: intern
    
	....
       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
My restrictiction would disallow your def. of MOVE-SYMBOL, but you
could easily unintern the symbol from all the packages it is present
in (except of course the old home package) (and of course keeping a
list of those packages, and info. as to whether or not the symbol was
external) BEFORE uninterning the symbol from its home package.  THEN,
you import it into it's new home package, and import/export it back
into the other packages it was present in.  [Note: Your def. of move
symbol did not deal with the problem of using SHADOWING-IMPORT where
necessary, so neither does my alternative.]

Other than changing a symbol's home package, I doubt that my
restriction would ever get in anyone's way.
    current approach of warning users that this situation may arise is better
    than restricting its use.
I'd rather warn the user when it happens, since that's when they need
the warning. :-)
    
	-- Nick