A package is more than a library collection. It would include test code.
It would include meta-information. It could even include executable
scripts that are used to actually generate the libraries on the target
system. In general, it doesn't make sense just to grab some subtree of
the library collection.
The distinction is further complicated by the fact that a featureful
Scheme implementation like Gambit doubles as a package manager. So a
package manager can be:
1) built into the Scheme implementation
2) external program specific to particular Scheme implementation
3) a third-party package manager supporting more than one implementation
Fortunately our main concern is interfaces, not implementations. If we
deliver a spec that works for all of these cases, it doesn't matter.
Earlier I first claimed that "package = library collection" and then
that "package = authority about where and how to find libraries". These
are conflicting definitions in both theory and practice. Sorry!
It seems that all of these concepts are useful:
1) library [i.e. some Scheme code]
2) library with metadata
3) collection of libraries [possibly all have the same metadata]
4) authoritative info on where and how to get collection of libraries
But it's not clear to me how they should be divided technically.
There could be a simple tool converting a single library into such a
package.
True. It could also be implicit. Not clear on this yet.
I didn't mean that rewriting shouldn't be used but that the default
mapping isn't that useful IMO.
I'd leave it to implementations and their user communities to figure out
a good default mapping for each; I assume there's a lot of variety in
what works well.
E.g. Kawa should probably have defaults that make sense in a JVM context.
- The .scm vs .import.scm vs .sls vs .sld ... file extension wars.
- The %-encoding of filenames for R6RS libraries.
- The R6RS numbers-in-library-names thing.
- Case folding in filenames.
- Reading Scheme libraries from zip/tar files.
- Reading files from URLs vs local computer.
- Reading from git and directories.
I would call this "compiling" and not "rewriting" because it may involve
even more.
The rewrite language could be Turing-complete and imperative, but I
would strongly prefer a non-Turing-complete and declarative one.
