[r6rs-discuss] voting process
lord at emf.net
Mon Nov 3 15:35:20 EST 2008
I'm sympathetic to Bear's position and frustration. My "yes" vote on
R6 was, as I tried to say with my vote, motivated largely by the
thoughts that (a) it wasn't going to get any better under the process at
hand; (b) ratification would enable the community to lick its wounds
and move on.
I hoped that two things would follow ratification:
1) R6RS believers would start cranking out the holy grail of "lots of
useful libraries," -- the much anticipated phenomenon that would
supposedly make Scheme as practical for many as, say, Python, Perl, and
Ruby are today.
2) R6RS critics would converge on a real "correctional" -- make an
With all due respect, neither has much occurred. There are few signs of
life. As to libraries, most everyone seemed to assume that an unnamed
host of "others" would step up to supply them given a new module system.
As to a correctional, the slow but continuing progress on ERR5RS
notwithstanding, my impression from the dialog is that few R6 dissenters
have the economic resources to spend much time on it, much as we'd like
I notice that the only recently finalized SRFI is for environment
variable access. Nothing wrong with that but that's a short list.
I notice only two draft SRFIs, one to standardize an R6 naming
convention for SRFI libraries, the other a records proposal coming out
of ERR5RS. Both fine proposals, I'm sure, but a dismally short list.
There has been some progress on implementing R6 including one new
implementation. I am not aware of any significant advances in
I'm not certain what conclusions to draw from this but I do have some
Except for a small number of academic positions and a small number of
niche industry positions, there appears to be no money to be made using
Scheme, never-mind working on improving it. In contrast, it appears
that a critical mass of commercial adopters of Perl, Python, Java, and
similar languages formed *before* those languages developed large
libraries and community-driven language improvements. The commercial
interest drove the development of those libraries, for the most part.
Now, today, Scheme is handicapped for commercial adoption by the lack of
libraries and so the libraries of those other systems constitute a
"barrier to entry" for any new and improved Scheme.
In retrospect, R6 started very, very late in the game applying a tactic
(developing a module system) that "should" have been done at least a
decade earlier. The effort to add a module system was premised,
roughly speaking and informally attributing motive, to Steele's notion
of a "growable" language and with faith that "if you build it they will
Well, it got built. They didn't come.
(As an aside to Bear: More than a decade ago Guile Scheme attempted to
introduce and promote a module system that, while not perfect, was at
least practical and flexible enough to grow into a more principled
solution. That work was done with commercial support and that
commercial support also disrupted that work and denigrated it at a
critical juncture, delaying progress on it for years, just when and
perhaps even because of the then recently pre-announced Oak, soon dubbed
Java and (then) taken to be the crown prince of client-side programming
on the web. Bear: in my experience, bitterness of the sort you evince
does not fade much with time and the intellectual vindication of seeing
people realize their mistakes far after they are willing to do anything
like admit and correct them is quite a hollow victory.)
Perhaps we have reached a kind of "end of history" in the domain of
and Lua appear to be the focus of most attention. There is money in
browsers; Python at Google). By some kind of "power law" of
economics, it might be unreasonable to expect Scheme to gain much
adoption at all, anytime soon.
Frighteningly, commercial forces will probably continue to align to
thrust some incremental improvement to JVM down our throats as the One
True Run-time System API, even further constraining any innovation in
Without monied adoption of Scheme, it is hard to imagine that we'll have
a lively and productive community cranking out libraries and having
productive debates about how best to improve the core language. Yet
without an improved core and lots of libraries, monied adoption lies
nowhere in sight. Scheme, folks, appears to be a sad and obscure
victim of the obscene excesses and rush-to-build-out of the dot-com
People around my age might get my drift if I put it that: Scheme is the
new Pascal only without even a "Turbo" implementation around. It's the
kind of language you might use for teaching, as a case study: similar
enough to "real world" languages to be educational yet simple enough for
students to dissect or assemble.
If these speculations are right, the situation can not be improved by
revising the standard.
To be sure, as a matter of simple maintenance, it strikes me as a good
idea to replace the steering committee. They wish to step down and so
the community choice is either to give up the pretense and go without a
steering committee entirely, or to replace them with their kind
assistance. If we replace them, there is a ghost of a chance.
And, to be sure, again just as a matter of routine maintenance, an
eventual R7 or substantially similar follow-up is desirable, if we can
muster it. R6 would make a poor, sad coda to the series. As a matter
of respect for our belief in the good work and good ideas that are our
community heritage, at the very least, at least one more less
problematic document is desirable.
I would like to propose some theses, based on these observations, though
I doubt I can come up with 95 of them just now:
1. The role of a steering committee is unconstrained. The next steering
committee is not limited to appointing editors and initiating an R7
2. To advance the Scheme language meaningfully requires more than an R7.
To become "relevant" other than as a historic expression of certain
ideas -- that is, to become "practical" or to be a "tool" for
engineering -- Scheme needs compelling applications.
3. Nothing in the R_RS series is sacred other than, perhaps, a
commitment to recognizably traditional lisp-ish types, s-exp notation,
lexical scoping, closures, continuations, and a dedication to providing
some powerful form of syntactic abstraction. I.e.: there is nothing
"sacred" to Scheme in the R_RS series that isn't already found in the
Rabbit thesis and "Lambda the Ultimate..." papers. Scheme remains, at
heart, a set of ideas that aim to describe a practical approach to
building practical systems using a few famous "tricks".
4. Scheme (thus understood) is superior, in principle, to its real-world
competitors. It suffers in the real world from under-funding,
ultimately. The ideas need to be realized in a commercially compelling
form for a broad audience if we are to raise the bar for dynamic
languages. Scheme is very well suited as a starting point for doing
5. The next steering committee should formalize and sanctify its status
by seeking funding assistance sufficient to create a non-profit
corporation with a self-nominating board which is distinct from the
steering committee itself. The bylaws of this NPO should define a form
of membership sufficient that the membership elects the steering
committee and the steering committee normally controls operations, but
the board may step in to override. While the board should be
self-nominating, it should be chartered such that signifcant details of
its expenditures are public record and such that periodic "confidence
votes" are solicited from the membership and the results made public
record. (These public records are for the benefit of the membership,
the board, and current and potential sponsors.)
6. Simultaneously, the next steering committee should develop, in a
transparent fashion and soliciting suggestions from the community, a
series of proposals for fund-able, free software projects which aim to
help bootstrap far greater real-world adoption of Scheme, including
commercial adoption. Each project proposed should include a
contribution to an eventual R7. An eventual R7 should include *at
least* one official reference implementation.
7. The new board and steering committee should engage in fund-raising,
primarily but not exclusively from potential corporate sponsors, to hire
staff to work on those proposals.
The net effect would be to create a kind of semi-democratic, non-profit,
Institute for the Advancement of Scheme. I'm not sure there is any
lesser hope worth aiming for.
On Mon, 2008-11-03 at 10:19 -0800, Ray Dillinger wrote:
> On Mon, 2008-11-03 at 12:23 -0500, Marc Feeley wrote:
> > I meant divergent opinions on the "soul" of Scheme and on the goals.
> > In other words fundamentally divergent opinions on Scheme and the
> > design process. The message(s) from the SC to the EC must be clear
> > and direct. That will simply not happen if there is discord at the SC
> > level. Divergent opinions are good, and necessary, as long as the SC
> > members are comfortable in discussing the issues to converge on a
> > common position, but fundamentally divergent opinions will kill the
> > process. I believe the EC can tolerate more divergence of opinion.
> > Here too it can be a problem that stalls the process, but the SC can
> > step in in those cases.
> I see in R6RS a repudiation of the spirit of Scheme - and also
> a poor standards document.
> In part this was because there was insufficient effort to
> respond to divergent opinions or to draft a general standard
> suitable for implementing scheme on diverse platforms. Ideas
> for resolving conflicts got ignored without technical response
> as the processed rushed to adopt specific proposals. The
> standard itself was passed while still containing known errors
> and inconsistencies.
> There was an opportunity to create a document that specified a
> (drastically simplified) "core scheme" and pushed all controversial
> items out to libraries which are, in principle separable and
> interchangeable. This was not done. The "core language"
> specified in R6 is not simpler and contains many controversial
> elements that could have been placed in libraries. The library
> of functions is monolithic, inseparable, and there is no way
> to create any alternatives to any part of it. This is not just
> a failure, it is an epic failure. And no amount of effort
> seemed capable of convincing any of the editors that there was
> any better way to do things.
> In this process, I felt that whatever input I (and several others
> whose design sense I respect) made was ignored or treated as a
> mere obstacle. I was frustrated with the process and I am
> unsatisfied with its result. I am not emotionally ready to repeat
> the investment of work at this time, and I do not feel that such
> an investment of work would be very likely to give better results
> at this time. Moving into the process, as I would, on the defensive,
> still stinging with frustration, and with reduced expectations that
> good ideas will actually be listened to, would not make me a "nice"
> person to work with and would be unlikely to elicit my best
> standards work.
> Also, I feel that it's necessary for its supporters to have enough
> time to take new positions. I don't want them defending Bad
> Ideas merely because they defended them before and can't
> stomach admitting that they were wrong. I think they need a
> year or two more to first understand and then get over how badly
> they screwed up.
> As far as I'm concerned, R6RS was a waste of effort on my part
> and I don't want to touch it again until I'm pretty sure the
> rest of the world has fully appreciated its flaws. Only with
> that realization will people be truly ready to try and fix it
> and future effort less likely to be wasted.
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
More information about the r6rs-discuss