>     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.
>
> Okay... it's a good yardstick if you are interested in the absolute core
> of a language, but the idea of R6RS and R7RS-large is to write practical
> applications as well.

True. I may sound pedantic by using R5RS as an example, but I'm trying
to make a serious point: that de facto standards are the real standards,
and by extension, anything we _can_ get agreement on is a standard in
practice, and anything we can't get agreement on is not. The content or
scope of the things being standardized doesn't matter in this respect.

Technically, there's no upper limit to what it makes sense to
standardize. It's human factors that make the ceiling. We could
standardize everything up to Strong AI if we were smart enough to figure
out how. As it stands, it seems human factors put the limit at about
R7RS-small without options.

> On the other hand, things whose use we don't want to encourage shouldn't
> be added to a report. For new code, there are absolutely zero reasons to
> use ER if syntax-case is also available. So having both in the same
> report doesn't make a lot of sense. And making both optional parts would
> lead to a lot of unportable libraries.

Good point. It would be prudent to poll implementers about this.

> Compared with R7RS-small "locked", R6RS didn't "lock" many more things.
> From memory: mostly hash tables (but they would be needed anyway),
> syntax-case (a feature in existence and well-understood since R4RS, or
> so), conditions (much needed for real-world code), and enumerations
> (being added in an extended way to R7RS-large anyway).
> In hindsight, it would have been much better if R7RS had proceeded from
> R6RS. R7RS-small could have been R6RS with some parts optional and
> R7RS-large could have been R6RS with extra bells and whistles.

Also the library system (this seems unequivocally a good thing: a
language without a standard way to write libraries has no way to share
reusable code).

>     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.
>
> There had been implementations of the stuff.

Sure, the implementations co-evolved with the standard. But only some
implementations. A Scheme standard not taken up by MIT Scheme and Gambit
is not a credible Scheme standard. Both of them accepted R7RS-small.

Kawa, one of the long-running large Scheme implementations, is not
taking up R7RS-large despite substantial effort from its author to come
to terms with the new standard.

> If R7RS-large is the baseline for R8RS, there won't be an R8RS I
> suppose. It's not a good comparison, but it's like making C++ the
> baseline of the next C standard.

This gets at the heart of the matter: there needs to be a steady
succession of future RnRS reports (probably about one per decade)
because RnRS is the only place where compatibility can be established
without shims and other hacks.

Treating the reports as visionary projects, apart from making it hard to
get community-wide agreement on them, gets in the way of this mundane
but essential work with the compatibility glue. A trivial example is
that (library ...) and (define-library ...) are incompatible which puts
us in a Python 2-vs-3 like situation where it's not possible to write a
portable library file. The resolution of this everyday problems is held
up indefinitely since R7RS-large is not shipping on any particular
schedule, and it can't ship on a schedule because visionary work is not
predictable.

Scheme needs a design process that runs at intervals on a predictable
schedule and fixes these little inconveniences. Only RnRS is suited to
be that process.

The C and C++ comparison is interesting. C++ is almost a superset of C,
but not quite; there are trivial incompatibilities that nevertheless
make it hard to write a C program that compiles without warnings as a
C++ program. It's like R7RS-small and R6RS.

I believe there isn't enough agreement in the Scheme community to
standardize anything with the scope of R6RS or R7RS-large (with all
options implemented) with the rigor expected from the RnRS process.

Our realistic options are to do something on the R6RS scale, but
factored into optional features; and to do something on the scale of
R7RS-large (and beyond!), but using a much less rigorous process.

No existing technical work need be wasted! If we refactor the social
processes, we can continue building on the existing technical work
without a hitch.

> Standards do no fight wars. :) Nor do the people of the different
> communities. They just use different languages to some extent.
>
> All that one can say is that R6RS is currently as legitimate as is R7RS
> as is R5RS. And that if you want to learn Scheme as a newcomer you may
> want to take look at Racket, which is a huge superset of most "official"
> standards.

If there are multiple legitimate standards, it dilutes the legitimacy of
them all, and ultimately the legitimacy of the standards process. An
outsider would be excused for concluding that Scheme has no legitimate
standard.

I feel our formal standards process is obscuring the state of de facto
standardization. Ultimately, the point of a de jure standard is to have
a de facto standard. That's the only thing that makes it legitimate long
term. A de jure standard can exert its formal authority to go beyond de
facto, but there are consequences. The greatest error is to be so
convinced of our de jure authority that we lose touch with the de facto
situation. The reign of any such standard won't last long.