[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@SU-AI.ARPA
- From: Nick Gall <Gall@MIT-MULTICS.ARPA>
- Date: Wed, 3 Apr 85 17:36 EST
- In-reply-to: Message of 3 Apr 85 03:28 EST from "Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA)"
Date: 3 April 1985 03:28 est
From: Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA)
Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:16 PST (=GMT-8hr)
Date: 1985 April 02 23:36:01 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
Subject:CL, INTERN, etc.
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
> Date: Thu, 21 Mar 85 00:36 EST
> From: Nick Gall <Gall@MIT-MULTICS.ARPA>
> Thanks for the encouragement. Having previously worked on an Ada
> implementation effort, I was hoping that the Common Lisp spec. would
> have been as carefully and completely defined. But it's never to
> late, as long as there is a concerned community.
Well, it's more difficult to make substantive changes now, because
those who worked on the current version of the manual and have done
some implentation are unwilling to start all over now, which I
understand (PCNET pulled the rug out from under my software and
documentation too many times), but indeed perhaps it's never too late
to fix the document to say something consistent and reasonable.
> I am sending my replies to some of your replies to the
> Common-Lisp mailing list.
Ok. (I think I already saw some of them, I'm falling behind in
answering my netmail.)
> !section 11.7 Nick Gall 85-03-20
> !version Digital Press 1984
> !topic UNINTERNing a shadowing-symbol
> When uninterning a shadowing symbol (call it foo), UNINTERN
> collects all inherited symbols with the same print-name
> as foo, including foo (assuming foo was inherited). If the name
> conflict is only between foo and one other symbol, what sense
> does it make to signal a name conflict error and give the user a
> choice between shadow-importing foo and the other symbol. If the
> user chooses foo, it is no different from aborting from the
This plus later messages bring up a curious question. Originally
INTERN could take a symbol and put it in a hash table so it'd be
accessible by name in addition to by internal pointer. Any values or
properties it had would presumably be kept. But CL allows INTERN only
for strings (creating an symbol or finding an old one), so it never
modifies an existing non-interned identifier to make it itself
interned, it always makes a new symbol, thus it's impossible to keep
the old properties and value from the old symbol in the new one. I
IMPORT can be used to "put [a symbol] in a hash table so it'd be
accessible by name...".