SRFI metadata
Erkin Batu Altunbas
(19 Apr 2020 16:58 UTC)
|
Re: SRFI metadata
Arthur A. Gleckler
(19 Apr 2020 17:06 UTC)
|
Re: SRFI metadata
Erkin Batu Altunbas
(19 Apr 2020 17:14 UTC)
|
Re: SRFI metadata
Lassi Kortela
(19 Apr 2020 17:18 UTC)
|
Auto-parsing SRFI lists from Scheme implementations' tar files
Lassi Kortela
(19 Apr 2020 18:29 UTC)
|
Re: Auto-parsing SRFI lists from Scheme implementations' tar files
Lassi Kortela
(19 Apr 2020 20:30 UTC)
|
Re: Auto-parsing SRFI lists from Scheme implementations' tar files
Lassi Kortela
(19 Apr 2020 20:32 UTC)
|
Re: SRFI metadata Erkin Batu Altunbas (19 Apr 2020 18:50 UTC)
|
Re: SRFI metadata
Lassi Kortela
(19 Apr 2020 18:59 UTC)
|
SRFI lists from Frank in 2019
Lassi Kortela
(19 Apr 2020 19:13 UTC)
|
Re: SRFI lists from Frank in 2019
Lassi Kortela
(19 Apr 2020 19:18 UTC)
|
Re: SRFI metadata Erkin Batu Altunbas 19 Apr 2020 18:50 UTC
I quickly generated a preliminary table to get a feel of how it would be like. https://github.com/schemedoc/srfi-metadata/blob/master/table.html > On 19 April 2020 20:18 Lassi Kortela <xxxxxx@lassi.io> wrote: > > SRFI support is complicated by the fact that an implementation can > either have a particular SRFI built into it; ship with the SRFI as a > loadable Scheme library; or rely on a third-party package to provide it. > For example, Chez and Chicken are two implementations that have very few > SRFIs built in but a very large collection available separately > (Chicken's collection is all the eggs named srfi-*, and Chez's > collection is chez-srfi by @arcfide). > > (In principle, an implementation can also support a particular SRFI only > on particular platforms. Or SRFI support could be turned on and off with > build time options. However, I'm not aware of any cases like this > currently.) > > In practice, schemedoc should also have a package index of Scheme > libraries other than SRFIs. (We already have a pretty comprehensive > scraper at <https://github.com/schemedoc/packhack>, it just needs to be > polished and plugged into a general organizing backend.) Akkuscm.org and > Snow-Fort.org also provide easy-to-read package metadata. > > Once we have the package index, we can somehow auto-detect which of > those packages implement SRFIs, and which implementations they run on. Yeah, I only opted to include SRFIs that are built into the stdlib of each implementation. I think we could mark third-party SRFI support with the colour yellow on the table. Either way, there needs to be more work put into it. I'll go through all these sources once I can and update the data we have thus far. ~erkin