Discoverability of CDR implementations (pre-submission discussion)
Ooops, sorry, sent to the wrong list. Forwarding to the correct one.
Hello I was told that it might be better to have a separate document about interaction of CDRs and packages. I think as the problem with packages for CDR-defined symbols is about discoverability and probing, it is a good idea to also provide some functionality for probing for available but not loaded CDR implementations. The draft is currently available at: https://gitlab.common-lisp.net/mraskin/cdr-walkability/blob/master/cdr-packa... It is also attached as a text file to this message All feedback is of course very welcome. Thank you, goodbye Michael Raskin
On Sun, Jun 23, 2019 at 06:08:57PM +0200, Michael Raskin wrote: Hi! I do not think i can contribute to this discussion for lacks of skills, but i find it very interesting, though! :) Anyway i have spotted what i thinks are couple of typos: [...]
This document proposes instead a minimalistic way. The aim is to obtain tangible benefits with minimal effort, limited oordination and limited ^^^^^^^^^^^ [...]
CDR implementations MAY be provided by third-party libraries. Such libraries SHALL define ethods of PROBE-CDR function corresponding to provided CDRs.
^^^^^^ Thanks for your works! Bye! C.
I do not think i can contribute to this discussion for lacks of skills, but i find it very interesting, though! :)
Thanks for kind words! And user interest is probably more important than minor improvements of the interface.
Anyway i have spotted what i thinks are couple of typos:
Indeed. Sorry. Thanks. Fixes pushed to the repository.
On Mon, Jun 24, 2019 at 08:22:54PM +0200, Michael Raskin wrote:
I do not think i can contribute to this discussion for lacks of skills, but i find it very interesting, though! :)
Thanks for kind words!
No problem! Looking forward for CL improvement even if i think i am going to switch to "lurking mode", at least for now. :) [...] Bye! C.
Hello, I have three questions (of which number 2 is most important) and one comment about the proposal. | 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. | 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. (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. | 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? I ask because the sentence "In this case the implementation of the CDR SHALL be fully loaded (and the corresponding symbol added to the *FEATURES* list)" is vague to me: I can read it either as a static description of the circumstances under which PROBE-CDR returns true rather than false, or as a description of actions to be performed by PROBE-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. Thanks, Richard
| 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?
participants (3)
-
cage -
Michael Raskin -
Richard M Kreuter