An immediate reply on the most important issue for SRFI 198:

From: Lassi Kortela <xxxxxx@lassi.io>
Date: Monday, July 27, 2020 10:29 AM

> [ Good stuff on the groveler. ]
>>
>> However, currently the SRFI omits your catalog APIs in favor
>> of a future SRFI, in large part because I expect that people
>> will use the SRFI in an ad hoc manner.  Which for libraries
>> like libsodium is pretty much the only want to use it, there's
>> no organization to its errors beyond the function reporting an
>> error.> And of course to keep the API as small as is reasonable.
>>
>> Is that decision wrong?
>
> The catalog API was deliberately designed so that it can cope with
> incomplete or altogether missing catalogs. I.e. the programmer can be
> happy that a particular error collection is enumerable and use that
> information, but should not rely on that to be the case.
>
> Since enumerating an error set means "these error codes exist, but other
> ones may exist as well", a missing set can be treated the same as an
> empty set.
>
> For those reasons, I thought it's ok to include enumeration in the same
> SRFI. No decision on the topic is objectively right or wrong, it's a
> matter of taste.
>
> FWIW, Python has an errno module like this:
> <https://docs.python.org/3/library/errno.html>. In particular:
>
> errno.errorcode -- Dictionary providing a mapping from the errno value
> to the string name in the underlying system. For instance,
> errno.errorcode[errno.EPERM] maps to 'EPERM'.
>
> To be honest, enumerable error sets are probably useful mainly for
> interactive use (REPL, future Scheme IDEs and the like). It's nice to be
> able to browse error codes interactively.

In that case, it's worth bundling all of this together, assuming the
catalog procedures are pure Scheme, albeit of course requiring input
from foreign systems to use them.  Exposing that e.g. errno 2 is ENOENT
has been my pet project for SRFI 170, and a regularized system to both
create and query such a catalog would be great.  And naturally used
to replace the ad hoc hash table map I currently use.

If John and the community at large agrees this is the Right Thing, can
you provide some code to implement these APIs?

- Harold