INTERN [Gall: Bug Report]

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

This concerns the recent exchange between Moon and Gall on how INTERN
should handle home packages.  I will refrain from including all previous
context.  Unfortunately, I read most of this mail on an 80-column screen
and if things get nested too deeply, each line starts on the next line.

First, let me say that this is probably not of world-shaking importance.
Home packages are just a convenience for the printer, so that if a
symbol isn't accessible in the current package, it can (usually) either
tell you some package where the symbol is accessible or flag the cases
in which a symbol is not accessible in any package.  It is true that by
clever use of Unintern you can manage to create an accessible sysmbol
with no recorded home package.  Unintern also allows you to screw
yourself in lots of other ways if you work hard at it.  Yawn!

Having said that, it seems to me that Gall's original reading of the
manual is as reasonable as any other.  This says that if Intern finds an
acessible symbol that has no home (as opposed to creating a new symbol),
it should bash the Symbol-Package cell to the value of the package in
which it is doing the interning.  It is too much work to make sure that
every symbol that is accessible in any package always has a home
package, but when we trip over an anomalous case like this, we may as
well fix it.  It seems intuitive that Intern should return a symbol that
is "interned", in the sense of being accessible and having a home.

Moon grants that this might be a reasonable implementation, but then
comments that implementing this might be expensive.  I don't see where
the expense would be.  If Intern creates a symbol, it sets the home
package; if Intern finds a symbol whose package cell is NIL, it again
sets the home package.  Checking the home package for nillity is a tiny
expense compared to the hash-table lookups, etc.

The sentence on page 172 should more properly say "when a STRING is
interned in a package...", since as Moon points out you cannot intern a
symbol directly.  However, I think that this passage makes sense despite
this, if you make the reasonable assumption that the "symbol" referred
to here is either the one that is created or the already accessible
symbol that is found, as the case may be.

We decided not to allow users to use SETF on Symbol-Package, since there
seemed to be no good use for this and since by diddling around with this
you can create some very confusing situations.

-- Scott