[r6rs-discuss] meta r6rs

From: Thomas Lord <lord>
Date: Sun, 10 Jun 2007 08:10:52 -0700

Aubrey Jaffer wrote:
> | Meanwhile, none of that has any effect on whether or not the
> | treatment of uniform arrays is useful.
>
> The words "uniform" and "array" appear in neither the r5.93rs draft
> nor the r5.93rs-lib draft.
>
> I have beaten the drum for arrays since the r6rs process was proposed,
> including writing several SRFIs, but to no avail in r6rs.
>
>


Sorry for bringing up an old insult, then. I only meant the
bytevector stuff.

This does help to illustrate the problem with trying to publish
an R6 instead of a "Workshop Scheme" SRFI: the R6
process is largely about ways of saying "no" while SRFIs
are almost entirely about ways of saying "yes". Personal
animosities can arise in the comment period of a SRFI,
but in any R6 process, formal, professional insults
can (and must, by definition) occur.

There are lots of hard design choices. Unicode support
is one example -- Cowan and I disagree strongly about
which options are better in some areas. Really, neither
of us can prove our case at this time, not objectively.
Experimentation is really the only way to explore (a)
how important these design questions really are; (b) which
are the better ideas about how to handle them.

So, in the R6 world, Cowan's view on Unicode and my view
on Unicode are locked into a zero-sum game. It's winner take
all. It's "yes" to one design and, therefore, "no" to the
other, fighting essentially for full "citizenship" under the
flag "Scheme". There is no Right Way to pick a winner in
that case.

In the SRFI world, two designs for Unicode are playing a much
more realistic game against (sort of) one another: they compete
to be used; they compete for "design wins" -- when people use
the SRFI in an application. The SRFI game is not zero-sum.
Just the fact that there are two Unicode SRFIs, with differing
capabilities, can increase the total number of applications written.
Instead of "dividing the pie," SRFIs create at least the possibility
of just baking more pies. And above all, SRFIs answer the
question "which design is better" through experiment, not fiat.


The usual argument for keeping a "winner take all" standards
process in the middle of a language growth project is to prevent
excessive divergence. Sun would consider it a problem, for
example, if no two Java implementations recognized the same
bytecode format.

There is a role for that kind community policing in Scheme,
too, but let's be honest: Sun holds a trademark on names like
Java, and copyright on specifications and documentation -- they
are legal owners of certain intellectual property rights, protecting
their property. Here in the Scheme world, on the other hand,
we work by voluntarism and acclaim. A steering committee
emerges from informal discussions, and an editorial committee,
and the community is thrilled to talk with them and help them
prepare a report simply because our consensus is "Yes, that's
a great set of people for such work, at this time -- it will be
interesting to see what they come up with." So, when
Sun defines Java, they are literally amending various contracts
and licenses. When a bunch of good people from a certain
workshop offer up a definition of Scheme, all they are doing
(though its nothing to sneeze at) is signing their names to
a document they've agreed upon.

Our community has a formal process under which any group
can form, offer up a standards document for discussion, and
then if they so choose, finalize the document, signing their
names to it: SRFIs.

-t
Received on Sun Jun 10 2007 - 11:10:52 UTC