How many name spaces in CL?

[Christopher Fry <cfry@OZ.AI.MIT.EDU>]

    Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 14 Mar 86 11:15-EST
    Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 11:14:01 EST
    Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Mar 86  07:48:11 PST
    Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Mar 86 10:48:08-EST
    Date: Fri, 14 Mar 1986  10:48 EST
    Message-ID: <FAHLMAN.12190655018.BABYL@C.CS.CMU.EDU>
    Sender: FAHLMAN@C.CS.CMU.EDU
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
    Cc:   Common-Lisp@SU-AI.ARPA
    Subject: How many name spaces in CL?
    In-reply-to: Msg of 14 Mar 1986  07:46-EST from George J. Carrette <GJC at MC.LCS.MIT.EDU>


    WHy would anyone want to enumerate this set?  There are a bunch of
    obvious members, and then they get kind of arguable and trail off into
    infinity.
I've thought about such a list myself. A list of namespaces is a concise, useful
viewpoint of CL. Thank you GJC for making it for us. I hope it will appear
in the next CLtL.

	With so many name spaces already it is unfortnate there is no
	construct for defining new name spaces. 

    There are several such mechanisms: hashtables, property lists, macros...
    it all depends on how you choose to look at the result.
A mechanism for defining namespaces has some interesting possibilities.
First, the list that GJC constructed by hand could have been created automatically
by the def-namespace form. If for no other reason than documentation, its useful.
Next, I can imagine an apropos which takes a list of namespaces to search through.
I'll be suprised if there aren't other uses, though I wouldn't want to
jump into making such a mechanism part of CL.

Scott raises the issue that every plist or random alist is, 
in effect, a separate namespace. This is true for one definition of namespace.
But at least some of the namespaces that GJC was using
have the characteristic that each namespace contained only and all objects of a type.
Such is not true for random data structures.
Maybe this property can be exploited for a general gain in power
similarly to deftype?