Hello Sergey,

Thank you for your work on the Chicken SRFIs and for proposing metadata
standardization!

I agree that it is a good idea. We discussed it last year or early this
year on one of the SRFI or Scheme topics mailing lists but didn't
implement anything concrete.

Every current Scheme implementation is maintained in a git repo. Hence
the most natural way to implement your suggestion would be to put a
metadata file in each repo under a standard filename. Since source
releases (.tar.gz) are made from the repos, the metadata file would
automatically ship as part of each source release too. This would let us
easily find out the SRFI set for each release of each implementation.

Much of the table we've gathered with Erkin is already auto-generated by
scrapers that download a tar archive of the Scheme implementation's
source code and grep for things in it. We currently have a tailor-made
scraper for each implementation separately; they are in the "listings"
directory of the srfi-metadata repo [1]. Following your suggestion we
could eventually have one scraper that works for all implementations. A
big simplification, as you say. Since Scheme is based on S-expressions,
it would be most natural if the metadata file were an S-expression file.

One complication remains: Many implementations support extra SRFIs via
third-party packages in addition to the built-in SRFIs. Chicken is an
extreme example of this approach: almost all SRFIs are eggs. This
problem would be most naturally solved by having a similar standard
format for package metadata. This problem is also tractable. For
example, the current Chicken egg and Snow-Fort.org metadata files look
vaguely similar already. With the flexibility of S-expressions and
`cond-expand`, I'm confident we could specify a standard package
metadata format that works for everyone. If this were coupled with a
standard package index format, an automated scraper could parse an
implementation's package index and look for all packages that implement
SRFIs.

By adding the SRFI lists from the implementation metadata and the
package metadata, a fully automated scraper could build a complete table.

Would you (and others) be interested in collaborating on such a SRFI? If
so, I have another related idea related to library lookup that I'd like
to try and merge with it :)

[1]
https://github.com/schemedoc/srfi-metadata/tree/9ff8091a35c058ee531e989fae48db191014fcd6/listings