[no subject]

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

    Date:  3 April 1985 03:28 est
    From:  Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA)

    Return-Path: <@MIT-MULTICS.ARPA,@SU-AI.ARPA:REM@IMSSS>
    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)
    Message-id: SU-IMSSS.REM.A132116072764.G0391
    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    To:Gall@MIT-MULTICS.ARPA
    Subject:CL, INTERN, etc.
    Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
    Reply-to: REM@MIT-MC.ARPA

    > 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
    > error.

    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
    this correct?


IMPORT can be used to "put [a symbol] in a hash table so it'd be
accessible by name...".