Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 08:14 UTC
> I think a very good thing about the R7RS-large effort is the large > number of SRFIs it has been and is producing because it is moving the > Scheme language forward. > > The actual purpose of the R7RS-large effort, namely creating a ratified > language spec by declaring some of the SRFIs as "offical", is far less > important IMHO. Actually, I am no longer convinced that it is a good > goal for a number of reasons: > > * Far too few people (especially implementers) are active in the process. > * Even fewer people review, test and implement proposed SRFIs. > * The voting process can too easily yield arbitrary results depending on > who votes. > * The SRFIs making up R7RS-large handle similar things often very > differently. > * We often have just one implementation of a SRFI. Implementers of the > very fast implementations like Chez don't give feedback whether > implementing them would compromised performance. > > So when R7RS-large is finalized, we are simply giving a number of SRFIs > "official" status. The nice thing about it is that the can be accessed > through simple names like "(scheme list)". But, as John writes, this > also means that the underlying SRFI can only be replaced by an upward > compatible one. > > R6RS has library versioning, which would have helped. We would finalize > "(scheme list (7))" but that wouldn't exclude a different "(scheme list > (8))". Of course, there's always the possibility that we get back a > (stripped-down) form of library versioning back in the R7RS world. > > Please read again the first sentence. While this may not have been the > original goal of the R7RS-large process, it shows that it has already > been highly successful. We owe you a lot just for this, John. I basically agree with everything Marc said, both the praise and the plea for change, for the reasons he states. I also feel apologetic and self-conscious about directing so much criticism at R7RS-large (even though it's intended to be constructive and in good faith) since in practice John has to shoulder so much of the responsibility personally. R6RS was polarizing because it was a de jure standard that wasn't (and still isn't) a de facto standard. It didn't achieve de facto status because it added so much new stuff not backed by a consensus. The voting record shows that even the working group was divided internally but they forged ahead anyway. R7RS-small is a successful consensus standard, and -large mainly adds libraries on top of it, so -large is better positioned than R6RS in this respect. There are few changes to the core language on top of the consensus standard. However, the same process artifacts are showing as with R6RS: there is not broad consensus within the Scheme community about which R7RS-large libraries to adopt, and no working group internal consensus either. (WG2 members who disagree with the general direction tend to become passive or leave. In R6RS I assume most of them stayed but were outvoted.) I believe this outcome is not peculiar to R6RS or to R7RS-large, but is inherent in making any de jure standard that doesn't start from a de facto consensus. It's not about individual decisions made; it's inevitable due to the scope of the standard, which has been extended to cover areas of the language about which there isn't a consensus. IMO a standard has the moral duty to establish long-term agreement among implementers. The larger the scope of the standard, and the more novel stuff there is, the more difficult it is to uphold that duty. Something like R7RS-small is: people may grumble about the precise syntax or semantics of define-record-type or define-library, but implementers agree that the language should have records and libraries in something like their current form. There isn't similar agreement about what data structures and libraries the language should have (beyond lists, vectors, bytevectors, strings, and hash tables). Not only is near-term agreement important, but long-term agreement across the decades. This means that when writing a standard, succession should be planned in from the start. We should make it easy for writers of future Scheme reports to keep in agreement with the de facto consensus among future implementers. Since we lack the requisite foresight, the best bet is to be conservative and standardize things that are already widely implemented. This principle has guided the internet RFC process; https://tools.ietf.org/html/rfc2026 ("The Internet Standards Process") is quite clear about it. This does not in any way mean that the massive amount of work done on the data structures and other libraries in R7RS-large is ill-advised or wasteful. I simply don't believe that RnRS (and to a lesser extent SRFI) are right vehicles for carrying it and formalizing it. There are many indicators of this: the inability to establish a schedule and stick to deadlines; the unclear scope; disagreement among WG members on both the content of the standard and the process used to make it. All of these are indicators of exploratory rather than scholarly work. It's important to emphasize that there is nothing inherently wrong with disagreeing, taking a long time, and working in fits and spurts, but I think a standard should be more like a scholarly work that goes smoothly on a set schedule like a train. Predictability and lack of surprises are good ways to establish agreement; the design work involved in RnRS should focus on tweaking things that are already widely implemented. That's why I suggest that we keep all the high quality work that has gone into R7RS-large, and continue expanding it, but find another process to host it, a process that is built from the start to be an ideal vehicle for exploration rather than scholarship and refinement. If such a process enjoyed a similar de facto standard status as RnRS and SRFI, the libraries being made by that process would have the kind of high visibility and status that would help them be widely adopted over time. The key would be to build a default place for exploratory work in Scheme, and to invest schemers with ownership of that place so that it is well kept. SRFI and RnRS both involve de facto ownership of specs, and hence the specs are very well kept, but if we use these processes as intended the barrier to entry is prohibitive for exploratory work.