> 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 :)