[R6RS] Module naming

Wed May 10 09:47:45 EDT 2006

Doing some legwork preparing for the Dagstuhl presentation, I got to
thinking about our module naming syntax.  For several reasons, I think
what we currently could be improved:

- The URI doesn't serve any significant purpose at the moment.  As
  Alan Bawden suggested, it might serve the purpose of keeping names
  globally unique if we registered the "scheme:" scheme; but I don't
  get the impression we'll be doing that.

- If the library modules are to be a viable deployment mechanism for
  code, they need to take into account code evolution via some form of
  versioning.  Otherwise people will quickly go crazy figuring out
  what libraries work with what other libraries.  I've certainly seen
  that happen a lot with XEmacs's libraries over the years.

If we're not bound to URIs, it makes more sense to use an S-expression
representation for module names.  This would also allow us to do
something sensible about the versioning.  I stole ideas from CPAN,
Ruby Gems, PLT's PLaneT, and an old draft of a (never realized) XEmacs
package system I wrote.

With respect to SRFI 83, this would require splitting up <lib-path>
into two non-terminals, <lib-name> and <lib-ref>.  The library form
is:

(library <lib-name> <language> <body>)

Where:

<lib-name> ::= (symbol>+)
             | (<symbol>+ <version>)

<version> ::= (<uinteger 10>+)

Examples:

(r6rs hash-tables)
(srfi 1)
(de deinprogramm mike gravity (1 1))

Now, the path gives a fixed name to the library, and <version> gives
some kind of version information in the form of a sequence of
numbers.  As a first benefit, it gives the creator of a library module
the opportunity to ship different versions of his library under
different names, without having to be creative about them.

Now, <import-set> goes like this:

<import-set> ::= <lib-ref>

<lib-ref> ::= (<symbol>+)
            | (<symbol>+ (<version-ref>+))

<version-ref> ::= <uinteger 10>+
                | <version-cond-ref>

<version-cond-ref> ::= (>= <uinteger 10)
                     | (<= <uinteger 10)
                     | (and <version-cond-ref>+)
                     | (or <version-cond-ref>+)
                     | (not <version-cond-ref>)

This allows the user to specify that she wants one out of a set of
matching available library modules, to be chosen by the
implementation.

Examples

(r6rs hash-tables) ; matches (r6rs hash-tables)
(srfi 1)           ; matches (srfi 1)

(de deinprogramm mike gravity (1))  
  ; matches (de deinprogramm mike gravity (1))
            (de deinprogramm mike gravity (1 0))
            (de deinprogramm mike gravity (1 0 1))
            (de deinprogramm mike gravity (1 1))
            ...

(de deinprogramm mike gravity (1 1))  
  ; matches (de deinprogramm mike gravity (1 1))
            (de deinprogramm mike gravity (1 1 5))
            (de deinprogramm mike gravity (1 2))
            ...

(de deinprogramm mike gravity (>= 1))
  ; matches (de deinprogramm mike gravity (1))
            (de deinprogramm mike gravity (1 1))
            (de deinprogramm mike gravity (2))
            ...

(de deinprogramm mike gravity (and (>= 1) (<= 3)))
  ...

Thus, (<version-ref>+) specifies a predicate on a prefix of the
<version> specification in the library name.  Everything not in the
prefix always matches.  This imposes very little policy on the version
convenions, except that version numbers lose significance down the
list.

A restriction comes with this, namely that no two library modules with
the same symbolic name but at different versions can co-exist in the
same program---otherwise, you might get incompatible types, replicated
state etc.  It may be desirable to lift this restriction later and let
libraries declare that different versions co-exist, but that's
probably best left for later.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla