Re: INTERN [Gall: Bug Report]

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

Sorry about the long message but I can't justify deleting any of
the context yet.  Summary of conclusions at the end.

    Date:  Tue, 2 Apr 85 14:57 EST
    From:  Nick Gall <Gall@MIT-MULTICS.ARPA>

	    !section  11.7      Nick Gall 85-03-20
	    !version  Digital Press 1984
	    !topic    INTERN's effect on an accessible symbol's owner.

			As a verb, to `intern' a symbol in a package means to
		      cause the symbol to be interned (sic) in the package if
		      it was not already; this function is performed by the
		      function INTERN.  If the symbol was previously unowned,
		      then the package it is being interned in becomes its
		      owner (home package)...
							      CLRM Section 11.0 (pg. 172)

	    I interpret this passage in the following way:

	    ;; Current package is USER

	    * (setf p1 (make-package 'p1 :use '()))
	    {printed rep. of p1}

	    * (import 'p1::xyzzy)
	    T

	    * (symbol-package 'xyzzy)
	    {printed rep. of p1}

	    * (unintern 'xyzzy p1)
	    T

	    * (symbol-package 'xyzzy)
	    NIL         ;; At this point, xyzzy is an accessible uninterned symbol.

	    * (intern "XYZZY")
	    XYZZY
	    :INTERNAL

	    * (symbol-package 'xyzzy)
	    {printed rep. of user}

	    In other words, INTERN ensures that the symbol that it returns
	    as its first value has a home package.

	    Is this interpretation correct?

	I think the mention of accessible but unowned symbols on page 172 (in the
	discussion of home packages) shoots down your example.  The result of the
	last call to SYMBOL-PACKAGE is probably undefined.

    I don't understand your response.  The mention of accessible but
    unowned symbols on page 172 merely confirms the possibility of
    accessible uninterned symbols.  I fully agree that such beasts
    may exist.  In fact, I have annotated the above code to show that
    BEFORE the intern is done, xyzzy is an accessible uninterned
    symbol.

To amplify my response, I don't feel that when INTERN finds an already
accessible symbol (rather than creating a new one), that it "interns
the symbol".  I think the symbol is already interned and INTERN shouldn't
mess with its home package.  Of course this is a matter of interpretation
and perhaps you are right.  The implementation might be expensive in some
systems, though.

    My contention is that the above call to INTERN should (according
    to my interpretation of the CLRM and for practical reasons which
    I will point out below) change xyzzy from an accessible
    uninterned symbol into an interned symbol (simply by updating its
    package cell).

	If the symbol was previously unowned, then the package it is
	being interned in becomes its owner (home package); but if the
	symbol was previously owned by another package, that other
	package continues to own the symbol.

    This sentence strongly suggests to me that intern does affect
    accessible uninterned symbols.

Oh my.  The sentence you quote (on p. 172) appears to be left over from
the days when INTERN would allow a symbol as its argument.  The language
was later changed to permit only strings as arguments to INTERN.  But if
this isn't really a left-over, then it is evidence for your position.

    If intern does not update an accessible symbol whose package cell
    contains NIL, there is NO WAY to change the home package of the
    symbol.  I can't give it a new home!

I think IMPORT was intended to be the way to do that.  Again, the manual
does not appear to have been updated to reflect this after the arguments
allowed for INTERN were changed.  SYMBOL-PACKAGE is also SETF'able in
our implementation, but apparently not in the standard language.

    Suppose I defun foo in the user package.  Then I decide that it
    `belongs' in my tool package.  The best I can do now is

    * (import 'foo 'tool)
    T

    * (unintern 'foo)
    T

    But whenever foo is printed, it will print as #:foo.  This is
    unacceptable.

Do the operations in the other order.  (Of course you have to read
the IMPORT form before evaluating the UNINTERN form).  That works in
our implementation, although I admit it isn't crystal clear that that
is what the manual intends.

I think this issue may need to be referred to the (not yet existent)
technical committee on clarifications to the language.  If you want my
own opinion, in summary:
	- INTERN never changes the SYMBOL-PACKAGE of a symbol that it
	  did not just create.
	- IMPORT sets the SYMBOL-PACKAGE to the package imported into
	  when given an uninterned symbol (more precisely, a symbol
	  whose SYMBOL-PACKAGE is NIL).