Libraries at scheme.org? Lassi Kortela (26 Jan 2021 22:49 UTC)
Re: Libraries at scheme.org? Vladimir Nikishkin (27 Jan 2021 01:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 07:28 UTC)
Re: Libraries at scheme.org? Vladimir Nikishkin (27 Jan 2021 01:34 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 07:46 UTC)
Re: Libraries at scheme.org? Arvydas Silanskas (27 Jan 2021 08:26 UTC)
Re: Libraries at scheme.org? Marc Nieper-Wißkirchen (27 Jan 2021 08:36 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 08:51 UTC)
Re: Libraries at scheme.org? Arvydas Silanskas (27 Jan 2021 10:34 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 13:17 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 14:07 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 16:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 17:34 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 18:10 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 19:54 UTC)
Re: Libraries at scheme.org? Lassi Kortela (29 Jan 2021 13:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 08:37 UTC)
Re: Libraries at scheme.org? Duy Nguyen (28 Jan 2021 10:29 UTC)

Re: Libraries at scheme.org? Lassi Kortela 27 Jan 2021 17:34 UTC

> 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.