R7RS versus R6RS (2018)

I followed the discussion and schisma which resulted in Racket for good. If you want to have a sane language, some pages of specification and rationalization are required, as has been done for R6RS.

If the professors fear that students will no longer be able to implement their Scheme interpreter in a term because the spec has become to complicated please call the language somehow different and stop to encumber the development of an otherwise great language!

1. On the number argument: Even the author acknoweldges that R6RS is twice as large. Regardless of the fact that the standard library is the other half, the fact is that the standard library is a requirement for R6RS. Because of the controversies about it (the condition system, record system, hash table library), the R7RS standard was purposely split into 2 parts, the R7RS-small and the R7RS-large. The R7RS-large standardization is an ongoing project.

2. On the condition system: The fact is that horse already left the barn. Most major implementations already had their own condition hierarchies. The only way to reconcile their existing conditions would be to have a translation layer which would be inefficent. Conforming to R6RS condition system would mean throwing out most of the code that people who use those implementations depend on. R7RS focused on providing a basic error system with a purely procedural interface, which combined with cond-expand and the library system, can allow people to write portable code. So the idea that the standard committee doesn't believe "Safety is not a desirable language feature" is unwarrented.

3. On Optional is better argument: Sure you can have an R6RS with restrictions, but then it isn't R6RS, it is a R6RS-like scheme. Using feature identifiers is at least a better way to create portable code. If you have a library that requires unicode, you can specify that in the code.

4. On syntax-case, one of the costs of having it is a more complicated library system, with import and export levels. Read it yourself, http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_se... . R7RS-small decided to be more conservative in this area.

Overall, I think that the way that R7RS standardization has worked to evolve the standard was the right approach. They focused on the most important needs for scheme ( The library system, a basic record system, basic error handling) while avoiding adding features that were overly controversial.

I should also say that my perspective is that of an outsider, a user, not someone who is involved in implementing scheme, or in the standards process. With that said, I feel like this post does not capture the social context of R7RS vs R6RS and without that you can't really understand the overall picture.

Scheme has been around for decades and there are probably dozens of implementations. Almost every one of them supported R5RS. Unfortunately this standard didn't specify enough to allow for easy interoperability of scheme programs between implementations, depending on what you were trying to do. So everyone ended up just picking their own scheme and running with it.

R6RS tried to offer enough of a standard to allow for interoperability between implementations, particularly in offering a module/library syntax, and a bunch of the other things listed in the post. The main problem, and really the one that triggered R7RS, was that it was a large enough standard and required enough work that not many implementations updated to conform to it. The standard was ratified in 2007 and when I was looking around for conformant implementations I didn't find a lot. There was Ypsilon scheme, which has since become abandonware. Ikarus scheme by Abulaziz Ghoulum was super fast but was also abandoned. Larceny scheme was compliant I believe but I didn't use it much. Kawa scheme worked to get there but was still not conformant by 2012. Guile never fully implemented it. PLT Scheme implemented it, but 2 years after was already making announcements about leaving Scheme behind and became Racket in 2010. MIT Scheme of SICP fame basically said they'd never implement it. The crown jewel was probably Chez Scheme, still to this day one of the best language implementations period. But it was proprietary in 2007 and cost money. You could use the interpreter based implementation Petite Chez Scheme, but it still had other restrictions I believe. Committing to R6RS as the standard going forward meant abandoning most of the existent implementations, and thus most of the body of code people had written for them. In trying to unify the Scheme world going forward, R6RS was potentially asking for a large schism. Please note that the previous sentence isn't a value judgement. Maybe Scheme would be in a better place given the technical merits of R6RS. I can't deny that. But that is how the world looked (in my view) when R6RS was the scheme standard of the day.

In comparison after R7RS was ratified, many implementations worked to be conformant. Guile is close, Kawa is conformant, Gauche Scheme implements R7RS, Ypsilon is another, Chibi Scheme, Larceny, etc, etc. In terms of standards adoption there's no contest.

Writing this post from 2020, where Chez Scheme is open sourced and free, Akku scheme is a great implementation of R6RS, and we are starting to get package repos for Scheme, maybe R6RS would have been the better choice. Maybe all those other implementations should have fallen by the wayside and we'd all use Chez Scheme, much like CPython is the canonical Python (except Chez Scheme is incredibly well implemented). But at the time the decision was made to make a new standard, a very explicit decision was made to abandon the "easy for users, hard for implementers" motto of R6RS, because what is a language standard without implementations?

My hope is that ongoing work can build on R7RS and get us to the level of excellence and ability to build things that R6RS gave, and maybe we can end up having our cake and eating it to.