I think a very good thing about the R7RS-large effort is the large
number of SRFIs it has been and is producing because it is moving the
Scheme language forward.
The actual purpose of the R7RS-large effort, namely creating a ratified
language spec by declaring some of the SRFIs as "offical", is far less
important IMHO. Actually, I am no longer convinced that it is a good
goal for a number of reasons:
* Far too few people (especially implementers) are active in the process.
* Even fewer people review, test and implement proposed SRFIs.
* The voting process can too easily yield arbitrary results depending on
who votes.
* The SRFIs making up R7RS-large handle similar things often very
differently.
* We often have just one implementation of a SRFI. Implementers of the
very fast implementations like Chez don't give feedback whether
implementing them would compromised performance.
So when R7RS-large is finalized, we are simply giving a number of SRFIs
"official" status. The nice thing about it is that the can be accessed
through simple names like "(scheme list)". But, as John writes, this
also means that the underlying SRFI can only be replaced by an upward
compatible one.
R6RS has library versioning, which would have helped. We would finalize
"(scheme list (7))" but that wouldn't exclude a different "(scheme list
(8))". Of course, there's always the possibility that we get back a
(stripped-down) form of library versioning back in the R7RS world.
Please read again the first sentence. While this may not have been the
original goal of the R7RS-large process, it shows that it has already
been highly successful. We owe you a lot just for this, John.
I basically agree with everything Marc said, both the praise and the
plea for change, for the reasons he states. I also feel apologetic and
self-conscious about directing so much criticism at R7RS-large (even
though it's intended to be constructive and in good faith) since in
practice John has to shoulder so much of the responsibility personally.
R6RS was polarizing because it was a de jure standard that wasn't (and
still isn't) a de facto standard. It didn't achieve de facto status
because it added so much new stuff not backed by a consensus. The voting
record shows that even the working group was divided internally but
they forged ahead anyway.
R7RS-small is a successful consensus standard, and -large mainly adds
libraries on top of it, so -large is better positioned than R6RS in this
respect. There are few changes to the core language on top of the
consensus standard.
However, the same process artifacts are showing as with R6RS: there is
not broad consensus within the Scheme community about which R7RS-large
libraries to adopt, and no working group internal consensus either. (WG2
members who disagree with the general direction tend to become passive
or leave. In R6RS I assume most of them stayed but were outvoted.)
I believe this outcome is not peculiar to R6RS or to R7RS-large, but is
inherent in making any de jure standard that doesn't start from a de
facto consensus. It's not about individual decisions made; it's
inevitable due to the scope of the standard, which has been extended to
cover areas of the language about which there isn't a consensus.
IMO a standard has the moral duty to establish long-term agreement among
implementers. The larger the scope of the standard, and the more novel
stuff there is, the more difficult it is to uphold that duty. Something
like R7RS-small is: people may grumble about the precise syntax or
semantics of define-record-type or define-library, but implementers
agree that the language should have records and libraries in something
like their current form.
There isn't similar agreement about what data structures and libraries
the language should have (beyond lists, vectors, bytevectors, strings,
and hash tables).
Not only is near-term agreement important, but long-term agreement
across the decades. This means that when writing a standard, succession
should be planned in from the start. We should make it easy for writers
of future Scheme reports to keep in agreement with the de facto
consensus among future implementers. Since we lack the requisite
foresight, the best bet is to be conservative and standardize things
that are already widely implemented. This principle has guided the
internet RFC process; https://tools.ietf.org/html/rfc2026 ("The Internet
Standards Process") is quite clear about it.
This does not in any way mean that the massive amount of work done on
the data structures and other libraries in R7RS-large is ill-advised or
wasteful. I simply don't believe that RnRS (and to a lesser extent SRFI)
are right vehicles for carrying it and formalizing it. There are many
indicators of this: the inability to establish a schedule and stick to
deadlines; the unclear scope; disagreement among WG members on both the
content of the standard and the process used to make it. All of these
are indicators of exploratory rather than scholarly work.
It's important to emphasize that there is nothing inherently wrong with
disagreeing, taking a long time, and working in fits and spurts, but I
think a standard should be more like a scholarly work that goes smoothly
on a set schedule like a train. Predictability and lack of surprises are
good ways to establish agreement; the design work involved in RnRS
should focus on tweaking things that are already widely implemented.
That's why I suggest that we keep all the high quality work that has
gone into R7RS-large, and continue expanding it, but find another
process to host it, a process that is built from the start to be an
ideal vehicle for exploration rather than scholarship and refinement.
If such a process enjoyed a similar de facto standard status as RnRS and
SRFI, the libraries being made by that process would have the kind of
high visibility and status that would help them be widely adopted over
time. The key would be to build a default place for exploratory work in
Scheme, and to invest schemers with ownership of that place so that it
is well kept. SRFI and RnRS both involve de facto ownership of specs,
and hence the specs are very well kept, but if we use these processes as
intended the barrier to entry is prohibitive for exploratory work.
