a (revised) draft of R5RS

[Chris Hanson <cph@martigny.ai.mit.edu>]

This is the reason that Scheme standardization is dead.

On the one hand, there are a group of people who are trying to make
Scheme a useful programming language.  These people make expedient
choices that use the best currently available technology to produce a
language with the expressive power to write complex programs.  These
people are programmers who are trying to use Scheme as a tool.

On the other hand, there are a group of people who are trying to make
Scheme the cleanest and best programming language.  These people want
to wait until the technology has reached the point that it is elegant,
well understood and well integrated with the rest of the language
before it is standardized on.  These people are language designers who
are trying to make Scheme the best possible language, a work of art.

There really isn't any middle ground between these two points of view,
at least as far as standardization goes.  Each person is going to make
a different trade-off based on their immediate need for expressive
power versus their desire for a beautiful language.

The underlying problem is that these are two very different goals, and
that the Scheme community hasn't chosen one or the other as its basis
for standardization.  The original reason for standardization, which
resulted in RRRS, was to produce a document that defined the common
elements of the then-existing implementations, and possibly to
compromise on some of their differences in an effort to create a
portable language.  Today, there's no such reason.  Portability is
important, but we already have portability for the agreed-upon subset.
Now the problem is to extend that subset, and there's no agreement
about what purpose the extension would serve.

I think a good deal of this is the fault of those of us who
participated in the early standardization efforts.  We thought that we
could live in both camps, having an elegant language that was also
expressive.  We established the tradition of unanimous agreement, and
we tried to standardize only on those things that were well
understood.  This was fine as long as the goal of standardization was
to create a language that was suitable for teaching, in which toy
programs were portable.  Today that's no longer an interesting
motivator, and consequently the traditions of the past are no longer a
good mechanism for moving forward.

The only way I can see to resolve this is to have two languages.  

The first is a kind of cleaned-up Common Lisp, in which it is
understood that the goal is to make the language as powerful as
possible using the best, cleanest language technology of the day, and
incorporating other elements when necessary to solve real programming
problems.  This would be a "snapshot" of the current Scheme
technology, augmented by some reasonable but less-than-excellent
mechanism to cover up Scheme's pimples.  Standardizing on this
language would be a matter of getting the participants to agree on a
clean base language (e.g. R4RS or R5RS) and an acceptable but
imperfect set of patches to cover the pimples.

The second is a work-in-progress, which lacks certain kinds of
expression when it is not yet understood how to cleanly integrate that
expression into the language.  It would be understood that some kinds
of programs would be hard to write in this language, but people would
work to improve the technology until that expression was achieved.
Probably this second language would periodically spin off "snapshots"
that would be used for serious programming.  Standardizing on this
language would be a matter of getting the participants to agree what
parts of the language are well understood and elegant.

Then the only real issue is: which language gets the name "Scheme"?
Frankly, I don't give a damn.