Marco Antoniotti
Università degli Studi di Milano Bicocca,
Milan, Italy<marco.antoniotti [a]
unimib.it>
Keywords: Common Lisp, CDR, Implementation Features.
The Common Lisp Document Repository (CDR) [2] was created as a very light-weight infrastructure for the Common Lisp community, where a number of "documents" and "specifications" are collected and fixed for the benefit of programmers and implementors. Each document is give an unique CDR identifier (essentially a number), which is retained over the years; each of these documents can then be referred simply as CDR number N (or, more simply, a CDR, when not referring to a particular document in the repository).
At the time of this writing, there is yet no agreed upon way to check whether a Common Lisp implementation provides a particular CDR or not (i.e., whether a particular CDR is present "out of the box", or whether a library implementing a specific CDR is loaded in the Common Lisp environment). The goal of this document is to provide a specification for this behavior.
Each CDR is assigned a unique number/identifier. It therefore
appears natural to resort to the Common Lisp
*features*
machinery to provide a minimal
infrastructure to check for the presence of a given CDR in a
Common Lisp environment. To do so, a few
definitions are necessary and will be listed in the next
section.
The specification contained in this document consists of the following items:
:cdr-
n (where n is
the unique CDR number assigned by the editors).
The numer n is a (integer 0)
, if
Common Lisp types are to be
used, and its typographical representation is as if it were
print
ed with *PRINT-BASE*
set
to 10.:cdr-42
) in the
*features*
list.:cdr-
n is present in
the *features*
list of a given Common
Lisp environment, that means only that
specific instance of a Common Lisp environment purports to implement CDR i at a "satisfactory" level of compliance.
Users and programmers can thus check whether a give CDR is
"present" in a Common Lisp environment,
using the usual *features*
checking machinery.
It must be noted that there are possible pitfalls that the "CDR process and infrastructure" cannot avoid. In the following they are listed in no particular order.
The "CDR process and infrastructure" cannot guarantee
that the presence of a CDR keyword in a Common
Lisp environment *features*
list corresponds
to a "correct" and "complete" implementation of
a given CDR. "Correctness", "completeness" and
"testing" are left to the "provider" of a given
CDR.
It is understood that a provider of a given CDR (a provider who purports to implement...) will make a best effort to fully implement a specification.
It may be possible for multiple implementations of a given
CDR to co-exist in a given Common Lisp environment.
All of them will rely on a single :cdr-
n in
the *feature*
list. Which particular implementation is
then actually used and where, is left to the programmer and her/his
use of the package system.
As an example, testing for the presence of CDR 10 will be done as follows:
#+cdr-10 (abi-version)
The current set of CDR's is listed at the site http://cdr.common-lisp.dev. The following keywords are thus assigned to each of the finalized CDR's:
:cdr-0
,
:cdr-1
,
:cdr-2
,
:cdr-3
,
:cdr-4
,
:cdr-5
,
:cdr-6
,
:cdr-7
,
:cdr-8
,
:cdr-9
,
:cdr-10
,
:cdr-11
,
:cdr-12
,
:cdr-13
.
The CDR editors, and the participants to the CDR "side"-meeting at the European Lisp Symposium in Madrid, June 4, 2013 (ELS 2013).
This work may be distributed and/or modified under the conditions of the Creative Commons Attribution 3..0 Unported License, or (at your option) any later version. The latest version of this license can be found at http://creativecommons.org/licenses/by/3.0/.
The current maintainer of this work is Marco Antoniotti,
<marco.antoniotti [a] unimib.it>
.