
R7RS versus R6RS (2018) - fanf2
https://weinholt.se/articles/r7rs-vs-r6rs/
======
jhoechtl
I seldom saw such an incredibly weak argumentation as in section "The number
argument". Yes, If someone wants Scheme to remain an academic toy language,
this might make sense.

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!

~~~
eadmund
It really all depends on what one wants. If one wants an excellent academic
exercise, Scheme is pretty great. If one wants an excellent industrial
language, Common Lisp is right there.

I am sympathetic to R6RS because it tries to make Scheme more useful for real
programming — but in that case why not just use Common Lisp, which is even
_more_ useful for that purpose?

~~~
codeflo
I’m not convinced CL is more useful for real world usage. People sometimes
fall into the trap of thinking that more features are always better. With
programming languages, that’s rarely true, because even features you don’t use
cost you something — in terms of training new programmers, and every time your
dealing with other people’s code. (And note here that in real-world projects,
most of the code you have to modify and debug isn’t yours!)

Of course it’s possible to go too far the other way, and R5RS leaves too many
questions unanswered. But in my opinion, simplicity is also an important
feature, not just academically, but in practice.

~~~
lispm
Since one doesn't program in R5RS (a language definition document), but with
real implementations, those tend to add quite a bit to Scheme to make
practical programming possible.

Example:

[https://www.gnu.org/software/mit-scheme/documentation/mit-
sc...](https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-
ref/index.html)

~~~
codeflo
Sure, but the point of a standard is usually to make implementations
interchangeable.

------
atsmyles
With all due respect to the author, I followed the r7rs standardization
closely, and disagree with his bottom lines.

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...](http://www.r6rs.org/final/html/r6rs/r6rs-
Z-H-10.html#node_sec_7.2) . 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.

------
haolez
I thought that the whole point of Scheme is for it to be easy to implement.
R7RS seems more aligned with Scheme's vision.

~~~
bitwize
Ease of implementation leads to a maze of twisty little implementations, all
different. It also leads to unaccounted-for corner cases (see: why C is
deprecated). The major implementations, Guile and Racket, both embraced R6RS.

~~~
buzzkillington
Guile has not embraced R6RS:

> R6RS significantly expands the core Scheme language, and standardisesmany
> non-core functions that implementations—including Guile—have previously done
> indifferent ways. Guile has been updated to incorporate some of the features
> of R6RS, and toadjust some existing features to conform to the R6RS
> specification, but it is by no meansa complete R6RS implementation.
> SeeSection 7.6

[https://www.gnu.org/software/guile/manual/guile.pdf](https://www.gnu.org/software/guile/manual/guile.pdf)

Neither has Racket, they aren't even calling themselves a scheme any more.

~~~
akkartik
Are there _any_ complete implementations of R6RS?

~~~
widdershins
I think Chez is pretty much compliant.

------
apocalypstyx
Stands off to the side waving R4RS flag.

~~~
nils-m-holm
You are not alone! S9fES is still R4RS. :)
[https://www.t3x.org/s9fes/index.html](https://www.t3x.org/s9fes/index.html)

------
jgon
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.

------
jimbob45
I was struggling to find a concise summary of the debate between R7RS vs R6RS
earlier this year. This article was the best I found to that end.

~~~
slim
last year

