| CDR-defined symbols | | For every supported CDR n. XX in the system, there SHALL be a package | with name or nickname CDR-XX.
1. What if the user want loads two different libraries that each provided the interface of one CDR document?
Those two libraries can't both be loaded without package name or nickname conflicts.
I might be biased by the historical record which makes multiple implementations not exactly the most likely proble… I guess I should add something more explicit to say that a portability layer providing a CDR-defined interface should pass through the support provided by implementation if it is present. As for the general case — well, CFFI provides UFFI package but as a separate system, would it be enough to encourage separation of CDR interface into a separate system?
(Comment) I'd suggest stating that the CDR-XX package corresponding to a CDR XX document make external all *and only* the symbols described in the document, so that a user of such a package would know the consequences of calling USE-PACKAGE on the package.
This would specifically rule out having a single COMMON-LISP-EXTENSIONS package with all the supported CDR symbols (which seems to be the preferred eventual outcome for some people).
| PROBE-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.
2. Is it your intention that a call to PROBE-CDR merely checks whether the specified CDR's functionality is already available in the Lisp instance, or that PROBE-CDR might load some files/modules/systems or otherwise change the state of the Lisp instance to arrange that the functionality of CDR-NUMBER becomes available?
As it shall return a true value if the code is available, but only after the code is loaded, the intention is indeed to load whatever systems are needed. Should I use a different name? REQUIRE-CDR?
| CDR implementations MAY be provided by third-party libraries. Such | libraries SHALL define [m]ethods of PROBE-CDR function corresponding | to provided CDRs.
3. Similar to my first question, what should happen if two libraries want to provide the same CDR? They'll clobber each other's PROBE-CDR methods.
Technically speaking, the same problem applies to require and some built-in loadable extensions and apparently nobody suffers too much from that. I hope that generally the downstream CDR-relying code doesn't care too much which CDR implementation is loaded (in most cases). Should we encourage :around methods and handling conflicts?