List supported SRFIs

[lassik]

We should aim to eventually list the bundled-srfi-implementations for all releases of all implementations.

Bundled vs third-party SRFI implementations

The word bundled is important. Some SRFIs can be implemented in pure Scheme, so for example Chicken offers some of them as optional third-party packages instead of bundling them with the implementation (Peter Bex brought this important distinction to our attention). A list of third-party SRFI implementations is not as easy to amass, hence the scope will be clearer if we stick to the bundled ones in this metadata.

The problem of finding third-party SRFI implementations can be solved by putting that information in package metadata instead of Scheme implementation metadata. If each package (currently in packhack, eventually in some more principled package index :p) optionally lists what SRFI(s) it implements, and also lists what Scheme implementations it supports, then we can write a little code to derive a list of third-party packages that extend the SRFI support of a given Scheme implementation.

How to gather the list of bundled SRFIs for each Scheme implementation

We would ideally have a list for each release of each implementation, so we need some mostly automated solution tailor made to each of them. Writing the lists by hand is too error-prone if we want to cover all historical releases.

We could start from hand-written lists, though. Arthur has a comprehensive and reasonably error-free list covering recent versions of many, many implementations.

Frank has some code to auto-extract lists from the documentation of a few implementations. This could serve as the starting point for the auto-extraction tools.

[weinholt]

I'm working on an issue in Akku where I need to know the bundled SRFIs for R6RS implementations, so I'll be amending the lists here a little. The data eventually goes into (akku lib schemedb).

FWIW: https://gitlab.com/akkuscm/akku/issues/19

[weinholt]

Larceny 1.3 has a weird split in SRFI availability wrt the R6RS and R7RS names. An example is SRFI-127, which exists as (srfi 127) but not as (srfi :127). Should this be shown in bundled-srfi-implementations?

[lassik]

I'm thankful to have you contributing to these listings as well. The practical experience from Akku will be valuable for sure...

Larceny 1.3 has a weird split in SRFI availability wrt the R6RS and R7RS names. An example is SRFI-127, which exists as (srfi 127) but not as (srfi :127). Should this be shown in bundled-srfi-implementations?

...case in point :) I was waiting for special cases like this to show up.

I think it should be split into two separate lists. But it's also possible that a Scheme implements an SRFI on one OS but not another, etc. We can't anticipate all situations. Hence, should we go whole hog and put a SRFI 0 cond-expand style construct in there?

[lassik]

Something like:

(release
 (version-number "1.3")
 (bundled-srfi-implementations
  1 2 11 13
  (127 r7rs)))

So a plain <srfi-number> is always supported. A list (<srfi-number> <condition>) means that SRFI is only supported when the condition is true. It should probably have nested and/or/not operators to make it even crazier :) Like so:

(release
 (version-number "1.3")
 (bundled-srfi-implementations
  1 2 11 13
  (127 (and r7rs (or linux freebsd) 32-bit (not ppc)))))

[lassik]

If we have those conditional expressions, we could take the opportunity to decouple the lists from the (release ...) forms. Like so:

(bundled-srfi-implementations
 (1   ("1.2" ..))
 (2   ("0.9" .. "1.1" "1.3"))
 (127 ("1.3" ..) (and r7rs (or linux freebsd) 32-bit (not ppc))))

So each SRFI would always be represented as a list: (<srfi-number> <version-list> [<condition>])

The version list could have:

• <a> .. <b> to denote all versions between a and b (inclusive)
• <a> .. at the end to denote a and all later versions

[lassik]

We also should not rely on any sort of lexicographic sorting algorithm to sort the versions from earliest to latest. We should probably not even rely on dates. Instead, the versions would be given in the right order in the file and the reader would trust that that is the correct sort order.

[weinholt]

I can't recall any case where a bundled SRFI is supported on only some of the target platforms, although I guess it could happen. But then I think it would be dependent on target OS, not the target architecture.

How about inverting it and using a regular cond-expand, which can be omitted if it's not needed:

(bundled-srfi-implementations
 (cond-expand
  (linux (1 13 98))
  (windows (1 13))))

Who is the intended audience for this? I don't think I can use too detailed variants of this in Akku, there I just want to know which SRFIs are already provided by a particular Scheme. I don't really know the target OS, machine or implementation version in advance; I just need something reasonable. If that exists. :)

[lassik]

The thing is, that kind of expressive power is bonkers for a task like this. Hopefully no-one will need it. But I was trying to prepare for the worst since schemas for data are much harder to change later than mere code is. If it was just code I would not start with something so complicated.

If you need to know whether a particular SRFI is supported by a particular implementation version under any circumstances at all, just ignore the feature expression and assume it's always true :) But you need to check for R7RS. Hmm. What to do.. I can't think of anything that doesn't get ludicrous.

[lassik]

We could add stuff like (report= r7rs) to the feature expressions. If we go down that road we're in danger of being showcased at Accidentally Turing-Complete :D

We could leave out the OS/architecture stuff but SRFIs for system interfaces are a reasonable idea, and it's quite plausible some could be implemented only for some OS (e.g. POSIX or Win32 API or some mobile stuff).

[lassik]

The regular cond-expand would depend on a lot of state from the Scheme implementation so it would make the form tricky to parse in a neutral environment. And it would basically mix basically full-on Scheme code inside what is supposed to be just a simple metadata format.

[lassik]

OK, this is getting embarrassing but this is the best I can think of:

(127 ("1.3" ..) (and (report? r7rs)
                     (os? (or linux freebsd))
                     (computer? 32-bit (not ppc))))

So all the symbols (here r7rs linux freebsd 32-bit ppc) have to be inside a form that says what type of symbol is being tested (here report? os? computer?). The reader can make it so that if the OS is not known, any (os? ...) form always evaluate to true. Likewise if the computer architecture is not known, any (computer? ...) form always evaluates to true.

Then it should work for all cases, with room for extension, and we only need and/or/not and not things like if/cond/equal/member.

I also thought about tri-state logic (yes/no/maybe) but let's not go there :D

[weinholt]

Could just write the set of SRFIs supported in some environment by the implementation and amend it with a comment if needed.

[lassik]

That could be done (i.e. rather have false positives than false negatives when it comes to SRFI support). But would that solve your R6RS vs R7RS case?

I would avoid putting any valuable information in comments since the data can be expected to be mangled, filtered and combined by many different tools.

[weinholt]

The R6RS vs R7RS case could be solved by listing the built-in library names instead of just the SRFIs. That would also be more generally useful, I think, because there's also a bunch of code that is shipped as libraries in implementations (e.g. IronScheme and Sagittarius) that should be more widely available.

[lassik]

OK, cool. Let's do that -- so we can keep the current simple format (bundled-srfi-implementations ...) with just the SRFI numbers for each release. We can add fancier stuff later if needed (e.g. by allowing a list (<srfi-number> <fancy-stuff...>) in place of an integer <srfi-number>). Listing the built-in libraries would be great anyway. We could plan that in its own issue.