Re: INTERN [Gall: Bug Report]

[Nick Gall <Gall@MIT-MULTICS.ARPA>]

    Date:  2 April 1985 23:01 est
    From:  Scott E. Fahlman <Fahlman at CMU-CS-C>
    Subject:  INTERN [Gall: Bug Report]

    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

I agree with you completely.  I disagree with the recommendations given
by Jon L.  White:

     1) pick some other word to use in place of "interned" to describe the
          state so laboriously depicted on page 172, so that the reader is not
          tempted to jump to the conclusion that it is coextensive with INTERN'd
     2) Introduce the user-level operation for modifying a symbol's package
          "cell" [its home package].  As Nick has already pointed out, the
          current design doesn't prevent one from damageing that cell, by
          injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't
          provide any way to say precisely what you mean when you want to
          change its home [which is different from merely IMPORTing it somewhere].

Since the CLRM already implies that INTERN may clobber the package cell
of an accessible symbol (an inexpensive operation) isn't it simpler (and
cleaner) to merely state it explicitly in the def.  of INTERN (pg.184),
instead of changing pg.  172 AND inventing a WHOLE NEW user-level
operation (and a dangerous one at that)?