John Cowan wrote:
> If you think that this draft should not become R6RS, then register
> to vote and vote no, publicly giving your reasons. Don't attempt to
> end-run the process in this particularly unsubtle fashion.
I am offended by that characterization.
I am not trying to "end-run the process". I am not trying to be
sneaky, which your charge of "unsubtle" seems to imply.
I am trying to suggest a graceful way to abort the process and
I'm offering some reasons why that it is a good idea to do so.
R6 has two properties that, taken together, mess up the function
of a community. In a community, we hope that people are,
as Steele puts it, "working side by side rather than head to head".
Yet, R6 dooms the Scheme community to work head to head:
R6 matters, economically, because implementations are often
judged to be more or less valuable depending on their RnRS
conformance. There are other economic reasons it matters, too.
For example, the value of listing "Scheme" on your resume
is, in part, a function of the quality of RnRS. So, there is economic
rivalry over the contents of R6.
Yet, control over the content of R6 is wholly owned (de facto)
by past editors and their "heirs". So, even though there is
economic rivalry over the contents of the document, the contents
are, at the end of the day, decided by the fiat of a small group.
Therefore, R6 forces the community to go head to head: lots
of us have incentive to "spend" to influence the evolution
of the language, but because the contents of R6 are rival,
we can only spend to influence a particular group of editors
and steering committee members. Those small groups
have a monopoly on R6 content. Demand for piece of that
content exceeds supply. So the community is forced to fight
over that: to try to make others lose. We are going head to head
over R6 when, if we're to be a Scheme community, we should
be working side by side.
It is particularly tragic, for the Scheme community, to have
such fights over R6. For example, Cowan and Lord (you
and I) have disagreed about the desirable structure of the
CHAR and STRING types. How much better if that debate,
instead of having the form of a fight over R6, had the form
of alternative SRFIs -- so that we wound up with positive
accounts of both positions rather than just one, and so that
implementors and programmers could make individual
choices about which to adopt.
Publication as a SRFI, not as R6, would restore the community's
ability to work side by side. SRFI's are non-rival. If
some in the community doesn't like the way a particular SRFI
is going, they are free to create an alternative SRFI. Neither
SRFI is more legitimate than the other, but probably one will
eventually emerge as more popular than the other. Contrast
that with R6RS: if a splinter group decided to publish their
own, alternative R6RS, immediately the question would arise
"which R6RS is legitimately titled? which is the authority?"
The splinter group would most likely be disregarded on that
basis alone.
-t
Received on Fri Jun 08 2007 - 02:40:21 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC