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.