This page is part of the web mail archives of SRFI 84 from before July 7th, 2015. The new archives for SRFI 84 contain all messages, not just those from before July 7th, 2015.
Hello, "Andrew Wilcox" <awilcox@xxxxxxxxxxxxxxxxx> writes: > As a distribution format, my first thought was that keys would be the > natural thing to use to refer to the library name and whatever > libraries it imports. > > When I received a library, in raw form it might look something like > > (library a673482b8a1e23... 7812abe317... > (import 87a16327dea2...) > ...) > > (where these hex digits are supposed to suggest keys, although I don't > actually know what keys would look like). > > On my personal system, I can map these keys to whatever petnames I want. You seem to imply that: 1. The `library' and `import' forms would accept only cryptographic keys (name certificates) when designating libraries. 2. It is up to the user's editor to find the user's petnames that match the keys at hand and to display them, on the fly. Is this correct? My opinion is that using name certificates within the code would make code sharing quite tedious, because not all the tools you use would be capable of converting keys to petnames. For instance, suppose you get to view a piece of code with your browser: it's very likely that it won't be able to perform the conversion. Same with your e-mail client, etc. Furthermore, the library identifiers often (not always) denote an interface, rather than an implementation, as you mentioned here: > Suppose when I say > > (import 87a16327dea2...) > > that I'm referring not to a specific implementation of SRFI-1, but > instead to SRFI-1 as an API. > > When I send you my library of code that uses SRFI-1, I'm not saying > you have to use the exact implementation of SRFI-1 in my Scheme > system, I'm saying go ahead and use whatever is the best > implementation of SRFI-1 on your system. The two arguments suggest that perhaps we should keep petnames as library identifiers so that code is always human-readable. Hopefully, there will be ``obvious'' petnames such as, e.g., 'srfi-XX or 'rNrs that most people will understand without further explanations. When one needs to be more precise, they would publish, along with their code, their set of relevant name certificates. For instance, if I publish something like: (import html-parser) ... I should as well post a name certificate that says what `html-parser' is bound to in my local namespace (IOW: what this petname actually refers to), in order to disambiguate it. Conclusion: I believe code itself should still use simple identifiers (petnames) to designate implementations/interfaces. A cryptographically-protected naming scheme, à la SPKI/SDSI, is very desirable but it might rather be handled ``behind the scenes'', transparently, by the Scheme implementation. Thanks, Ludovic.