[r6rs-discuss] Last minute questions
Michael Sperber wrote:
>
>
> While the SRFIs are a valuable vehicle for discussing proposals, and
> many are widely adopted by implementations, they do not have a
> coherent organizing principle; for some subjects, several competing
> SRFIs exist. Thus, the SRFIs in some cases serve as an incubator for
> future standards but are no substitute for a coherent
> language design and set of standard libraries.
>
I object to that description. It relies on a "type error".
To say that "SRFIs are no substitute for coherent language
design and a set of standard libraries" is analogous to saying
that blogs are no substitute for a tutorial about delimited
continuations. It is like saying that a piece of parchment
is no substitute for a Constitution. The proper response
to such a claim is something like, "huh?"
SRFIs are nothing more or less than:
a) an open-participation, moderated, blog-like
communications forum. It is blog like in that the
main content comprises single-author "top posts"
and open "threaded comments".
b) a cataloging system for top-posts within that
forum. Every SRFI has a number, a title,
authors, a date, a status, etc.
c) a self-nominated authority, comprised of well
known persons in the Scheme community, who
referee the moderation process and contribute
the IT infrastructure. This group operates with
considerable transparency, has evoked no controversy
with their efforts, and could be trivially dumped by
the "mob" if serious controversy ever arose.
So, SRFIs are just a forum for Schemers to post formal documents
about implementable features of Scheme. Much like the R6
process, SRFI moderation allows for a discussion period during
which multiple drafts may be unveiled and threaded discussion
can take place. Voting is a nice R6 innovation and would make
a nice addition to the SRFI IT infrastructure and moderation
process.
There is no promise (or at least should be none) that SRFIs are
"coherent" -- a discussion forum *should* contain contradictory
ideas. Otherwise, what is there to discuss, really?
A set of SRFI authors is perfectly free to build a coherent
*subset* of SRFIs. What is currently the R6 draft *could*
have been a series of SRFIs, later ones referring to earlier
ones, until something like the R6 draft emerges as the "top"
of that lattice of a subset of all SRFIs.
In contrast, doing R6 the way it is being done brings an
unusual "ceremonial" aspect to this particular formal document --
it gets to bear the much-revered title. And, it also raises
an economic question that, perhaps, we would be better off
not having to answer: the use of the R_RS title sends an unusually
strong signal to markets -- much stronger than a SRFI sends
*unless that SRFI happens to become widely adopted*.
That strong market signal is troubling because while the potential
that there would someday be *something* called "R6", what
we have hear is an assertion that this particular document be called
"R6" basically on the authority of a self-nominated committee.
Now, the voting procedure dilutes the committee's power a
little bit, sure, but... The process amounted to the drafting of
a monolithic and quite radical candidate in near private.
Thus, the committee has to conduct the vote but, through
their proxies, the editors, they determine the ballot. It's
all very "Soviet," in its way.
Why do I intend to vote yes? Another way to say it is that:
1) The economic play of dubbing this document R6 may have
been made by means that are somehow illegitimate, but (a)
I detect little or no malice; (b) the particular economic play
chosen (this draft) -- even if it is not quite a gem -- will
(my guess) give the community as a whole an economic
boost, without *too* badly foreclosing future opportunities to
change things.
2) I believe that using the SRFI forum wisely will, in the end,
win out over less democratic forums such as the R6 process.
Perhaps R7, by whatever process it might arise, will amount
to the single line "We include SRFI-##### by reference."
(The graph of SRFI's thus referred to can be attached as
appendices.)
-t
Received on Fri Aug 03 2007 - 13:46:52 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC