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.
