Email list hosting service & mailing list manager

SRFI metadata Erkin Batu Altunbas (19 Apr 2020 16:58 UTC)
Re: SRFI metadata Arthur A. Gleckler (19 Apr 2020 17:06 UTC)
Re: SRFI metadata Erkin Batu Altunbas (19 Apr 2020 17:14 UTC)
Re: SRFI metadata Lassi Kortela (19 Apr 2020 17:19 UTC)
Re: SRFI metadata Erkin Batu Altunbas (19 Apr 2020 18:51 UTC)
Re: SRFI metadata Lassi Kortela (19 Apr 2020 18:59 UTC)
SRFI lists from Frank in 2019 Lassi Kortela (19 Apr 2020 19:13 UTC)
Re: SRFI lists from Frank in 2019 Lassi Kortela (19 Apr 2020 19:18 UTC)

Re: SRFI metadata Lassi Kortela 19 Apr 2020 17:18 UTC

> I took the liberty to use the SRFI metadata repository with some info
> I compiled together today.

Great work. Thanks for the iniative!

> Inspired by, I want to use
> it to generate an HTML table.

Sounds good. is nice!

> It's rather incomplete right now because
> some implementations aren't very open about which SRFIs they support
> for some reason. Although I found a few pages on the web that loosely
> described SRFIs each implementation supports, I felt like those might
> be out of date so I just consulted the official webpages or README
> files for all of them save for Larceny, SLIB and TinyScheme.

That's true. They are not being intentionally obscure -- it varies a lot
in general how up-to-date and comprehensive each Scheme implementation's
documentation is.

Downloading the latest source archive (or doing a git clone) and doing
something like `git ls-files | grep -i srfi` is a good start. Also,
plain old grep on file contents :) But you managed to gather a very good
list already.

Shiro's Scheme Cross Reference wiki also has a nice SRFI roundup:

I recall Frank Ruben also made a nice list last year, but I can't find
it under Schemedoc or right now. I'll search my email

It may be possible to write some simple Scheme-implementation-specific
rules (filename/grep patterns) to produce a of SRFIs supported by that
implementation, given a tarfile of the implementation's source release.
I've generally found that automating data extraction is not much more
work than doing things by hand, and is much less error-prone. It also
leaves instructions that others can study and run for how you managed to
find the info.


SRFI support is complicated by the fact that an implementation can
either have a particular SRFI built into it; ship with the SRFI as a
loadable Scheme library; or rely on a third-party package to provide it.
For example, Chez and Chicken are two implementations that have very few
SRFIs built in but a very large collection available separately
(Chicken's collection is all the eggs named srfi-*, and Chez's
collection is chez-srfi by @arcfide).

(In principle, an implementation can also support a particular SRFI only
on particular platforms. Or SRFI support could be turned on and off with
build time options. However, I'm not aware of any cases like this

In practice, schemedoc should also have a package index of Scheme
libraries other than SRFIs. (We already have a pretty comprehensive
scraper at <>, it just needs to be
polished and plugged into a general organizing backend.) and also provide easy-to-read package metadata.

Once we have the package index, we can somehow auto-detect which of
those packages implement SRFIs, and which implementations they run on.