3 ms·
I think this is a really fair summary of the technical differences between the two standards written from the perspective of a person who favors R6RS. I especi
by jgon 7y ago
I think this is a really fair summary of the technical differences between the two standards written from the perspective of a person who favors R6RS. I especially agree with the point regarding error signalling and the lack of effective facilities for that in R7RS.
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.