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.