Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 13:34 UTC
> On the contrary, R5RS is an excellent illustration of the principle -- > it still is the most successful Scheme standard of all, even more so > than R7RS-small. Even non-schemers revere R5RS. > > Okay... it's a good yardstick if you are interested in the absolute core > of a language, but the idea of R6RS and R7RS-large is to write practical > applications as well. True. I may sound pedantic by using R5RS as an example, but I'm trying to make a serious point: that de facto standards are the real standards, and by extension, anything we _can_ get agreement on is a standard in practice, and anything we can't get agreement on is not. The content or scope of the things being standardized doesn't matter in this respect. Technically, there's no upper limit to what it makes sense to standardize. It's human factors that make the ceiling. We could standardize everything up to Strong AI if we were smart enough to figure out how. As it stands, it seems human factors put the limit at about R7RS-small without options. > On the other hand, things whose use we don't want to encourage shouldn't > be added to a report. For new code, there are absolutely zero reasons to > use ER if syntax-case is also available. So having both in the same > report doesn't make a lot of sense. And making both optional parts would > lead to a lot of unportable libraries. Good point. It would be prudent to poll implementers about this. > Compared with R7RS-small "locked", R6RS didn't "lock" many more things. > From memory: mostly hash tables (but they would be needed anyway), > syntax-case (a feature in existence and well-understood since R4RS, or > so), conditions (much needed for real-world code), and enumerations > (being added in an extended way to R7RS-large anyway). > In hindsight, it would have been much better if R7RS had proceeded from > R6RS. R7RS-small could have been R6RS with some parts optional and > R7RS-large could have been R6RS with extra bells and whistles. Also the library system (this seems unequivocally a good thing: a language without a standard way to write libraries has no way to share reusable code). > I'd argue that R6RS did the greater wrong because it added > controversial > stuff. They should first have written the implementations, and if > consensus emerges, then the standard. Or written a standard by some > other name than RnRS, RnRS being the flag bearer of Scheme. > > There had been implementations of the stuff. Sure, the implementations co-evolved with the standard. But only some implementations. A Scheme standard not taken up by MIT Scheme and Gambit is not a credible Scheme standard. Both of them accepted R7RS-small. Kawa, one of the long-running large Scheme implementations, is not taking up R7RS-large despite substantial effort from its author to come to terms with the new standard. > If R7RS-large is the baseline for R8RS, there won't be an R8RS I > suppose. It's not a good comparison, but it's like making C++ the > baseline of the next C standard. This gets at the heart of the matter: there needs to be a steady succession of future RnRS reports (probably about one per decade) because RnRS is the only place where compatibility can be established without shims and other hacks. Treating the reports as visionary projects, apart from making it hard to get community-wide agreement on them, gets in the way of this mundane but essential work with the compatibility glue. A trivial example is that (library ...) and (define-library ...) are incompatible which puts us in a Python 2-vs-3 like situation where it's not possible to write a portable library file. The resolution of this everyday problems is held up indefinitely since R7RS-large is not shipping on any particular schedule, and it can't ship on a schedule because visionary work is not predictable. Scheme needs a design process that runs at intervals on a predictable schedule and fixes these little inconveniences. Only RnRS is suited to be that process. The C and C++ comparison is interesting. C++ is almost a superset of C, but not quite; there are trivial incompatibilities that nevertheless make it hard to write a C program that compiles without warnings as a C++ program. It's like R7RS-small and R6RS. I believe there isn't enough agreement in the Scheme community to standardize anything with the scope of R6RS or R7RS-large (with all options implemented) with the rigor expected from the RnRS process. Our realistic options are to do something on the R6RS scale, but factored into optional features; and to do something on the scale of R7RS-large (and beyond!), but using a much less rigorous process. No existing technical work need be wasted! If we refactor the social processes, we can continue building on the existing technical work without a hitch. > Standards do no fight wars. :) Nor do the people of the different > communities. They just use different languages to some extent. > > All that one can say is that R6RS is currently as legitimate as is R7RS > as is R5RS. And that if you want to learn Scheme as a newcomer you may > want to take look at Racket, which is a huge superset of most "official" > standards. If there are multiple legitimate standards, it dilutes the legitimacy of them all, and ultimately the legitimacy of the standards process. An outsider would be excused for concluding that Scheme has no legitimate standard. I feel our formal standards process is obscuring the state of de facto standardization. Ultimately, the point of a de jure standard is to have a de facto standard. That's the only thing that makes it legitimate long term. A de jure standard can exert its formal authority to go beyond de facto, but there are consequences. The greatest error is to be so convinced of our de jure authority that we lose touch with the de facto situation. The reign of any such standard won't last long.