Standardizing SRFI metadata

[lassik]

@diamond-lizard I'm opening this issue to explore the SRFI metadata problem specifically, since the scope of pre-srfi/scheme-metadata-files is both more general and (in other ways) more specific.

Let's walk backward from the end result. To generate the big table, we need an S-expression like this:

((chez
  (0 external)
  (1 external)
  (2 external)
  (4 external)
  (5 external)
  ...)
 (chicken
  (0 release)
  (1 external)
  (2 release)
  (4 release)
  (6 release)
  (8 release)
  (9 release)
  (10 release)
  (11 release)
  (12 release)
  (13 external)
  (14 external)
  (15 release)
  ...)
 ...)

Here the symbol is external or release or pre-release to indicate how that SRFI is supported in that implementation. Missing SRFIs are unsupported.

We know:

• Each implementation has zero or more SRFIs in built-in.

• Some implementations have their own package collection, serving packages for that implementation only. E.g. Chicken eggs. Each package implements zero or more SRFIs.

• There are also cross-implementation package collections like Akku and Snow-Fort. Each package implements zero or more SRFIs for one or more implementations.

• Each package collection has an index of all the packages in it.

This suggests the following standardization:

• Each implementation has some file in its source release that lists all the built-in SRFIs.

• Each package collection has a machine-readable package index that lists all the SRFIs implemented by each package.

• The cross-implementation package collections have some way of indicating in their index which Scheme implementations are supported by each package. If this information is unavailable, we need to make an educated guess.

Currently there is no standardization:

• Scheme implementations' source releases don't ship any standard metadata file.

• Package collections haven't standardized their per-package metadata, and also haven't standardized their package indexes.

[lassik]

This shows the utility of storing all of a package's metadata in one S-expression: If instead of SRFI information, we wanted to list license information, or author information, that problem would have exactly the same shape as this problem, just using different fields of the metadata. The authoritative source for the information would be in the same place (in each Scheme implementation, and in each package) and could be aggregated to the index of each package collection like the SRFI information.

Likewise, if the package index is an S-expression (as it already is for Akku) it can be naturally made as a list of the individual packages' S-expressions.

If at any point there is too much information, just (filter do-i-care-about-this-part? the-s-expression)

[jpellegrini]

One thing: some R6RS libraries have SRFI equivalent, and the table doesn't show them.
For example, Guile (and other R6RS implementations) have (rnrs io ports), which do implement SRFI-192 completely. But the table does not show these implementation as supporting SRFI-192, because in them it is called rnrs io ports...

[lassik]

Good point. Same thing with the libraries in the work-in-progress R7RS-large: each library is one SRFI.