Email list hosting service & mailing list manager

Establishing a Scheme registry Lassi Kortela (31 Jul 2020 08:14 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (31 Jul 2020 08:39 UTC)
Re: Establishing a Scheme registry Lassi Kortela (31 Jul 2020 08:49 UTC)
Prior art: SRFI 97 Lassi Kortela (31 Jul 2020 08:59 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 09:18 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 09:20 UTC)
Re: Prior art: SRFI 97 Lassi Kortela (31 Jul 2020 09:39 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 09:58 UTC)
Re: Prior art: SRFI 97 Lassi Kortela (31 Jul 2020 10:13 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 10:18 UTC)
Python PEPs Lassi Kortela (31 Jul 2020 10:23 UTC)
Re: Python PEPs Marc Nieper-Wißkirchen (31 Jul 2020 11:12 UTC)
Re: Python PEPs Lassi Kortela (04 Aug 2020 07:04 UTC)
Re: Python PEPs hga@xxxxxx (04 Aug 2020 09:28 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 13:31 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (31 Jul 2020 09:13 UTC)
Re: Establishing a Scheme registry John Cowan (01 Aug 2020 03:49 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (01 Aug 2020 06:29 UTC)
Re: Establishing a Scheme registry John Cowan (01 Aug 2020 13:19 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (01 Aug 2020 13:48 UTC)
Re: Establishing a Scheme registry Amirouche Boubekki (01 Aug 2020 13:55 UTC)
Re: Establishing a Scheme registry Arthur A. Gleckler (31 Jul 2020 20:09 UTC)
Re: Establishing a Scheme registry hga@xxxxxx (31 Jul 2020 20:34 UTC)
Re: Establishing a Scheme registry John Cowan (01 Aug 2020 01:58 UTC)
Re: Establishing a Scheme registry Amirouche Boubekki (31 Jul 2020 09:04 UTC)
Re: Establishing a Scheme registry hga@xxxxxx (31 Jul 2020 20:52 UTC)
Re: Establishing a Scheme registry Lassi Kortela (01 Aug 2020 19:50 UTC)

Re: Establishing a Scheme registry Lassi Kortela 31 Jul 2020 08:49 UTC

> We may need further registries, for example for standardized feature
> identifiers that extend the small list in R7RS-small.

Yes. I have some sketches at
<https://github.com/srfi-explorations/identifiers> - just simple
S-expression files.

> I would have proposed to use the SRFI process for it. Whenever there
> is a major change in the registry, an updated SRFI (only containing
> that registry) is issued while the previous version will be withdrawn.
>
> I think it is simpler or safer than inventing a new process, whose
> life may depend on the lifetime of the git repo chosen.

Very interesting and novel idea.

I like it from an archival point of view, in which it is indeed
reliable. The only thing I worry about is that it would generate "noise"
in the SRFI process:

- How often would a new registry SRFI be published, and where would new
submissions be gathered in the meantime?

- Scheme implementations typically claim that they support particular
SRFI numbers. What (if anything) should they say about which registry
SRFIs they support? It they list all of them, it would cause a lot of
new identifiers in (features) and (cond-expand) over the years. Perhaps
such registry SRFIs should simply be omitted from the (features) list.

If the git repo is tied to the SRFI process, it would be safest to have
a policy of storing it in the same place as the other SRFI repos. In
fact, perhaps they could be stored as S-expression files in
<https://github.com/scheme-requests-for-implementation/srfi-common>.
Arthur already has scripts to generate HTML pages out of data files in
that repo, so perhaps extra page(s) could be generated for the registry.