If I understand correctly, SRFI / RnRS libraries would be collectively owned by participants including maintainers of Scheme implementations that want to take part in the process? The alternative at the moment is to copy and tweak sample implementations or create an implementation from scratch.
Yes, exactly!
As far as I know cond-expand is not trivial to implement. And even if it was, it will not completely eliminate the problem that some Scheme may want to use a completely different implementation that will force us to have cond-expand based on implementations.
IMHO cond-expand is one of Scheme's best features, and probably impossible to eliminate for non-trivial programs which need to call out to things like SQLite, compression libraries, etc.
As far as I know there is no Scheme implementation that can run on a trivial subset of Scheme (that is maximally portable across Scheme implementations and Operating Systems), and that is easy to debug (breakpoints, step debugger, variable inspection, one step macro expansion). Including a garbage collector is too much work (I am clueless about the subject). Regarding things like threads, network or SRFI-170, it could be emulated (a portable C FFI can be a very useful addition :).
Good Scheme debuggers are very hard to do, as well as good error messages; those almost research problems in their own right. The implementations that have been around for 30 years probably have the best debuggers currently.
An emulator is a somewhat different problem from writing libraries for real work, though ideally those libraries would also run on the emulator.
I agree. I still wonder whether being portable like the projects below is not more work than the alternative I describe above. One drawback of relying a lot on external implementations, is that if the maintainer goes, scheme-live will end-up with debt code or we will need to decide to drop support for that implementation, which is a difficult choice.
My main interest in a portable library collection would be that it's useful for writing real programs. That means the code should run fast and be able to use all the features of the target Scheme implementations where it makes sense (while still retaining a portable API, so that switching from one Scheme implementation to another doesn't require rewriting programs that use the libraries).
The base64 and gzip libraries at <https://github.com/scheme-live/live/tree/a53b6365e9f1121d92ee5afb7bc55f03ba78bf34/live/encoding/filter> are an example of this approach.
One great advantage of libraries that are portable to many Scheme implementations is that it's a big encouragement to the authors of our existing implementations to continue their work. The Scheme community has a tradition of "implementation wars", which thankfully aren't really wars but more like debates. Our experience so far shows that we can't agree which Scheme implementation is the main one. The future of Scheme will continue to be based around many implementations, so making the most out of those implementations would be the most useful realistic outcome and would keep morale.
(The attempt to raise one Scheme implementation as the standard one resulted in Racket which is now its own community.)
The Smalltalk community has long had an interest in portable systems that reproduce exact behavior (e.g. arithmetic should produce bit-identical results on different computers). They pay a heavy price for that goal: Smalltalk implementations are not that fast, and they tend to become their own little islands, hard to connect to other languages and systems. For correctness, the portability is wonderful, though.
Also I support your approach to request some formal acknowledgement for this monorepo: the projects you mentioned below have tried to reach an informal consensus, but did not succeed, it can be improved and that is not wasted effort. scheme-live can probably re-use some of those libraries.
Thanks! Indeed, libraries can and should be copied from one collection to another, and a common collection should start with many of the SRFIs and pre-SRFIs we already have.
Those are great projects. Also it shows there is a strong interest about the subject.
Yes, they're great starts. The challenge is how to persuade all these people to work on one collection instead of 5-10 different ones :)
