[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Where do extensions go?
- To: email@example.com, common-lisp@SU-AI.ARPA
- Subject: Where do extensions go?
- From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
- Date: Tue, 11 Mar 86 11:38 EST
- In-reply-to: The message of 11 Mar 86 10:07-EST from "BACH::GREEK" <firstname.lastname@example.org>
Date: 11 Mar 86 10:07:00 EST
From: "BACH::GREEK" <email@example.com>
I agree that different implementations might have lots of packages with
different extensions in them (e.g., debugger, editor). It just seems
a pain if you don't import all of these into one extensions package and
then make them public from there. Otherwise the user has to use all
sorts of packages or put package prefixes everywhere.
What if there is more than one "extension", and two extensions use the
same name for something? Think about why there are packages in the first
In particular, Common LISP says that there will probably be a debugger
(for example), but doesn't talk about the interface. So the user says
"I want to use the debugger, where the hell is it? Which packages do I
have to use so that any symbols that are part of the debugger will show
up? Do I need to use more than one package?" It seems we could avoid
some of this annoyance if we just said that all such public symbols are
in some standard package.
OK, so then you'd know what package the interface was in. But you still
would not know what any of the functions did. So you need a
specification (documentation). Since you need that anyway, it can tell
you what package to use.
Of course there might be confusion between two implementations. But
that isn't any worse or better if we agree on the name of the extensions
package. Also, by agreeing on one name, we only reserve that one name,
and we don't potentially have a bunch of names that layered product
developers have to avoid. This is particularly important if we refuse
to register package names, which we probably will.
I think the problem here is that you are assuming that each Common Lisp
system comes with one single set of "extensions", produced by the same
people that provide the base language, and that these sets of
"extensions" are inherently different in some way from other packages of
useful functions produced by other parties.