Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 09:56 UTC
> I disagree slightly. R7RS-small is no more and no less a successful > consensus than R6RS. We have seen half of the community adopting R6RS as > a base and the other half mainly adopting R7RS-small. What I mean is that R7RS-small is relatively easy to add to an R6RS implementation. Sagittarius, Guile, Loko, and Ypsilon have already done so, and we could expect the same from the remaining R6RS implementations given enough pressure from their user communities. We can't expect R6RS or R7RS-large to be supported due to pressure from users, because those standards add so much new stuff. It's too much hard work to expect from an implementer who isn't already committed. R6RS wasn't added to Gambit, for example; there's an abandoned project to try it out. Kawa is big and has parts of R6RS but isn't R6RS compliant. > Both are successful in that they describe programming languages that > have been implemented and can be used. They differ in some details, of > course. R7RS-small may be more attractive to a general implementer > because it's smaller and because it gives the implementation much more > freedom. For the actual Scheme programmer, R6RS should be more > attractive because it is more complete and gives safety guarantees. > > I have come to the conclusion that it would have made at least as much > sense if not more to build R7RS-large on top of R6RS instead of > R7RS-small. With R7RS-large, the smallness argument of R7RS-small does > not matter anymore and R6RS is the better core language because it > provides a few things (like record inheritance, procedural macros, fast > hashtables, ...) that R7RS-small is lacking but which are very helpful > for R7RS-large. I guess we could eventually reshape R7RS-large into an > R6RS-large. Many seasoned schemers dislike R6RS on aesthetic grounds to the extent that building R7RS-large on top of it is likely to be politically impossible. It would also be incredibly bad PR: it would look like the Scheme community is directionless and has no ability to make decisions. What could work, is a standard that has everything from both R6RS and R7RS-small combined, so that a Scheme implementation supporting all features of the new standard will run all existing code from R3RS upward. That would also be a good look PR wise. "We admit that we made some mistakes with RnRS incompatibility, but now we have cleaned them up and the latest RnRS is again compatible with the earlier ones." As best I can parse the situation as a newcomer, a lot of this is on the Scheme Steering Committee. John has been fighting valiantly for backward compatibility in R7RS but the Committee instructed him that compatibility should be second priority. I think that's an astonishing attitude, and it's not John's fault. We can argue that R6RS was an irresponsible standard. But in the aftermath of an irresponsible standard, the job of the next standard is to suck it up and be the cleanup crew. Based on what I've been able to parse, the Committee's idea of a cleanup crew is a detonation crew. When the goal is to bring a community to an agreement, we don't go about reaching that agreement by detonating half of the community's buildings and rationalizing our actions by claiming no-one really lived in those buildings anyway, and if some people did, they're weirdos who are best ignored. > A few people left the group of R6RS editors in the process. > > This had the negative consequences that half of the Scheme community > outright rejected R6RS. On the other hand, on the positive side, R6RS is > now a very coherent standard, which is has been well-thought-of from one > end to the other. > > (The latter is also true for R7RS-small, which was easier to achieve > because of its smallness. It won't be true for R7RS-large unless there > will be some difficult consolidation process once we have arrived at the > ultraviolet end of the spectrum.) Lack of coherence is unfortunate but empirically, compatibility is the main determinant of a successful language standard. Python 2 vs 3 is a good example of coherence winning over compatibility. It was a social, technical, and PR disaster. > I don't think that R6RS and R7RS-small are very far from each other in > this regard. While implementing an R6RS needs more work than > implementing an R7RS-small, this difference is almost negligible for > implementations that want to be more than toy implementations. Something like syntax-case is definitely not negligible, and the R6RS portability guarantees (in the exacting sense of the word "portable") probably are not either. The proposal that seems best to me so far is to have all the R6RS stuff as optional modules. Then implementers could pick whether or not to have complex stuff like syntax-case. This is wonderful from a practical standpoint: most R6RS code doesn't use syntax-case, so a lot more useful code would work out of the box in a lot more implementations, even without implementing all the options.