Extensible reader package name resolution
=========================================

Motivation
==========

Common Lisp's package system suffers from the fact that the package
name space is global.  When a Lisp program wants to use libraries that
have conflicting package names or nicknames, it needs to take special
precautions to resolve the naming conflicts.  This problem is getting
larger with the advent of a working Lisp library infrastructure in
which libraries heavily depend on each other, thereby increasing the
number of packages that are typically used within one program.

One solution to this problem is to create a namespace for package
names that prevents naming conflicts, similar to the reverse domain
name scheme that is used in Java package names.  This scheme has not
widely been adopted, though.  Also, the practice of using qualified
names instead of importing library symbols into application packages
has become more popular, making the use of very long package names
undesireable.

Analysis
========

Package names are used in two situations: The Lisp reader looks up
package names when interning qualified symbols, and package names can
be supplied to various CL functions when interning and looking up
symbols.  Both basic use cases typically end up in an implementation
private function that consults global list of packages to find the
package of interest.  The implementation private function that maps
from a package name to a package is not exposed to user programs, so
extending the package name lookup in a portable fashion is not
possible.

Solution
========

Implementations that support this CDR create a new package, named
"CDR12", which exports the symbol "*PACKAGE-PREFIX-RESOLVER*" which is
bound to NIL by the implementation.  Application code my bind this
variable to a unary function which receives a package name, specified
as a string, as argument.  The function is expected to return NIL if
the name could not be resolved, or the package object that the
application wants to refer to by the name.

The implementation is expected to call the *PACKAGE-PREFIX-RESOLVER*
function before performing the standard package name lookup function
as mandated by CL or implementation specific extensions.

Implementations that support this CDR must put the :CDR12 symbol onto
the *FEATURES* list.

Application best practices
==========================

Application code that sets CDR12:*PACKAGE-PREFIX-RESOLVER* should
retain the old value internally and call the previous resolver
function, if any, if a package name could not be resolved.

If *PACKAGE-PREFIX-RESOLVER* is not NIL, the implementation must call
the function instead performing the standard package name lookup
function as mandated by CL or implementation specific extensions.  The
implementation must make its own package name resolution function
available to the application level package name resolution function
under the name CDR12:RESOLVE-PACKAGE-NAME.  It is at the discretion of
the application-level name resolution to call this function or to
return NIL, indicating that the package name could not be resolved.

Implementations that support this CDR call into an application level
package name resolution hook function when a package name must be
resolved, either from the Lisp reader or from any other function that
accepts a package designator and is presented with a string designator
(i.e. FIND-SYMBOL, INTERN, APROPOS etc.).

The application hook system is implemented by the way of a new,
implementation-defined package "CDR12", which exports the symbols
CDR12:*PACKAGE-PREFIX-RESOLVER* and CDR12:RESOLVE-PACKAGE-NAME.

The variable CDR12:*PACKAGE-PREFIX-RESOLVER* is bound to NIL by the
implementation.  Application code may bind it to a unary function
which receives a package name, specified as a string, as argument.
The function is expected to return NIL if the name could not be
resolved, or the package object that the application wants to refer to
by the name.  If *PACKAGE-PREFIX-RESOLVER* is not NIL, the
implementation must call the function instead performing the standard
package name lookup function as mandated by CL or implementation
specific extensions.  The implementation must make its own package
name resolution function available to the application level package
name resolution function under the name CDR12:RESOLVE-PACKAGE-NAME.
It is at the discretion of the application-level name resolution to
call this function or to return NIL, indicating that the package name
could not be resolved.

If the application level package name resolver returns NIL, the
implementation must signal an appropriate package lookup error to the
user.