A lot of SRFIs don't have many tests. It might be nice to gather a big, up-to-date test suite for all SRFIs.
Or keep up-to-date tests in each SRFI's repo with the sample implementation.
That will be nice.
The problem with updating test in SRFI sample implementations is that we would probably need permission from each SRFI's author, and we probably can't reach most of them to approve new code. Some popular SRFIs are almost 20 years old.
It might be good for Scheme implementors to create a common test repo on GitHub or GitLab and gather tests for lots of different SRFIs there. It would also be an opportunity to use the same testing framework for all of them. I'll start a thread about this on srfi-dicsuss.
the SRFI is the documentation.
We already discussed that matter in SRFI schemedoc mailing list. We disagree. In my opinion, SRFI documents are not user documentation. Simply refering gambit user to the SRFI document is not good enough. A proper implementation documentation will need examples uses, a useable comment system. And also systematic documentation of all forms. Unlike some SRFI document like (scheme mapping) aka. SRFI-146 that bolt together (scheme mapping) and (scheme mapping hash) together (see https://srfi.schemers.org/srfi-146/)
Those are good points. Perhaps it would be better to rely on a Scheme-wide documentation site for this stuff instead of Gambit (and every other Scheme) having its own detailed documentation for each SRFI. It would take a lot of effort and pressure off Scheme implementors.
The https://clojuredocs.org/ and https://www.php.net/ facility where users can post comments to supplement the official documentation is nice. Perhaps a Wiki would be even better. The https://srfi-email.schemers.org/schemedoc/ list is probably the best place to discuss this.
Most of the SRFI implementations from udem-dlteam/libs will probably be merged into Gambit's main repo once they have been tested enough; libs is mostly for work-in-progress stuff.
It will be easier if that was a draft pull-request against gambit repository. It will help with discovery and it will also take advantage of gambit repository Continuous Integration.
They're in a separate repo instead of a PR so we can do:
gsi -:whitelist=github.com/udem-dlteam/libs
A GitHub pull request corresponds to a Git branch in someone's fork of the Gambit repo. In principle, the module system ought to be able to download that branch instead of the master branch. I don't know whether anyone has tried this.
Gambit's CI builds all of Gambit (gsc and gsi) which does quite a bit more work than just building some SRFI implementations. Eventually, once the SRFI implementations are optimized for Gambit, it makes sense to build them with Gambit and rely on the CI.
I don't like SRFI 64. It is impossible to run a single test with SRFI-64. I am looking forward an introspection or reflection library system (something like guile or chez does) so that it is possible to run a single test where a test are procedures.
That probably doesn't require reflection; just a command-line flag for the test runner to specify which tests to run or which to skip.
Reflection would probably help with running tests in a running gsi from Emacs using Geiser.
SRFI 64 is popular so we should to have it. That doesn't mean we can't have other APIs as well. For example, (chibi test) is also popular so it would be good to have. It's best if all these different test APIs can be implemented using Gambit's native API.
See `library-exports` at https://github.com/amirouche/arew-scheme/blob/master/make-check.scm#L22
I already tried to use SRFI-64, at the very minimum it requires to wrap `test-fu` forms inside a procedure like chibi scheme does.
Not sure what to do about this.
Trying with tab completion in gsi, Gambit already has things like:
##procedure? ##procedure-friendly-name
as well as the ##symbol-table used in the apropos. You might be able to put something together using the primitives that are already there.