Hello,

"Andrew Wilcox" <xxxxxx@andrewwilcox.name> 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.