[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: RAM@C.CS.CMU.EDU
- Subject: Re: intern
- From: NGALL@G.BBN.COM
- Date: Mon, 17 Feb 1986 17:42:00 -0000
- Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
- Cc: hpfclp!diamant@HPLABS.ARPA
- In-reply-to: <RAM.12183949643.BABYL@C.CS.CMU.EDU>
- Sender: NGALL@G.BBN.COM
Date: Sun, 16 Feb 1986 20:54 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In-Reply-To: Msg of 16 Feb 1986 20:12-EST from Scott E. Fahlman <Fahlman>
I believe that it was decided that the correct interpretation of
the manual did not support INTERN setting the package cell.
Contradictory passages were considered to be dated, and inconsistent
with the current notion of package semantics.
It was thought that having INTERN do anything to package cells was
a rather random side-effect, and was better left out since no very
convincing arguments were presented in its favor.
It was pointed out that IMPORT is a function which causes a symbol to
be present in a package. This seems to correspond fairly well to the
notion of intering a symbol. It was decided that having IMPORT home
the symbol made some sense, so the change to IMPORT was put in.
There is a point against INTERN setting the home package which I
believe was not discussed. It is not obvious what package INTERN
should choose at the home. It is a bad idea to set the package
to the one being interned in, since the symbol may not be present in
that package; it may be inherited. If the symbol was subsequently
unexported, it would have a home package yet not be available in that
package. This could be fixed up by choosing some package which the
symbol is present in, but the choice would have to be fairly
arbitrary, since the symbol might be inherited from more than one
This is pretty much how I remember the discussion.
- From: Rob MacLachlan <RAM@C.CS.CMU.EDU>