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 Marc Nieper-Wißkirchen 31 Jul 2020 09:13 UTC

Am Fr., 31. Juli 2020 um 10:49 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

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

There could always be one SRFI in draft status, which accepts new
registry entries in the meantime.

The noise will then mainly happen on the mailing list of that SRFI.

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

SRFIs do not need entries in the features list. As long as they define
a library with its name, a cond-expand with this library name is
enough to check for its existence.

By the way, the claim that a scheme implementation supports that many
SRFIs doesn't say much about the quality of the support, in particular
when just the generic sample implementations have been copied.
Moreover, more SRFIs doesn't necessarily make an implementation a
better system. So in many cases, one should shrug this off as
advertising.

(Look at Guile's non-existing built-in support of SRFI 121 to get a
different view on the topic:
https://lists.gnu.org/archive/html/guile-devel/2019-07/msg00000.html.
Mark's arguments are sound, but they mean that an implementation may
be better with fewer SRFIs. SRFI 121's generators have been wired into
many other SRFIs lately because it has been claimed that they are much
faster than, say, SRFI 41 streams. Apparently, they are not. And
without a proof that SRFI 41's streams cannot be made nearly as
efficient as generators, it would have befitted Scheme as a functional
language to replace generators by streams. Haskell shows that
efficient implementations of streams are possible. But that's a
different area needing improvement.)

Marc