Thanks for writing to the list, Adam!
A suggestion for a global namespace: something under (scheme ...),
like (scheme contrib _) or (scheme extra _). That marks the namespace
as "reserved", but still allows as many entries to be added as
necessary without colliding with anything in the official R7RS.
Good idea but R7RS-small says: "Libraries whose first identifier is
scheme are reserved for use by this report and future versions of this
report."
Maybe R7RS-large could specify that (scheme something ...) is reserved
for this purpose. In practice, it wouldn't conflict with anything that's
currently in Scheme.
Since this is a new idea, do we have the moral authority to add stuff
under (scheme ...) though? Maybe it should first be tried out under some
less official prefix.
Also, when it comes to development style: will this library be made up
of /specifications/ that each Scheme implements differently (like
SRFIs), or of a single /implementation/ that tries to be compatible
with as many Schemes as possible (a la Schemepunk)?
The starting point should be that it's implementation first (or
implementation and discussion), and once the implementation stabilizes,
a stable specification is the end product.
In other words, the opposite direction than what SRFI is currently
using. (Classically, I guess a SRFI specification is intended to be the
end product of implementation work that has first been done elsewhere,
so in that respect the library collection would be one central place to
do this groundwork for SRFI. Of course, people could still submit SRFIs
prepared elsewhere.)
The https://github.com/pre-srfi organization currently serves as an
unofficial staging area for SRFI. A library collection would basically
be the same thing, but putting all libraries in a monorepo with
collective ownership instead of separate repo per library, each owned by
one person.
If it's the latter, contributing to this repo will quickly become
overwhelmingly complex. Keeping 7 Schemes working in Schemepunk is
already a lot to juggle, and the test suite takes a long time to run.
I was recently bitten by a bug where the whole thing didn't work in
Gauche 0.9.10, but I was using an older Gauche so I didn't notice...
Yes, it does sound that good CI would be essential in the long run.
The collection has to be portable if it represents Scheme as a whole.
That can only work if libraries in the collection are allowed to start
out unportable and gradually be ported to more Schemes as people have
time and interest to do the porting work. If full portability was
required from the start, no-one could add things that require FFI
bindings without writing bindings for everything. That would be quite
demoralizing :)
Each sublibrary could have its own compatibility matrix, but we'd have
to track this carefully and set up a test method for each Scheme and
possibly even multiple versions of each Scheme.
This is a good idea IMHO. Letting CI run the test suite and produce the
compatibility matrix based on passed tests sounds like the right thing.
