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: Prior art: SRFI 97 Lassi Kortela 31 Jul 2020 10:12 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.