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: Prior art: SRFI 97 Marc Nieper-Wißkirchen 31 Jul 2020 10:18 UTC

Speaking of prior art: Python has PEPs and Java has JSRs. How do these
systems handle that kind of thing?

Am Fr., 31. Juli 2020 um 12:13 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >> 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.