The smaller something is, the easier it is to add. But that's all.
It's not too much hard work. But it won't be done unless an implementor
is willing, of course.
The unfortunate thing about standards is that what wins is whatever
succeeds at establishing agreement.
Many seasoned schemers dislike R6RS on aesthetic grounds to the extent
I don't get why it could be disliked on aesthetic grounds.
Probably just the scope of it, or the politics; I'm not experienced
enough to know what the precise cause is, but it still ruffles feathers.
The Scheme community is split; there's no point in trying to cover it.
It has been split for one third of its lifespan: about 15 years (give or
take) out of 45. That's a lot, but the standard has been united twice as
long as it's been split. We can unite it again.
If R8RS unites R6RS and R7RS, the split will cease to have practical
consequences and people will soon forget it.
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 be great.
It makes me very optimistic that you would support such a move!
R6RS is compatible with R5RS (to the extent it makes sense). It's hardly
irresponsible. Half of the community may see it as a bad standard but
that doesn't necessarily make it true.
We come back to the unfortunate fact that successful standards establish
agreement. R6RS is a successful language but an unsuccessful standard.
I'm concerned that R7RS-large will meet the same fate.
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.
Having options would be formalizing what Scheme implementations already
do in practice anyway. No implementation supports all of R7RS, and John
has mentioned that many or most of the R7RS-large libraries could be
options. Scheme is also extremely well suited for subsetting; it would
be nice if RnRS gave a nod to this.
I think the Python cleanup was good. But R6RS vs R5RS is not like Python
3 vs Python 2.
It would have been a good cleanup for a non-standard language. But the
Python devs found out the hard way that Python 2 is a de facto standard
that is not easily dethroned.
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.
R7RS-large is done with the same mentality, but more measured. It's nice
that the libraries are optional, but the next RnRS report has a moral
obligation to carry all of the libraries that now go into it (they can
be options, but they must still be there).
No report should pass on a moral obligation for the next report to carry
stuff that hasn't been proven and widely used in the field.
Experimentation should be done via experimental design processes.
The harder part of syntax-case is the pattern matcher and hygiene. But
this is already what an R7RS-small (even an R5RS system) must ship anyway!
I lack the expertise for this, but someone said psyntax (in its various
forks) is basically the only extant syntax-case implementation, and only
a small handful of people understand it.
