[r6rs-discuss] One vote

From: Chris Hanson <cph>
Date: Mon, 13 Aug 2007 14:00:19 -0400

Lynn Winebarger wrote:
> So, the official results won't be announced until August 26.
> I voted no; my explanation is below. Reading the statements of the
> electorate was interesting. I was surprised by how many people
> believe popularity is the measure of success in a programming language and that
> the passage of time is in itself sufficient reason to vote for ratification.
> I know Will has posted his explanation. Are there any others?

Thanks for your post, which I am very much in agreement with. Here is
the explanation accompanying my vote:

----------------------------------------------------------------------
There are several reasons why I am unable to vote in favor of this set
of documents. First, I am deeply disturbed by the size and scope of
the proposed changes to R5RS. While many of these changes are
sensible, there are very many changes, and rather than getting to vote
on each change separately, we're forced into voting on all of them at
once. This is very like the way national deliberative bodies work,
and is even more distasteful in this context. A more incremental
process would foster more thoughtful development, allow users and
implementers to digest and understand the strengths and weaknesses of
each feature before moving on to the next. (I certainly don't have
time to fully understand all that is being proposed here.)

One interpretation of this process is that it's driven by fear: the
fear that the current set of authors have only a limited extent of
control over the standards process, and are trying to make the most of
it while they can. I don't think that's exactly what's happening
here, but I do think there's a certain amount of distrust in the
future, based more than likely on the dismal experiences of the past.
Nonetheless I think we should start from the assumption that small
successes now will lead to more small successes in the future, and
that over time those successes will accumulate to make something
great. We have to trust our ability to work together, and we have to
trust that spreading control of the standards process more broadly
through the community is best in the long run.

So, what I'm advocating here is something more like the "bazaar"
software development model: release early, release often, and be open
to participation by the community.

The second problem I have is the fairly low priority given to
backwards compatibility. This is made all the more important by scope
of the documents. I understand that the standard answer to this is
that implementations are expected to provide mechanisms for switching
between modes -- but this doesn't really address what to do with
existing bodies of code. It also makes it more difficult to update
existing code to the new language, since there's no incremental update
path; each program must be completely transformed all at once, which
effectively means it will never happen. Contrast this with ANSI C,
for example, in which it's possible to incrementally update programs
from traditional to ANSI C, and have them continue to run when only
partially updated. This is a huge win that I've taken advantage of in
my own code.

The third problem I see is that two core features of the language have
been designed as entirely new sub-languages: specifically, the module
system and SYNTAX-CASE. Not only are these new languages, but they
are declarative languages, which makes them fundamentally different
from the core language, which has always been imperative. Worse,
these sub-languages solve problems that could have been solved by
application of the core language, meaning they lead to additional
cognitive complexity while getting little in return.

The module system is basically a way to tell the linker how to
construct programs from parts. Rather than invent a new language to
do this, it's possible to build the linker such that the programmer
can insert code to control aspects of the linking process. Such code
could do _more_ than the current module system does, and because of
the added expressivity, it could do so more concisely in many cases.
For example, I sometimes use a trivial module system in which names
starting with "%" are local, and all other names are exported. This
is a trivial program to write, and doesn't depend on the details of
the names, but it can't be said at all with the proposed module
system.

SYNTAX-CASE has similar problems, although not as extreme: it
implements a term-rewriting system, with limited programmability, to
solve a problem for which there are significantly simpler solutions.
This sub-language introduces a new kind of variable that behaves
differently from the variables we're used to, and pushes
pattern-matching and templating to the center of the macro-writing
process. Yet with this added complexity it is arguably no better than
the syntactic closures or explicit renaming mechanisms proposed years
ago, which have very little cognitive overhead.
Received on Mon Aug 13 2007 - 14:00:19 UTC