Discoverability of CDR implementations

Motivation

Since the publication of the Common Lisp standard, a significant amount of
extra functionality has become available in a similar way on most actively
developed Common Lisp implementations. Unfortunately, there are implementation
differences which require maintenance of portability libraries. Moreover, the
most common way to select the way of accessing extra functionality is the #+
reader macro with Common Lisp implementation name. This leads to the obvious
drawbacks (also experienced by other ecosystems) such as problems with
tracking the evolution of Common Lisp implementation from a release to the
next release and lack of support for forks and experimental branches of Common
Lisp implementations even if the functionality in question is implemented in
the exact same way.

The CDR process provides a way to define extensions in a way that fixes a set
of names and provides an interface which is either uniform or easy to probe.
However, in practice many CDRs define the names of the symbols without
specifying the package, which reduces the benefits of uniform naming. Another
problem is that a Common Lisp implementation might supply an implementation of
a CDR but not load it by default, leaving it invisible.

A natural solution would be to either revise the standard or to agree on a
single package name that would hold all the CDR-defined extensions.
Unfortunately, both approaches require building a widely accepted consensus
across a large community with diverse priorities. This requires both a
commitment to expending a significant amount of effort, and a commitment to a
specific process of avoiding deadlocks while still producing widely acceptable
decisions.

This document proposes instead a minimalistic way. The aim is to obtain
tangible benefits with minimal effort, limited coordination and limited
case-by-case commitment. The goals include simple probing for support of
desired CDRs as well as parts of desired CDRs, but creation of consistent
extension set spanning multiple CDRs is out of scope.

CDR detection and loading functionality

This CDR is based on CDR n. 14. An implementation of this CDR SHALL add
:CDR-NN to the COMMON-LISP:*FEATURES* global variable.

An implementation of CDR-NN SHALL have a package with name or nickname CDR-NN.
This package SHALL contain an external symbol named REQUIRE-CDR. The
CDR-NN:REQUIRE-CDR symbol MAY have a different home package. The CDR-NN package
MAY also contain other symbols.

The REQUIRE-CDR symbol SHALL name a generic function.

REQUIRE-CDR (CDR-NUMBER): a generic function

CDR-NUMBER: an integer, specifying the CDR number.

Return value: any true value if code intended to be a compliant implementation
of the CDR with the number CDR-NUMBER is available. In this case the
implementation of the CDR SHALL be fully loaded (and the corresponding symbol
added to the *FEATURES* list). If no implementation is available, NIL is
returned.

CDR implementations MAY be provided by third-party libraries. Such libraries
SHALL provide a separately loadable system for each implemented CDR, defining
the corresponding method on REQUIRE-CDR.

CDR-defined symbols

For every supported CDR n. XX in the system, there SHALL be a package with
name or nickname CDR-XX. Every symbol defined in the CDR n. XX and implemented
in the system according to the CDR SHALL be available in the CDR-XX package as
an external symbol. If a symbol with a name defined in CDR-XX is present in
the CDR-XX it SHALL have associated definitions according to CDR-XX. A CDR MAY
declare some functionality optional; if such functionality is not implemented,
the corresponding symbol SHALL NOT be present in the CDR-XX package.  The
symbols in the CDR-XX package MAY have a different home package.  The CDR-XX
package MAY also contain symbols with names not mentioned in the CDR, in
particular, it MAY coincide with package with nickname CDR-YY for some other
supported CDR n. YY.

The CDR authors SHOULD choose symbol names that avoid conflicts with other
existing CDRs.

Codification of popular extensions via CDR

As immediate and simultaneous adoption of a CDR by the all actively developed
implementations as well as by library authors is unlikely, portability
libraries are expected to stay in wide use. A portability library for
functionality defined via one or multiple CDRs SHOULD check whether the
necessary CDR implementations are available (and provide a sufficient part of
optional functionality, where applicable) before using the
implementation-name-conditional code or probing for availability of known
names without a neutral specification.

Both Common Lisp implementations and third-party libraries are encouraged to
provide CDR-compliant wrappers whenever the equivalent functionality is
already implemented with a different interface.