Proposal for Common LISP Registrar

[greek@DEC-HUDSON]

		PROPOSAL FOR COMMON LISP REGISTRY

Purpose
-------

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.


Feature Names
-------------

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

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


Package Names
-------------

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

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

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
separate products.


Other Conventions
-----------------

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.