Arne wrote:
Would it be possible to start into that by creating prefixes for the
different package repositories?
(akkuscm ...) and (snow-fort ...)
I advise against doing that, as the same package can be published to
multiple repositories.
Would that be a problem? All it needs is a reference that reliably works
in Guile. The akku/snow-fort equivalent for srfi.
I think it's not the best decomposition of the problem. At their core,
Akku and Snow are package indexes. Pointers that say, "in order to
obtain a copy of library X, use URL foo".
At the source code level, a Scheme library does not care where its
dependencies are obtained from. A particular version of a particular
package should perhaps be identified by a cryptographic hash of its
source code. And any place you can obtain a blob with that hash is fair
game. This is the Git model.
If we include the name of a package index in the library name, I think
we're promoting package indexes too much. It's just not the right mental
model, and that has secondary effects.
Maybe even something like the shims in the r7rs benchmarks: they have
preludes for the different schemes with which they can run the tests.
Making a set of Guile preludes and for each package some info which
prelude is needed to run it could make the packages work out of the box
for many. And it could be generalized to many different Schemes.
I recommend that each Scheme implementation natively support all the
RnRS feature, and that the Scheme community come up with standard test
suites for each RnRS edition. There is substantial work in this
direction, IIRC championed by Will Clinger, but my memory is fuzzy.
(how do I find out whether they are portable? Do I have to try?)
Last I checked, you just have to try.
Maybe we could start there for portability: create a list of packages
which work with Guile. Do you happen to have the start of such a list
from your testing?
I haven't kept track of compatibility with any Scheme implementation.
The general principle is (or should be) that each package is a
collection of libraries; each library imports other libraries; and any
Scheme implementation that can support those libraries can support the
library that depends on them. Where this is not the case, IMHO time is
better spent fixing that than manually keeping compatibility lists.
