On Mon, May 4, 2020 at 12:26 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
> > If that's the case, those SRFIs should be added to some repository
> > like Snow. We know if it's portable by looking at the repo, and the
> > user can also get it easily. We could reserve a namespace in snow for
> > srfi reference implementations.
>
> This is probably the ideal way to implement the above (short of bundling
> tailor-made SRFI implementations with each Scheme, which is more
> time-consuming, and implementors often don't even want to include all
> SRFIs with their Scheme).
>
> > I could start with some srfi that I know from experience is portable
> > enough. But I think we need to make sure srfi editors have the right
> > to update these packages if needed (haven't looked closely at snow
> > yet)
>
> That would be great.
>
> 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. 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).

> 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.
--
Duy