"Chez Scheme is one of the oldest Scheme implementations, and its evolution informed many parts of the Scheme standard through R6RS. (Racket's influence on the Scheme standard, in contrast, is limited to aspects of the R6RS library design.)..."
Why did Chez and Racket embrace R6RS, a standard widely rejected by the rest of the Scheme community?
Also, why did Racket choose Chez over some other high-performance Schemes, like Chicken?
Finally, how many Racket and Chez users are there compared to those of other Schemes?
The main implementors of Racket and Chez Scheme (Matthew Flatt and Kent Dybvig) were part of the committee that created the R6RS, and many of the ideas in R6RS came from Racket and Chez. Whether R6RS was "widely rejected" is of course up for debate, but the people that didn't like it decided that mostly after Matthew and Kent's contributions.
https://ecraven.github.io/r7rs-benchmarks/ is an ok comparison between Scheme implementations; you can see that Chez is much faster than Chicken in general. Chez also already supports many features beyond Chicken that were needed to implement Racket (for example, internal support that made delimited continuations easy).
It's hard to know exactly how many people use what, but it seems likely that Racket is the most widely used Scheme derivative.
I never understood that hate. R6RS is the only Scheme standard that makes it possible to write useful standards-compliant programs. R7RS-small is a big step back in that respect. The new standard is less of a burden on the implementer[0], and I guess that makes it popular in the Scheme community, as that mostly consists of people implementing Scheme and very few people writing Scheme programs.
I built a Chez Scheme backend for Idris (and Idris2 uses Chez as the default compilation target). I used it because it's so much better than the other compilers, and what's the point of being compliant with a standard that provides no interoperability anyway because it is so meager?
from what I gather (not an implementor) r6rs was too much to implement for the smaller 'testbed' scheme's popular with language designers, and perhaps a bit too proscriptive for the core - which is why r7 has the small/big split. small can be implemented more easily, and big can be added on as a portable library or alternately implemented at a more low level by the language runtime if desired
> Why did Chez and Racket embrace R6RS, a standard widely rejected by the rest of the Scheme community?
Why wouldn't they? The usual rationale for rejecting R6RS is that it's somehow "too big". But Racket already has a library whose size blows R6RS out of the water. So this rationale is irrelevant in this context. Also, Chez Scheme is an implementation detail. R6RS is only one of many languages that you may use through Racket.
And what is this "Scheme community" that rejected R6RS? It's always been my impression that it was rejected by authors of toy implementations. Is there actually any data on what portion of people who use Scheme (as opposed to write another implementation of it) reject R6RS?
> Why wouldn't they? The usual rationale for rejecting R6RS is that it's somehow "too big". But Racket already has a library whose size blows R6RS out of the water. So this rationale is irrelevant in this context.
No one begrudges Racket for having a huge library. The Racket team have obviously had enormous success building large, comprehensive real-world systems.
But Racket is an implementation -- not the Scheme standard. The historic value of the Scheme standard is its smallness and ease of implementation -- a small base upon which to build large systems. Large, comprehensive implementations -- such as T -- have been built on top of this small basis for almost as long as there's been an RnRS.
R6RS represented a fundamental shift in philosophy for what is Scheme. It de-emphasized the "small language kernel" approach and emphasized a comprehensive, software-engineering approach for building "real world systems". But the Lisp community already has a comprehensive, software-engineering-oriented language, Common Lisp (which borrowed some of its best features, like lexical scoping, from Scheme). So what's the point of building Scheme into a large software-engineering language to compete with Common Lisp?
It's a bit hard to fathom today, when most modern programming languages -- excluding ECMAScript but including, for example, Rust -- are defined in terms of a single reference implementation, but there are advantages to keeping the language standard small while allowing implementations to grow to arbitrary size and accrete features. Advantages which Scheme has turned into its own little niche among the family of Lisp programming languages.
> And what is this "Scheme community" that rejected R6RS? It's always been my impression that it was rejected by authors of toy implementations.
Of course, because Gambit, Chicken, and Gauche -- among others -- are mere toys.
A toy implementation that implements all of R5RS is at least possible. You can't build a toy implementation of Common Lisp, Python, or Rust, that covers even a small fraction of the core language. But you can build a Scheme that's nearly or entirely R5RS-compliant in maybe a few thousand lines of C, and from there build out the language to incorporate Python- or Rust-like features. "Toy" Schemes can even be useful in production, as an embedded scripting layer to a larger system.
The reason for Racket and its large library to embrace a large standard is the amount of things that Racket doesn't have to implement itself because it's in the standard already.
That's not how standards work. The standard just specifies something; you still have to implement it, unless the standard supplies a reference implementation which you can make work with your code. There's a reason why the quasi-standards for extensions to Scheme are called Scheme Requests for Implementation.
Neither R6RS nor any other RnRS standard contain a reference implementation, so whether it's in R6RS or not, the Racket developers have to implement it. RnRS standards do tend to have a description of Scheme's formal semantics, and SRFI documents, by convention, contain a reference implementation of the proposed API where possible.
Isn't chicken actually slower than Racket was before the switch? IMO its strong point is more seamless CFFI than performance. Chez also has a small C core and the rest in scheme, which I think was the main motive for the switch.
Why did Chez and Racket embrace R6RS, a standard widely rejected by the rest of the Scheme community?
Also, why did Racket choose Chez over some other high-performance Schemes, like Chicken?
Finally, how many Racket and Chez users are there compared to those of other Schemes?