>     The unfortunate thing about standards is that what wins is whatever
>     succeeds at establishing agreement.
>
> This isn't a good yardstick. Or R5RS would be the best of all.

On the contrary, R5RS is an excellent illustration of the principle --
it still is the most successful Scheme standard of all, even more so
than R7RS-small. Even non-schemers revere R5RS.

I suspect that R7RS-small is near the upper limit of how complex a
successful Scheme standard can be without relying on optional features.

> Uniting R7RS-small with R6RS isn't too hard because it would be
> basically R6RS+epsilon. The harder part would be to convince the
> R7RS-small people that adding the R6RS stuff is good.

Exactly!

If the R6RS parts are optional, then implementations like Chibi and
TinyScheme could still aim at conformance while keeping out the most
complex stuff.

Even simple compatibility such as supporting the same read syntax for
symbols and vectors, and supporting both (library ...) and
(define-library ...), would be a big help in practice. Every extra bit
of compatibility helps. Having a unified R6RS+R7RS standard would
encourage even the small implementations that leave out the complex
features, to eventually support the R6RS and R7RS variants of those
features that they do implement. This would add up to a lot more
real-world code being portable. It would obviate the need to mess with
command line flags like `-r 6` and `-r 7`, #!r6rs directives, .sld vs
.sls extensions, etc.

And perhaps equally importantly, uniting all schemers under the standard
with the same name would have a positive psychological impact and stop
our repeated exegeses about Scheme history that we cannot change :)

>     We come back to the unfortunate fact that successful standards
>     establish
>     agreement. R6RS is a successful language but an unsuccessful standard.
>
> Chez, Racket, and Guile are among the most successful Scheme
> implementations. And they are all based on the R6RS (or have moved
> there). In the case of Racket and Guile (and to a smaller extent also
> Chez), they have moved much further, of course, but implement R6RS
> nonetheless.

You have a point. R6RS has successfully standardized the core features
across important implementations.

>     It's possible to design a good language that is also a good standard
>     (i.e. reflects the consensus of the community). Scheme being in the
>     state that it is, the only way to do that is factoring it heavily into
>     optional features.
>
> That could be an approach for R8RS (= R6RS + R7RS-small) if "optional"
> is not restricted to libraries.

Agreed.

In particular, macro systems would be profitable to standardize in RnRS.
You have done excellent work cataloging them with your SRFIs. There's no
reason RnRS couldn't have something like explicit-renaming as an option,
considering that ER is already widely implemented in practice.

Macro systems are not as tractable to add as libraries outside RnRS.
It's all this compatibility glue that RnRS reports are uniquely well
positioned to deal with. We can write third-party compatibility shims of
all kinds, but the experience is never as nice as having all that good
stuff built in.

>     R6RS is compatible with R5RS, but R6RS set future RnRS reports up to
>     fail. A standard should never do that. The R6RS continuity plan for
>     R7RS+ was "our way or the highway". What if it turns out the wider
>     commmunity doesn't want all those features? Too bad for them.
>
> Why wouldn't be future reports based on R6RS possible?

They are very much possible, but what I mean is that R6RS locked future
reports into a particular direction that wasn't based on a consensus.

My opinion is that compatibility is the most important job of a
standard; it directly follows that future reports can add stuff to the
last report but not remove stuff. (They can make some previously
optional stuff required, or required stuff optional, eventually phasing
out optional stuff that nobody has used in a while. But it's not
acceptable to remove stuff from the previous report. That's what caused
the really big problems with Python 3; some code simply couldn't be
written in a way that works in both 2 and 3, making the transition
period painful for library authors.)

 From this point of view, R6RS added lots of stuff that R7RS has a moral
obligation to support. R7RS didn't accept this obligation (reflecting
the lack of consensus among implementers). The combined actions of R6RS
and R7RS caused us to end up with this debate.

I'd argue that R6RS did the greater wrong because it added controversial
stuff. They should first have written the implementations, and if
consensus emerges, then the standard. Or written a standard by some
other name than RnRS, RnRS being the flag bearer of Scheme.

But since R6RS already did its deed and it was finalized, the moral duty
(perhaps an unsavory one, but duty nonetheless) to maintain
compatibility has now been passed to R7RS.

If R7RS further adds new controversial stuff, it does the same thing
R6RS did, and if finalized, passes the moral duty onto R8RS to keep all
that controversial stuff.

At present, Scheme is in a cycle where RnRS designers are wed to their
personal vision and pass that vision onto the current implementers and
the next RnRS designers. Implementers grumble, designers resent prior
designers, the prior designers resent the next designers, and the
community is ambivalent, apathetic, or disillusioned.

These psychological reactions and attitudes are not unexpected. They are
a predictable consequence of a process where the RnRS stewards are
visionaries rather than scholars. A good scholar is diligent (which John
is, to a truly incredible extent), and tries to translate the source
material faithfully, adding as few of his own interpretations as he can.

> I doubt that all the R7RS-large libraries will have to go into the next
> formal RnRS report. For that, the libraries are too diverse and
> inconsistent. At least a thorough clean-up effort would be needed.

There are easily predictable psychological consequences to the entire
community if each RnRS drops half the stuff from the prior RnRS. The
process shouldn't be a Sisyphean task where each RnRS group rolls a
boulder uphill, the next group rolls it halfway back down, and then up
again.

And adding new people to the community is hard if no-one can figure out
which of the warring RnRS, if any, is legitimate.

> Besides psyntax, there is André van Tonder's implementation (shipped
> with Larceny). Then there is my own implementation in the form of
> Unsyntax. And there is the implementation I wrote for Chibi Scheme. Jim
> Rees has his own implementation, etc.
>
> The source code of the Chez Scheme compiler is very readable. It also
> includes a syntax-case implementation, of course. Maybe you want to take
> a look at that. Kent Dybvig's and his student's papers on syntax-case
> and the library system are very well-written.

Great, the situation is much better than I suspected. Congratulations
for implementing it on your own; not an easy job!