1) R6RS puts the version number in the “library” form. This is not ideal
because managing version numbers manually is error prone. It is better to
leave the “tagging” of the sources with the version information to the VCS.
The version number doesn't have to be specified in the library
definition written by the programmer. It's enough to specify the version
number in an import.
2) R6RS uses semantic versionning for checking the compatibility of libraries
(what is required vs. what is available). Semantic versionning is a neat
theoretical approach that just doesn’t work in practice (because humans are the
ones that are responsible for ensuring the semantic version attached to a
library is “correct”… and humans are error prone).
Good point.
So I think R7RS should not adopt the R6RS syntax or semantics for the version
information. Gambit uses a symbol starting with an “@” to indicate the
version, for example (import (foo bar @1.2.3)) .
If my reading of R6RS is correct, (import (foo (1 2 3))) will import any
library name (foo (1 2 3 ...)) where ... stands for zero or more integers.
Maybe we could use the same syntax, but interpret it such that (import
(foo (1 2 3))) will match exactly (foo (1 2 3)) and no other versions.
I'm not aware of anybody using the R6RS wildcard matching, and some
people really do want to use it, R6RS has standard >= and <= matchers.
We could also permit symbol(s) in addition to integer(s) in the version
part of the library name, which would let us match git tags of any form,
not just `x.y.z`.
Gambit also uses git for the VCS, and for this to work well the “root” is
considered to be a package and there can be libraries inside that package. So
libraries (foo bar) and (foo baz) are two libraries inside the package foo.
There could be a toplevel library (foo) in package foo, but it is not a
requirement. Simple libraries typically are the only library at the root of
the package of the same name. Finally, it is packages that are versionned and
not libraries. This matches most VCS systems, including git, that put version
information on the repository (package) and not on individual files.
Yes, this is definitely convenient for the implementer.
An unconventional approach would be for the Scheme library names to
refer to a package index. The index would map library names to package
(e.g. git repo or tar file) URLs. So the user would import libraries and
the right packages would be consulted transparently.
From a security perspective, this requires the package index to be
trusted in addition to the git repos from which packages are fetched.
The index also needs to be updated frequently in order to present an up
to date picture of all available libraries. This is all quite a bit more
complicated than having the user type packages URLs directly into Scheme
(import ...) clauses.
