CDR-14 and optional modules

Michael Raskin 38a938c2 at rambler.ru
Sun May 26 09:42:19 UTC 2019


>if you don’t load code that implements a feature you wouldn’t be able to push a feature onto the *FEATURES* list.

Well, it is _also_ useful to indicate availability of implementation-provided support for the feature that it is just a `require` away. Basically the ideal case would be to have trivial-X use CDR numbers to get implementation specific bits, then see what exactly is available and build a unified interface on top.

Should that be something like

«
generic function CDR-MM:PROBE-CDR (NUMBER)

If CDR number NUMBER is available in the current environment, load the associated code (if necessary), ensure that :CDR-NUMBER symbol is in *FEATURES*, and return the package containing the implementation; otherwise return NIL.
»

then?

>>        I look at CDR-14 that says about putting :CDR-NN symbols into
>> *features* if implementation purports to implement a CDR. What is the
>> recommended behaviour in the case when the implementation provides 
>> a loadable module to support a CDR? Should the feature be always present
>> or only appear when the module is loaded?






More information about the cdr-discuss mailing list