Alex Shinn <alexshinn@gmail.com> writes:

> The result was a factioning of the community.  Many people not
> directly involved took it upon themselves to write the
> self-introduction necessary to register for the electorate, to
> write the required rationale for a "no" vote, and to vote
> against ratification - enough so that the R6RS was barely able
> to achieve the 65% majority needed for ratification.  Even after
> it passed there was lackluster uptake, and many implementors
> outright refused to support it.

I wonder if this approach should be revisited in light of the scope and
tone of disagreements which seem to be coming out of the R7RS process.

In particular, while past Scheme standardization processes have tended,
as you note, to come out of a feeling that ``Scheme has moved on, let's
updated the standard to match'', the R7RS process seems to be explicitly
defined in opposition to perceived faults in the R6RS.  I worry -- based
on my limited exposure to the process so far -- that the result of this,
as with any coalition defined by what its against rather than what it is
for, is a lack of direction and fractiousness that makes real progress
in language design hard.

The committee knows what it doesn't want to produce (``if you want R6RS,
you know where to find it''), but it is not clear that enough time has
passed since R6RS for the committee to know what it _does_ want to
produce -- what a good `non-R6RS' should look like.  This threatens to
show itself as a throwing out of the baby with the bathwater -- a
rejection of features _because they were in R6RS_ due to a lack of a
clear idea of just what it is about R6RS that is so bad.

More generally, let's look at the timeline:

   R3RS -- 1986
   R4RS -- 1991
   R5RS -- 1998
   R6RS -- 2007

At the point where the R7RS began with a declaration that R6RS had
``lackluster support'', how many years had passed since R6RS's release?
Two?  How many schemes had still not finished R5RS support in 2000?
R4RS support in '93?  Given that two major Scheme implementations (PLT
(now Racket) and Chez) supported R6RS almost immediately, isn't the
declaration that ``many implementors outright refused to support it.''
(not counting implementors who held off _precisely because R7RS had
declared it was going in a different direction_) premature?

This doesn't mean R6RS is the way scheme should go, or R7RS as it exists
now isn't -- but I wonder if a lot of the disagreements we're seeing
here don't stem from the fact that there is a lot less agreement about
what R7RS should be than at the start of past standardization efforts?

(And so it's clear, I don't have a dog in this fight -- I'm not an
implementor, just a user who finds R6RS, as implemented in Chez and
Racket, more pleasant to use than R5RS or R4RS, and worries that many of
the features that made it so are in danger of being thrown out with the
bathwater.)

--
				Jim Wise
				jwise@draga.com

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports