There used to be a website a long time ago, but for now your link is it, unfortunately.
R7RS is the Revised⁷ Report on the Algorithmic Language Scheme, the latest common-ground description of the language.
Revisions up to and including R5RS were fairly minimalistic (even if not all of the features new to R5RS are uncontroversial) and specified essentially no library facilities, which were usually either completely implementation-specific or released as RFC-style documents called SRFIs (Scheme requests for implementation). As a result, toy, teaching, or research implementations of Scheme were fairly easy to make, but moving programs between implementations was a bit of a crapshoot.
The reaction to that was R6RS, which is—if not the length of the Common Lisp spec—similar in scope, with utility and OS interface libraries, an extensive macro system, a freshly designed module system, and a lot of other stuff. When SRFIs for the new functionality existed, R6RS certainly took inspiration from them, but its redesigns were neither fully compatible nor taken through the public SRFI process (the standard was still subject to public discussion, but in a different venue with different procedures). And people wanting a minimal standard to implement on their own (a not insubstantial part of Scheme users) were told that R6RS wasn’t for them and pointed back to R5RS.
Long story short, the few commercial Scheme vendors (first of all Chez Scheme, prior to the Cisco acquisition and open-source release) largely adopted R6RS; the rest of the implementor community largely ignored it or cherry-picked some parts—and that means not only the myriad hobby implementations, but also the medium-scale ones like Chicken, Gambit, or Gauche. I think even Guile (whose stance on minimalism mirrors that of most other GNU software) requires some wrangling to get it close to R6RS.
R7RS was intended to close that divide: there’s R7RS-small, which is an R5RS-style lean spec, and R7RS-large, which was intended to be a R6RS-style real-world language, but composed with more respect to existing practice and SRFIs and with more implementor buy-in. It was to be released in several issues organized by topic (data structures, I/O, etc.). John Cowan managed to get a couple of these out the door over the last decade, but the efforts seem to have stalled. AFAIK Chez, the gold standard of real-world implementations how that PLT Scheme has reinvented itself as Racket and gone its own way, has also indicated no interest in even looking at R7RS-large however nice it turns out, because they have customers now and that takes priority over ecosystem health.
Racket is not an extension of Chez; Chez is an implementation language for Racket (it replaces most of the C code in earlier versions). See my comment above about implementation languages.
The main benefit of basing Racket on Chez instead of C was maintainability. A bit of performance and a few fairly unimportant features (like single floats) were lost.
Eh. Giant headaches is overstating it, I think, if we're talking Lisp post 2005 or 2010: Common Lisp implementations are largely compatible; Racket only has one implementation (and no spec); in Scheme you'll have to spend a bit of time porting between the three or four big implementations that can actually run your stuff, big whoop. (On this forum I probably have to mention Arc, but I don't believe it ever grew beyond a personal project.) I'd say that the main obstacle to adoption was rather the (apparent) absence of shinies (and boy were there a lot of competing shinies at the time).
Even if this were correct, though, my experience is that I find very little enjoyment in things that are targeted at what in your terms is success. For example, Go feels dreadfully unpleasant even though I can't deny the good—occasionally downright brilliant—engineering that went into it, kind of like a mass-produced concrete residential building. Let's be honest, I'm in this largely for the hackery, a little bit for the feeling of having solved somebody's problem, and not in the slightest for the social acceptance. You might not agree here (or you might!), but I hope that, if one day nobody does, I still have the self-awareness to step away from the computer and go do something else.
> For example, Go feels dreadfully unpleasant even though I can't deny the good
For me Go feels like Pascal cut off C's face and is wearing it Hannibal Lector style.
That said, it's an absolutely fabulous language, standard library included, for implementing a worldwide ads serving network. Gotta give them that. For other problems that are more or less technically similar it's also great.
That’s not quite so true. The Common Lisp standard actually works pretty well for having many conforming implementations. For example SBCL, which it’s fair to call a nontrivial program, is portable across itself, CMUCL, Clozure CL, CLISP, ABCL, and ECL.
On the other hand, a theorem prover written by John McCarthy in 1958 was trivially adaptable to both Common Lisp and Scheme. Not too many languages get to make that claim.
Thanks, that is helpful background. I can see how it would be difficult find agreement between groups who want compatibility with R6RS, and those who want compatibility with SRFIs.
The 7th version of the Scheme standard/specification, basically. There's a "small" and "large" version of it, for different use cases/preferences (there's a bit of drama behind this: R6RS introduces a lot of "large" features that many implementers felt were too "bloated", which was eventually resolved by splitting the standard in small/large variants).
R7RS is the Revised⁷ Report on the Algorithmic Language Scheme, the latest common-ground description of the language.
Revisions up to and including R5RS were fairly minimalistic (even if not all of the features new to R5RS are uncontroversial) and specified essentially no library facilities, which were usually either completely implementation-specific or released as RFC-style documents called SRFIs (Scheme requests for implementation). As a result, toy, teaching, or research implementations of Scheme were fairly easy to make, but moving programs between implementations was a bit of a crapshoot.
The reaction to that was R6RS, which is—if not the length of the Common Lisp spec—similar in scope, with utility and OS interface libraries, an extensive macro system, a freshly designed module system, and a lot of other stuff. When SRFIs for the new functionality existed, R6RS certainly took inspiration from them, but its redesigns were neither fully compatible nor taken through the public SRFI process (the standard was still subject to public discussion, but in a different venue with different procedures). And people wanting a minimal standard to implement on their own (a not insubstantial part of Scheme users) were told that R6RS wasn’t for them and pointed back to R5RS.
Long story short, the few commercial Scheme vendors (first of all Chez Scheme, prior to the Cisco acquisition and open-source release) largely adopted R6RS; the rest of the implementor community largely ignored it or cherry-picked some parts—and that means not only the myriad hobby implementations, but also the medium-scale ones like Chicken, Gambit, or Gauche. I think even Guile (whose stance on minimalism mirrors that of most other GNU software) requires some wrangling to get it close to R6RS.
R7RS was intended to close that divide: there’s R7RS-small, which is an R5RS-style lean spec, and R7RS-large, which was intended to be a R6RS-style real-world language, but composed with more respect to existing practice and SRFIs and with more implementor buy-in. It was to be released in several issues organized by topic (data structures, I/O, etc.). John Cowan managed to get a couple of these out the door over the last decade, but the efforts seem to have stalled. AFAIK Chez, the gold standard of real-world implementations how that PLT Scheme has reinvented itself as Racket and gone its own way, has also indicated no interest in even looking at R7RS-large however nice it turns out, because they have customers now and that takes priority over ecosystem health.