SRFI support matrix is now auto-generated Lassi Kortela (03 May 2020 10:09 UTC)
Re: SRFI support matrix is now auto-generated Erkin Batu Altunbas (03 May 2020 11:42 UTC)
Re: SRFI support matrix is now auto-generated Lassi Kortela (03 May 2020 11:47 UTC)
Re: SRFI support matrix is now auto-generated Erkin Batu Altunbas (04 May 2020 16:26 UTC)
Re: SRFI support matrix is now auto-generated Arthur A. Gleckler (04 May 2020 17:19 UTC)
Re: SRFI support matrix is now auto-generated Erkin Batu Altunbas (04 May 2020 17:27 UTC)
Re: SRFI support matrix is now auto-generated Erkin Batu Altunbas (04 May 2020 17:37 UTC)
Re: SRFI support matrix is now auto-generated Arthur A. Gleckler (03 May 2020 16:25 UTC)
Re: SRFI support matrix is now auto-generated Erkin Batu Altunbas (03 May 2020 16:46 UTC)
Re: SRFI support matrix is now auto-generated Lassi Kortela (03 May 2020 17:00 UTC)
Re: SRFI support matrix is now auto-generated Duy Nguyen (03 May 2020 16:47 UTC)
Re: SRFI support matrix is now auto-generated Lassi Kortela (03 May 2020 17:26 UTC)
Re: SRFI support matrix is now auto-generated Duy Nguyen (04 May 2020 08:59 UTC)
Re: SRFI support matrix is now auto-generated Lassi Kortela (04 May 2020 13:06 UTC)
Re: SRFI support matrix is now auto-generated Erkin Batu Altunbas (03 May 2020 17:00 UTC)
Re: SRFI support matrix is now auto-generated Arthur A. Gleckler (03 May 2020 17:02 UTC)
Re: SRFI support matrix is now auto-generated Lassi Kortela (03 May 2020 17:05 UTC)
Re: SRFI support matrix is now auto-generated Erkin Batu Altunbas (03 May 2020 17:09 UTC)
Re: SRFI support matrix is now auto-generated Lassi Kortela (03 May 2020 17:16 UTC)

Re: SRFI support matrix is now auto-generated Lassi Kortela 04 May 2020 13:06 UTC

>> Snow packages should all have an email address somewhere in the package
>> metadata (if you download the tar file from snow-fort.org and grep for
>> '@' you'll probably be able to find it). Reaching all the different
>> authors could take quite a bit of time and work.
>
> This is why I want some kind of "group author" to have upload access
> to snow-fort.org instead of one person.

The easiest way to accomplish that would be a shared r7rs-srfi GitHub
repo where you can give access to a group of people. The whole repo
could then be uploaded to snow-fort as one package. That's how chez-srfi
is done in Akku: <https://akkuscm.org/packages/chez-srfi/>.

> Though now that I think more
> about it, this probably should not be srfi editors (which are about
> the documents, not about wasting time on maintaining srfi
> implementations for all schemes).

In fact, anyone who is willing to contribute fixes to a particular
SRFI's sample implementation, or to add an entirely new sample
implementation, is allowed to do so. At least that has been my
impression of recent activities. Just ask on a SRFI's mailing list
and/or send pull requests to the SRFI's GitHub repo :)

>> A unified "r7rs-srfi" collection could also make sense. The chez-srfi
>> package (from Akku) despite its name is effectively "r6rs-srfi" now. It
>> explicitly supports several different R6RS implementations. The same
>> could be done for R7RS.
>
> I'll look more into it.

Thanks! Last I checked, @arcfide who curates chez-srfi was quite
responsive and helpful so if you have any questions about a similar r7rs
project he might be able to help. Göran Weinholt (who I think is
subscribed to this list) wrote Akku and also has a lot of experience
with r6rs<->r7rs portability. This guy @okuoku as well:
<https://github.com/okuoku/yuni>. This is a good idea and it would be
great to get a group of people together to do it.