[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: INTERN [Gall: Bug Report]
- To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
- Subject: Re: INTERN [Gall: Bug Report]
- From: Nick Gall <Gall@MIT-MULTICS.ARPA>
- Date: Wed, 3 Apr 85 23:38 EST
- Cc: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>, common-lisp@SU-AI.ARPA
- In-reply-to: Message of 2 Apr 85 23:01 EST from "Scott E. Fahlman"
- Posted-date: 3 Apr 85 23:42 EST
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.
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)?