[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal for Common LISP Registrar
- To: common-lisp@su-ai
- Subject: Proposal for Common LISP Registrar
- From: greek@DEC-HUDSON
- Date: Fri, 21 Jun 85 11:04:07 EDT
PROPOSAL FOR COMMON LISP REGISTRY
The purpose of the Common LISP Registry is to prevent or resolve
conflicts in software written for Common LISP implementations.
These conflicts can arise in the following areas:
o Feature names. We must agree on those features which will be
in a flat name space (the keyword package, if we adopt the
latest proposal). Such features include implementation subsystems,
company names, operating system names, etc. Package-specific
features will be in the packages themselves (again, if we agree).
o Package names. The package name space is flat, so each and every
package that a user might need should have a unique name.
o Extensions. The Registry could also maintain a central collection
of Common LISP extensions, thus increasing the probability that
similar extensions are implemented in a consistent fashion. Such
extensions might include additional sharp-sign reader macros,
additional format directives, use of numeric extension characters,
additional character bits, etc. This tends to be controversial,
since it's akin to proposing additions to the language, so maybe
it's not time for this yet. Comments?
o Surely I forget something.
The Registry would be responsible for keeping track of those feature
names which reside in a flat name space. The conventions would be as
follows (exact names to be determined):
o Feature names for LISP dialects are such things as COMMON-LISP,
MACLISP, FRANZ-LISP, etc. We should agree on these so that people
can write dialect-independent code if possible. We already have
some Common LISP implementations using the feature COMMON-LISP and
others using just COMMON.
o Feature names for Common LISP subsystems are such things as
COMPILER, EDITOR, TRACER, FLAVORS, etc. These would be generic
names that indicate that some (hopefully standard) such subsystem
exists in this implementation.
o Feature names for companies are such things as DEC, SYMBOLICS, TI,
etc. These names can correspond to trademarks.
o Feature names for computers are such things as VAX, DECSYSTEM-20,
SYMBOLICS-3600, EXPLORER, etc. These names can correspond to
o Feature names for operating systems are such things as VMS, UNIX,
MSDOS, etc. Some of these names can correspond to trademarks.
o Feature names for specific Common LISP implementations are such
things as VAX-LISP, SPICE-LISP, etc.
Note that the last four items are redundant with some of the functions
in Section 25.4.2 of CLtL. This is unfortunate, but the functions are
meant to be descriptive to people, while the features are meant to
be tested by code.
I believe that package-specific features should reside in the package,
but this is currently under debate.
An implementation would also be free to add any features in the flat
name space, so long as they were prefixed with registered features
belonging to that implementation (e.g., VAX-LISP-MUMBLE is registered
by virtue of VAX-LISP being registered).
The Registry would be responsible for keeping track of package
names. The conventions would be as follows:
o The following package names are currently standard: LISP, USER,
KEYWORD, SYSTEM (SYS).
o Any package names which are prefixed with SYSTEM- or SYS- are
considered to be implementation-specific and are automatically
o Another set of generic package names will be preregistered for
Common LISP subsystems. These are to be determined, but an
example is EDITOR. This name is reserved for the editor in
any given implementation. A goal is that these names coincide
with the corresponding feature names.
Note that this convention precludes anyone from creating a
fancy new Common LISP editor and selling it under the name
of EDITOR (or DEBUGGER or FLAVORS or GRAPHICS or ...).
o All other package names must be registered, most importantly
those which are assigned to a product to be sold.
o It will be possible to register a package prefix. For example,
the Acme Artificial Intelligence Corp. registers GAMBLING-EXPERT-*
for a set of gambling expert systems. The star is a wildcard,
meaning that all names beginning with GAMBLING-EXPERT- are
An implementation would also be free to create additional package names
as long as they were prefixed with a registered feature belonging
to that implementation (e.g., VAX-PACKAGE3 is registered by virtue
of VAX being a registered feature). This would, in fact, be the
recommended way for an organization to make up package names for
All registration would be on a first-come-first-served basis. The
Registrar has the right, within reason, to refuse to register a name
which is too generic (e.g., ENGINEERING), to short (e.g., A*), likely
to conflict with future Common LISP extensions (e.g., GKS), or what
have you. In such cases, the reason will always be given.
All online correspondence with the registrar will be via the Arpanet to
an account with a name such as COMMON-LISP-REGISTRAR. Registration can
also be done in writing.
The Registration List
A complete registration list would be published from time to time and
distributed to the Common LISP mailing list. Hard copy would also be
available upon request.
Many new packages may be considered proprietary by the developing
organization. I would certainly make a provision for this and not
publish such packages. However, since I work for Digital it may be
that the organization does not even want me to know about the package.
That is why I have provided for automatic registration of names
prefixed with a registered feature name.