Automatically determining implementation support (for example, Kawa supports SRFI 164)

[jpellegrini]

In fact, Per Bothner is the author of the SRFI, and Kawa is mentioned as reference there. But the SRFI is embedded, so trying to load it will result in error.

I'm not sure there is an easy way to tell which implementation supports which SRFI. The easy way is to fire up the interpreter/compiler and try to load it with import, require, or whatever is needed. But this doesn't catch embedded SRFIs.

Another way (much harder) would be to try do that but also have a mapping from SRFIs to list of symbols, and check wether each Scheme recognizes that list of symbols.

• still wouldn't catch the case in which the SRFI is available under a different name
• would not catch the case in which the implementation has the symbols, but they do not work as per the SRFI

Implementations that support SRFI-176 make this easier, but we can't rely on that...

[lassik]

Scheme implementors are open to feedback via email / issue tracker. As a general rule, I'd recommend asking implementors to work out an easy and reliable way to get the SRFI list instead of doing something complicated and heuristic.

Some implementations (e.g. many R6RS ones) have not been actively developed for a couple of years or more. In that case, we need to scrape whatever complicated bits of information add up to the full list.

It's good for users if each implementation lists the supported SRFIs in its manual. Hence, while we wait fora standard way to encode a machine-readable SRFI list, scraping the manual's source files is a good start. For example, the current Kawa scraper does that. If the manual doesn't list all SRFIs, we should send a patch to the manual.

SRFI 176 does have a (scheme.srfi 1 2 3 ...) property, but like all properties in that SRFI it's optional, so it's not a guaranteed source of the info. Running the implementation is also much more complex than scraping the sources.

[jpellegrini]

Ok - so the table is going to be partly written by a script and partly written (overridden?) by humans, is that correct?

[lassik]

Yes - ideally we get as much information as we can from a script, and only write things by hand when we have no choice. If we write a script, people know exactly what we did to get the listing, and can re-run the script to update the list. It's executable documentation.

[lassik]

The information in implementation-metadata was almost all written by hand since it's so heterogeneous that there isn't much of anything we could scrape without using advanced machine learning. Most other information is amenable to scraping.

[jpellegrini]

OK. I suppose we can close this, then.

But there is still the SRFI-164 issue. How does one enter that by hand? I'd do that if I knew how to.

[lassik]

Thanks for pointing out the missing Kawa SRFIs. The regexp we used was too strict, so it didn't catch a few of the entries in the manual. Now fixed.

[lassik]

How does one enter that by hand? I'd do that if I knew how to.

The schemes variable in listings.scm has the "ground truth" for what files and regexps to scrape for each implementation. Many/most of the shell scripts listings/*.sh are generated from that table.