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)
|
>> Right. But then you'd get many (for example, yearly) differently >> numbered versions of SRFI 97. Not such a big problem on 1-2 a year >> timescale, but it adds up over a decade. > > SRFI numbers are cheap. I agree as long as new SRFIs address new problems. But if there are many SRFIs deprecating old ones, it leads to something like the internet RFC collection, where each RFC's header says "obsoleted by" some other. It's a bit of a maze to follow all those links and figure out which documents one should use. If there are major problems in the existing SRFIs/RFCs for some applications, then a publishing a new document is probably the right call and can't be avoided. But in my opinion, we should avoid gratuitously publishing new SRFIs about the same topics unless there is a substantially different approach or a major problem is fixed. Such SRFIs definitely need to be allowed (to avoid favoritism since criteria are subjective), but I think they should not be encouraged. >> But R6RS is not obsolete; it's a parallel version of the language. It's >> a matter of taste whether it's better, worse, or equally good as R7RS. > > That wasn't my point. I wanted to say that it would need a new SRFI > version anyway. No problem :) I'm committed to be neutral on RnRS. Scheme can't afford to lose the talents of adherents of any standard or implementation. If there is a registry (of any sort) for library names then you're right that the publication of R7RS would have meant adding entries. > Apparently, the inventors of R7RS thought differently. :) There have > built a few IMHO needless incompatibilities and changes from R6RS into > the new version. They probably had to choose between compatibility and being consistent - never a fun decision to have to make. For most things (library names, variable/procedure/macro names, feature identifiers) we can thankfully make aliases in case we want to deprecate old names. For read syntax it's a bigger burden but can still be done in principle (e.g. R6RS vs R7RS syntax for vector literals). An identifier registry could have a way to indicate that some identifiers are aliases where one of them is favored in particular circumstances (e.g. (scheme list) for R7RS and (srfi :1 lists) for R6RS.