> Languages like C++ (but even C) are larger than R7RS-small and also
> larger than R6RS, so I don't think that such a limiting factor has been
> reached yet.
>
> Personally, I don't like C++ that much because of the historical baggage
> it carries with it, but it is apparently still manageable.

Different language communities seem to have very different limits.
Common Lisp is also a big standard, but the implementers are in
agreement that it's a good basis for their work

> Polling implementers make sure that you get things implemented quickly
> but this would neglect the current and future user basis.

Good point.

> In any case, if you want to get R6RS on-board, you won't have an option
> but have to choose syntax-case over ER. Fortunately, this is also
> technically the much better solution.

I agree that starting from R6RS would bring an obligation to offer
syntax-case as an option, but no obligation to offer ER and the others.

>      > Compared with R7RS-small "locked", R6RS didn't "lock" many more
>     things. [...]
>
> On purpose, I wrote "compared with [what] R7RS-small locked" (but forgot
> one word). In terms of the library system, R6RS and R7RS are equal.

That's seems like quite a few more things than R7RS-small, but maybe I
don't have a good handle on the problem.

>     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.
>
> And are not fully compliant yet (at least weren't 5 years after the
> standard was done).> But it misses the point, doesn't it? One could also
> say that a Scheme standard not taken up by Chez is not a credible Scheme
> standard.

Very good points both!

In the case of R6RS -> R7RS-small, RnRS went from bigger to smaller
language, which may have affected the uptake among R6RS implementations.

> And if the only way to get a "credible" standard is by reducing it to
> almost R5RS, what's the point.

There is no point since we already have R5RS. What we could hope to
standardize is R5RS + libraries and exceptions + options for the rest.
And a less rigorous design process for stuff that isn't core.

> For Kawa, things seem to be a bit more complicated because it has to
> cope with the JVM and has to be interoperable with Java programs.

I got the impression Kawa's decision on R7RS-large was more about having
lots of data structures with monomorphic procedures for each of them,
instead of polymorphic. (John makes a good argument about the difficulty
of standardizing polymorhpism.)

> define-library vs library was a deliberate decision by the R7RS editors.
>
> They have taken R5RS as the baseline instead of scaling R6RS back. The
> latter would have led to a similar system like R7RS-small but would have
> introduced fewer incompatibilities.

Yes, arguably rolling the clock back beyond the previous RnRS is already
a bit too much of a visionary move :)

IMHO ideally RnRS would just standardize what implementers agree on. If
they agree on little, it would standardize little. If they agree on a
lot, it would standardize a lot. It should reflect the practice in the
field, whatever that is.

>     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.
>
> Isn't it again similar to C vs C++?

It is. C and C++ are each diluted by the other's existence. They are
just so extremely popular that it's hard to see the dilution. C++
compilers almost universally support compiling C code as well. Arguably
this is similar to the way R6RS compilers are now picking up R7RS-small.
But it would still be nice if C was a proper subset of C++, and
RnRS-small a proper subset of RnRS-large, obviating the need for
different compiler flags and such.

> I'm not completely convinced. If you look at R6RS, it is a standard
> respected by Chez, Racket, Loko, etc. meaning that I can be sure about
> the portability of my programs (modulo implementation bugs). So R6RS
> still has a lot of consequences even if not for all Scheme implementations.

It does, but if the same standard was supported all the other
implementations life would be even better. It's hard to think about
problems like this because we don't readily see what we're missing.
Perhaps it's easier to visualize in the other direction: take the set of
implementations that now support R6RS or R7RS, and split the set in half.

> As I wrote in some other thread, I am working on my own compiler (which
> I can then use at a testbed, etc.). For a change, I'm writing the
> compiler in R6RS. Compared with writing it in R7RS-small, life is easier
> for me as a developer, which means as a user of Scheme.

I believe that. I like both R6RS and R7RS, don't have a favorite, just
wish we could put the split behind us.