[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
flat name space for pkg names
- To: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@UCL-CS.ARPA>
- Subject: flat name space for pkg names
- From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
- Date: Tue, 18 Jun 1985 03:39:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 17 Jun 1985 19:25-EDT from DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa at ucl-cs.arpa>
- Sender: FAHLMAN@CMU-CS-C.ARPA
At the risk of re-opening some issues that are better left alone, I
will respond in public to your query.
I have no idea what would be an appropriate name-space mechanism for
Prolog, but I don't feel that the single-level namespace of Common Lisp
is a problem. If two packages are to run together in the same system,
they have to agree at *SOME* level of the package system that they are
going to use distinct names. If there's no coordination at all, there's
always the chance of a collision. You can't get rid of this; you can
only bury it deeper.
It would be possible to have a hierarchical package structure (or
nested, if you prefer to look at it that way), analogous in some ways to
hierarchical directories. This makes it possible to have sub-domains of
coordination -- if all files coming from CMU have symbols named things
like CMU:SOME-PACKAGE:SOME-SYMBOL, the CMU people can coordinate package
names among themselves with no fear that MIT people will happen to
choose conflicting names; all we have to agree on is that we use the CMU
super package and MIT uses the MIT super-package. This sort of thing
can be carried on to arbitrary depth.
In Common Lisp we decided that it wasn't worth the added complexity, and
that a single namespace for packages would suffice. I have not yet seen
any reason to regret that decision. If we try to import some new module
(or set of modules) whose choices for package names happen to conflict
with some existing modules, we do minor surgery on one file or the other
to eliminate the conflict. Inelegant, but good enough.