Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 12:09 UTC
> The unfortunate thing about standards is that what wins is whatever > succeeds at establishing agreement. > > This isn't a good yardstick. Or R5RS would be the best of all. 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. I suspect that R7RS-small is near the upper limit of how complex a successful Scheme standard can be without relying on optional features. > Uniting R7RS-small with R6RS isn't too hard because it would be > basically R6RS+epsilon. The harder part would be to convince the > R7RS-small people that adding the R6RS stuff is good. Exactly! If the R6RS parts are optional, then implementations like Chibi and TinyScheme could still aim at conformance while keeping out the most complex stuff. Even simple compatibility such as supporting the same read syntax for symbols and vectors, and supporting both (library ...) and (define-library ...), would be a big help in practice. Every extra bit of compatibility helps. Having a unified R6RS+R7RS standard would encourage even the small implementations that leave out the complex features, to eventually support the R6RS and R7RS variants of those features that they do implement. This would add up to a lot more real-world code being portable. It would obviate the need to mess with command line flags like `-r 6` and `-r 7`, #!r6rs directives, .sld vs .sls extensions, etc. And perhaps equally importantly, uniting all schemers under the standard with the same name would have a positive psychological impact and stop our repeated exegeses about Scheme history that we cannot change :) > We come back to the unfortunate fact that successful standards > establish > agreement. R6RS is a successful language but an unsuccessful standard. > > Chez, Racket, and Guile are among the most successful Scheme > implementations. And they are all based on the R6RS (or have moved > there). In the case of Racket and Guile (and to a smaller extent also > Chez), they have moved much further, of course, but implement R6RS > nonetheless. You have a point. R6RS has successfully standardized the core features across important implementations. > It's possible to design a good language that is also a good standard > (i.e. reflects the consensus of the community). Scheme being in the > state that it is, the only way to do that is factoring it heavily into > optional features. > > That could be an approach for R8RS (= R6RS + R7RS-small) if "optional" > is not restricted to libraries. Agreed. In particular, macro systems would be profitable to standardize in RnRS. You have done excellent work cataloging them with your SRFIs. There's no reason RnRS couldn't have something like explicit-renaming as an option, considering that ER is already widely implemented in practice. Macro systems are not as tractable to add as libraries outside RnRS. It's all this compatibility glue that RnRS reports are uniquely well positioned to deal with. We can write third-party compatibility shims of all kinds, but the experience is never as nice as having all that good stuff built in. > R6RS is compatible with R5RS, but R6RS set future RnRS reports up to > fail. A standard should never do that. The R6RS continuity plan for > R7RS+ was "our way or the highway". What if it turns out the wider > commmunity doesn't want all those features? Too bad for them. > > Why wouldn't be future reports based on R6RS possible? They are very much possible, but what I mean is that R6RS locked future reports into a particular direction that wasn't based on a consensus. My opinion is that compatibility is the most important job of a standard; it directly follows that future reports can add stuff to the last report but not remove stuff. (They can make some previously optional stuff required, or required stuff optional, eventually phasing out optional stuff that nobody has used in a while. But it's not acceptable to remove stuff from the previous report. That's what caused the really big problems with Python 3; some code simply couldn't be written in a way that works in both 2 and 3, making the transition period painful for library authors.) From this point of view, R6RS added lots of stuff that R7RS has a moral obligation to support. R7RS didn't accept this obligation (reflecting the lack of consensus among implementers). The combined actions of R6RS and R7RS caused us to end up with this debate. 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. But since R6RS already did its deed and it was finalized, the moral duty (perhaps an unsavory one, but duty nonetheless) to maintain compatibility has now been passed to R7RS. If R7RS further adds new controversial stuff, it does the same thing R6RS did, and if finalized, passes the moral duty onto R8RS to keep all that controversial stuff. At present, Scheme is in a cycle where RnRS designers are wed to their personal vision and pass that vision onto the current implementers and the next RnRS designers. Implementers grumble, designers resent prior designers, the prior designers resent the next designers, and the community is ambivalent, apathetic, or disillusioned. These psychological reactions and attitudes are not unexpected. They are a predictable consequence of a process where the RnRS stewards are visionaries rather than scholars. A good scholar is diligent (which John is, to a truly incredible extent), and tries to translate the source material faithfully, adding as few of his own interpretations as he can. > I doubt that all the R7RS-large libraries will have to go into the next > formal RnRS report. For that, the libraries are too diverse and > inconsistent. At least a thorough clean-up effort would be needed. There are easily predictable psychological consequences to the entire community if each RnRS drops half the stuff from the prior RnRS. The process shouldn't be a Sisyphean task where each RnRS group rolls a boulder uphill, the next group rolls it halfway back down, and then up again. And adding new people to the community is hard if no-one can figure out which of the warring RnRS, if any, is legitimate. > Besides psyntax, there is André van Tonder's implementation (shipped > with Larceny). Then there is my own implementation in the form of > Unsyntax. And there is the implementation I wrote for Chibi Scheme. Jim > Rees has his own implementation, etc. > > The source code of the Chez Scheme compiler is very readable. It also > includes a syntax-case implementation, of course. Maybe you want to take > a look at that. Kent Dybvig's and his student's papers on syntax-case > and the library system are very well-written. Great, the situation is much better than I suspected. Congratulations for implementing it on your own; not an easy job!