Discoverability of CDR implementations (pre-submission discussion)

[Michael Raskin]

>| 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?