I disagree slightly. R7RS-small is no more and no less a successful
consensus than R6RS. We have seen half of the community adopting R6RS as
a base and the other half mainly adopting R7RS-small.
What I mean is that R7RS-small is relatively easy to add to an R6RS
implementation. Sagittarius, Guile, Loko, and Ypsilon have already done
so, and we could expect the same from the remaining R6RS implementations
given enough pressure from their user communities.
We can't expect R6RS or R7RS-large to be supported due to pressure from
users, because those standards add so much new stuff. It's too much hard
work to expect from an implementer who isn't already committed. R6RS
wasn't added to Gambit, for example; there's an abandoned project to try
it out. Kawa is big and has parts of R6RS but isn't R6RS compliant.
Both are successful in that they describe programming languages that
have been implemented and can be used. They differ in some details, of
course. R7RS-small may be more attractive to a general implementer
because it's smaller and because it gives the implementation much more
freedom. For the actual Scheme programmer, R6RS should be more
attractive because it is more complete and gives safety guarantees.
I have come to the conclusion that it would have made at least as much
sense if not more to build R7RS-large on top of R6RS instead of
R7RS-small. With R7RS-large, the smallness argument of R7RS-small does
not matter anymore and R6RS is the better core language because it
provides a few things (like record inheritance, procedural macros, fast
hashtables, ...) that R7RS-small is lacking but which are very helpful
for R7RS-large. I guess we could eventually reshape R7RS-large into an
R6RS-large.
Many seasoned schemers dislike R6RS on aesthetic grounds to the extent
that building R7RS-large on top of it is likely to be politically
impossible. It would also be incredibly bad PR: it would look like the
Scheme community is directionless and has no ability to make decisions.
What could work, is a standard that has everything from both R6RS and
R7RS-small combined, so that a Scheme implementation supporting all
features of the new standard will run all existing code from R3RS
upward. That would also be a good look PR wise. "We admit that we made
some mistakes with RnRS incompatibility, but now we have cleaned them up
and the latest RnRS is again compatible with the earlier ones."
As best I can parse the situation as a newcomer, a lot of this is on the
Scheme Steering Committee. John has been fighting valiantly for backward
compatibility in R7RS but the Committee instructed him that
compatibility should be second priority. I think that's an astonishing
attitude, and it's not John's fault.
We can argue that R6RS was an irresponsible standard. But in the
aftermath of an irresponsible standard, the job of the next standard is
to suck it up and be the cleanup crew.
Based on what I've been able to parse, the Committee's idea of a cleanup
crew is a detonation crew. When the goal is to bring a community to an
agreement, we don't go about reaching that agreement by detonating half
of the community's buildings and rationalizing our actions by claiming
no-one really lived in those buildings anyway, and if some people did,
they're weirdos who are best ignored.
A few people left the group of R6RS editors in the process.
This had the negative consequences that half of the Scheme community
outright rejected R6RS. On the other hand, on the positive side, R6RS is
now a very coherent standard, which is has been well-thought-of from one
end to the other.
(The latter is also true for R7RS-small, which was easier to achieve
because of its smallness. It won't be true for R7RS-large unless there
will be some difficult consolidation process once we have arrived at the
ultraviolet end of the spectrum.)
Lack of coherence is unfortunate but empirically, compatibility is the
main determinant of a successful language standard. Python 2 vs 3 is a
good example of coherence winning over compatibility. It was a social,
technical, and PR disaster.
I don't think that R6RS and R7RS-small are very far from each other in
this regard. While implementing an R6RS needs more work than
implementing an R7RS-small, this difference is almost negligible for
implementations that want to be more than toy implementations.
Something like syntax-case is definitely not negligible, and the R6RS
portability guarantees (in the exacting sense of the word "portable")
probably are not either.
The proposal that seems best to me so far is to have all the R6RS stuff
as optional modules. Then implementers could pick whether or not to have
complex stuff like syntax-case. This is wonderful from a practical
standpoint: most R6RS code doesn't use syntax-case, so a lot more useful
code would work out of the box in a lot more implementations, even
without implementing all the options.
