Am Fr., 25. Feb. 2022 um 00:53 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > On Sun, Feb 20, 2022 at 10:05 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: > >> In fact, if R7RS-large wants to fulfill the goals that are set for it, >> it will have to include a subset equivalent of R6RS anyway. Now with >> syntax-case having become a part of R7RS-large, everything speaks for >> actually using R6RS as this subset and not to create something >> incompatible. > > > When the Steering Committee (Clinger, Feeley, Hanson, Rees, Shivers) appointed me chair of WG2, they asked me to draft the charter. My original included a clause requiring compatibility with R6RS. I got more pushback from the SC on that clause than on the whole rest of the charter. The SC definitely did *not* want full R6 compatibility, although they were okay with transplanting components of it, as the current charter provides for. I am the SC's servant, so if you want change here, you need a political solution: you can lobby the SC to change its mind, or raise a groundswell of public opinion that the current SC should be replaced. If it emerges that essential compatibility with R6RS is not possible on technical grounds, this is one thing, but forbidding R6RS compatibility on political grounds is en clair just stupid and petty-minded. >> Thus, we will probably >> have to build on existing implementations; no one can recreate what >> went into Gambit, Chez, Racket, etc. for twenty or thirty years or >> more in a year or two. > > > I agree with this. Indeed, we may need two: one based on an existing R6 and another based on an existing Small. The issue then is which implementations require the least modification and/or are easiest to modify. The only practical solution that will also yield the best for the community is in my opinion not to modify an existing implementation to create an R7RS-large fork, but to persuade the maintainers of such an existing high-quality implementation to steer their implementation towards R7RS-large compatibility. >> At least as much as with implementations, we should be concerned with >> the audience of the standard. It's a difference if we want to address >> some niche programming projections or if we want to see wider adoption >> of the resulting language in mainstream software development. > > > I don't think we can see *wide* adoption in 2022 or later without support from a commercial company, in which case the language will be what the company wants and not the community. I agree with the danger that lurks here. On the positive side, we see that a lot of programming languages with a wide adoption exist that vary a lot with respect to how companies influence them. >> In any >> case, R7RS-large has to offer more than existing standards and (!) >> tools. At the moment, for example, using R6RS together with some >> existing portable libraries (e.g. SRFIs) still gives me a more >> productive environment than the current R7RS-large. > > > Please tell me which libraries you have in mind. I mean that adding more and more portable libraries does not really create an argument in favor of R7RS-large because these libraries (which exist as SRFIs with implementations in the public domain) can simply be used with an R6RS system. The only difference is that R7RS-large allows me to write, say, (import (scheme list)), where for an R6RS system, I would write (import (srfi : 1)). R7RS-large would get a unique selling point once its core would surpass that of R6RS, but this is still far from being true even after so many years of development. Apparently, the SC didn't want it but the R7RS-large project would be much more successful (and possibly even finished) had R6RS been taken as its base so that one could have directly started to build its roof (and necessary bits for R7RS-small compatibility). At the moment, we are still building the roof with the foundations still in flux and with no clear direction.
