Re: Establishing a Scheme registry

Am Sa., 1. Aug. 2020 um 05:49 Uhr schrieb John Cowan : > > > > On Fri, Jul 31, 2020 at 5:13 AM Marc Nieper-Wißkirchen > wrote: > >> >> https://lists.gnu.org/archive/html/guile-devel/2019-07/msg0.html. >> Mark's arguments are sound, but they mean that an implementation may >> be better with fe

Re: Establishing a Scheme registry

On Fri, Jul 31, 2020 at 5:13 AM Marc Nieper-Wißkirchen < m...@nieper-wisskirchen.de> wrote: > https://lists.gnu.org/archive/html/guile-devel/2019-07/msg0.html. > Mark's arguments are sound, but they mean that an implementation may > be better with fewer SRFIs. In order to show that, you or

Re: Establishing a Scheme registry

On Fri, Jul 31, 2020 at 4:39 AM Marc Nieper-Wißkirchen < m...@nieper-wisskirchen.de> wrote: We may need further registries, for example for standardized feature > identifiers that extend the small list in R7RS-small. > +1 > I would have proposed to use the SRFI process for it. Whenever there >

Re: Establishing a Scheme registry

> From: Lassi Kortela > Date: Friday, July 31, 2020 3:14 AM > > Earlier this week we discussed on the SRFI 198 mailing list that there > should be a community-wide registry for foreign error types. The set of > known error types is necessarily evolving so it can't be in the SRFI. It > will sur

Re: Establishing a Scheme registry

> From: "Arthur A. Gleckler" > Date: Friday, July 31, 2020 3:09 PM > > On Fri, Jul 31, 2020 at 1:39 AM Marc Nieper-Wißkirchen > wrote: >> [ These aren't Scheme extensions. ] > >> I think it is simpler or safer than inventing a new process, whose life may >> depend on the lifetime of the git

Re: Establishing a Scheme registry

On Fri, Jul 31, 2020 at 1:39 AM Marc Nieper-Wißkirchen < m...@nieper-wisskirchen.de> wrote: > We may need further registries, for example for standardized feature > identifiers that extend the small list in R7RS-small. > > I would have proposed to use the SRFI process for it. Whenever there > is a

Re: Prior art: SRFI 97

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

Re: Prior art: SRFI 97

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 o

Re: Prior art: SRFI 97

Am Fr., 31. Juli 2020 um 11:40 Uhr schrieb Lassi Kortela : > > > Please note that this is not the process I have proposed. Instead of > > adding to some not formally archived data file, a new version of SRFI > > 97 would have been published (say with each iteration of R7RS-large), > > obsoleting th

Re: Prior art: SRFI 97

Please note that this is not the process I have proposed. Instead of adding to some not formally archived data file, a new version of SRFI 97 would have been published (say with each iteration of R7RS-large), obsoleting the respectively previous one. Right. But then you'd get many (for example,

Re: Prior art: SRFI 97

PS SRFI 97 is obsolete anyway when it comes to R7RS systems. The new naming scheme does not include, for example, a plural "s" in the second part of the library name. This, actually, is an argument in favor of the SRFI process I have proposed because a new SRFI can easily overwrite and change these

Re: Prior art: SRFI 97

Am Fr., 31. Juli 2020 um 10:59 Uhr schrieb Lassi Kortela : > > There's a registry in SRFI 97: SRFI Libraries. > > > As that SRFI shows, things get a bit messy. The document lays out > guidelines for what to do in the future about new entries, and add

Re: Establishing a Scheme registry

Am Fr., 31. Juli 2020 um 10:49 Uhr schrieb Lassi Kortela : > - 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

Re: Establishing a Scheme registry

Good idea :-) Le ven. 31 juil. 2020 à 10:14, Lassi Kortela a écrit : > > Earlier this week we discussed on the SRFI 198 mailing list that there > should be a community-wide registry for foreign error types. The set of > known error types is necessarily evolving so it can't be in the SRFI. It > wi

Prior art: SRFI 97

There's a registry in SRFI 97: SRFI Libraries. As that SRFI shows, things get a bit messy. The document lays out guidelines for what to do in the future about new entries, and added a post-finalization note last year about the fact that the name

Re: Establishing a Scheme registry

We may need further registries, for example for standardized feature identifiers that extend the small list in R7RS-small. Yes. I have some sketches at - just simple S-expression files. I would have proposed to use the SRFI process for it.

Re: Establishing a Scheme registry

We may need further registries, for example for standardized feature identifiers that extend the small list in R7RS-small. I would have proposed to use the SRFI process for it. Whenever there is a major change in the registry, an updated SRFI (only containing that registry) is issued while the pre

Establishing a Scheme registry

Earlier this week we discussed on the SRFI 198 mailing list that there should be a community-wide registry for foreign error types. The set of known error types is necessarily evolving so it can't be in the SRFI. It will surely be useful to define other evolving sets of things in future SRFIs.