R6RS Ratification Vote

Here are the final results of the ratification vote.

67 electors voted to ratify draft 5.97 as R6RS. 35 electors were opposed to ratification. Thus 65.7% of those who voted, voted in favor of ratification. This is more than the 60% required for ratification. The Steering Committee therefore ratifies the draft numbered 5.97 as the official "Revised6 Report on the Algorithmic Language Scheme".

A companion document containing some additional correspondence received after the poll closed is available here.

Voting in favor of ratification:

Voting against ratification:

Name: Abdulaziz Ghuloum
Location: Bloomington, IN, USA

Affiliation: Indiana University
Ratify: YES

Name: Adam Blinkinsop
Location: Hillsboro, OR, USA

Ratify: YES
The language is described and explained very well.

Name: Alexey Radul
Location: Boston, MA, USA

Affiliation: Massachusetts Institute of Technology
Web: http://web.mit.edu/~axch/www
Ratify: YES
Let me begin this addendum to my vote with thanks to
the editors of the report, and everyone involved in the Scheme
standardization process.  I imagine it must have been a monumental
effort, and I appreciate the work put into this wonderful programming
language that I like so much.  On reading the report and associated
documents, and pondering what they contained and did not contain, I
ultimately reached a position I expect to be isomorphic to that of all
those who vote to ratify the proposal --- 'This putative standard is
not perfect, but it is enough of an improvement over the previous
state of affairs that it deserves to be ratified.'  I have, on
reflection, found that all of the imperfections that troubled me are
solvable with standard-consistent SRFIs (which admittedly are not
necessarily implementable portably) and support from the programming
environment.  Nevertheless, I feel that two of these imperfections
deserve description here, perhaps as fodder for additions to the
Rationale document, and perhaps to stimulate the production of said

One of the imperfections that troubled me is the apparent
inflexibility of the library system.  It appears that it is difficult
to define and use a library for, say, generic arithmetic, that would
extend + and * to work on, say, matrices.  Specifically, it appears
that if one were to just import (rnrs (6)) and (generic-arithmetic),
one would get a symbol conflict and one's program would not run.
Consequently, one must explicitly exclude or rename the (rnrs (6))
symbols that are also exported by the putative (generic-arithmetic)
library.  One is forced to choose whether to exclude all the symbols
that (generic-arithmetic) redefines or only to import those symbols
from (generic-arithmetic) that one wants, and exclude only them.  Both
options are unfortunate.  Excluding all (generic-arithmetic) symbols
from one's (rnrs (6)) import is annoying, especially in the situation
where (generic-arithmetic) exports many symbols, such as cos or expt,
many of which one might not care about, and which one might need to
seek out in the library's documentation.  Doing so is also unstable if
the (generic-arithmetic) library is updated to overwrite more (or
fewer!) symbols from (rnrs (6)).  On the other hand, importing only
the symbols one wants from (generic-arithmetic) is also annoying,
because it is difficult to remember all the operations one may wish to
use, because one has to mention them in both the exclude and the
import only clauses, and of course because one will then change one's
mind about which exports of (generic-arithmetic) one wants.  I have
high hopes, however, that either a SRFI that extends the library
import syntax with a shadow form and/or a clever M-x organize-imports
function will alleviate this trouble.

The other imperfection that troubled me is the absence of a facility
analagous to Common Lisp's reader macros, and even an apparent
obstacle to the definition of such a facility.  I have several
specific use cases for such a facility in mind, mostly to do with
literal strings and regular expressions.  Regular expressions, for
better or for worse, use the backslash as an escape character just
like strings do, but with a different set of escapable characters.  If
one tries to write literal regular expressions in Scheme, therefore,
one is forced to double those of one's backslashes that are intended
for the regular expression parser rather than the string parser.
Furthermore, the natural printed representations of regular
expressions will include backslashes, and are therefore grossly
unsuitable for copying and pasting into Scheme source.  All this is
irritating in the extreme, and I wish Scheme had a mechanism whereby I
could write a user-land library that permitted something like
#/foo|bar/ as literal syntax for a regular expression (in this case,
one that matched either 'foo' or 'bar').  In the particular case of
regular expressions, a macro won't have the desired effect, because
the string out of which one would build a regular expression gets read
by the reader, with the attendant substitution of backslash escapes,
before the macro-expander sees it.  [Note that while I am all for an
s-expression language for semantically specifying complex regular
expressions, the compact, string-based notation is, in my experience,
far easier to read for short, simple ones.]

Another use-case for reader macros would be a facility analagous to
Ruby's and Perl's string substitution mechanisms.  I would like to be
able to write what amounts to quasiquote for strings, and while the
bulk of the work can certainly be done by a macro, it would be nice to
have a short cut analagous to the backquote, perhaps sharpsign
doublequote, for all of the same reasons.  Yet another use-case for
reader macros are here documents, again inspired by Perl and Ruby.
Those languages provide a facility for embedding comparatively long
documents into one's source code as string literals.  Long literal
strings have different needs from short ones, for instance in that the
usual string delimiter characters may appear in them.  Therefore, the
here document facilities I am familiar with give the programmer
control over the end delimiter used (often the word END or HERE on a
line by itself, hence the name of the facility) and some control over
the amount of string interpolation that is done on such embedded
texts.  Scheme could benefit from a library for this, and it seems
that such a facility cannot be implemented as a macro over data that
has already been processed by the reader.

I have made the case that there are extensions to Scheme's lexical
syntax that are worth considering adding to the language.  They are
sufficiently disparate and special-purpose that it would be
aesthetically displeasing, to say the least, to implement them all as
separate, one-off additions to the syntax of the language.  They are
also complex enough that it would be very valuable to be able to
implement them as user libraries and actually experiment with how well
they work, without having to recompile one's Scheme, before submitting
SRFIs proposing specific variations to the larger community.  In fact,
it would be valuable to be able to use such extensions in one's own
work, portably across implementations, without having to secure the
community's consensus at all.

I am therefore troubled by the paragraph immediately preceding Section
4.1 of the main report, which appears to throw up an obstacle to the
implementation of reader macros or any analagous facility as a SRFI,
in the form of a prohibition against any changes of the lexical syntax
of Scheme whatever.  One reading of that paragraph suggests that that
impression may be mistaken, as a SRFI that introduced a shebang
directive like #!srfi-314-reader-macros which signalled that
subsequent code was subject to interpretation according to the reader
macro facility specified in this hypothetical SRFI 314 would
constitute a standard-compliant extension adding reader macros, but
such a directive feels like an awkward increase in boilerplate, and
begins to smack of a thrid-party code distribution mechanism
completely orthogonal to the library system.  Whether or not that
reading of the report is, in fact, the intended one, I would greatly
appreciate a rewording of the relevant segments to make that clearer,
as well as a section of the Rationale document explaining why the
editors of the report reached the decision that they did about reader

Name: Andreas Bernauer
Location: Tuebingen, Germany

Affiliation: University of Tuebingen
Mail: r6rs at lysium remove-this dot de
Web: http://www.lysium.de
Ratify: YES
I think the draft is a good continuation of the current
 standard.  In particular, I like the newly introduced concept of
  libraries, that the handling of unicode characters is specified
  and that error conditions can be handled within a Scheme program
  in a standardized way.

Name: Arjun Guha
Location: Providence, RI, USA

Affiliation: Brown University
Ratify: YES

I am an idiot for not replacing this

Name: Arthur A. Gleckler
Location: Sunnyvale, CA, USA

Mail: r6rs@speechcode.com
Web: http://speechcode.com/
Ratify: YES

Name: Ben Simon
Location: Arlington, VA, USA

Mail: contact.ben.simon@gmail.com
Web: http://benjisimon.blogspot.com/
Ratify: YES
While there are some aspects of R5.97RS that I'm
uncomfortable with, I think it's an overall step in the right
direction. I'm confident that time will tell which aspects of the
report need to be corrected, and that this will be done for R7RS.

Name: Bill Heyman
Location: Eden Prairie, MN, USA

Affiliation: Heyman Software, Inc.
Mail: bill@heymansoftware.com
Web: http://heymansoftware.com/
Ratify: YES

Name: Bob Burger
Location: Indianapolis, IN, USA

Affiliation: Beckman Coulter, Inc.
Ratify: YES

Name: Brent Benson
Location: Burlington, MA

Affiliation: Oracle, USA
Ratify: YES
I am voting 'Yes' for ratification of the current R6RS 
draft.  My belief is that the draft represents a step forward for Scheme 
and that it accomplishes stated goals of the editors like unicode 
support, libraries and exceptions.

In addition, I wrote in my registration statement that one of the 
criteria by which we should judge this standard is whether it provides 
clear direction on how to accomplish basic programming tasks in a way 
that does not require building your own infrastructure, or resorting to 
implementation-specific features.  I believe that the current draft 
standard does an acceptable job meeting this criteria by providing 
standard mechanisms for things like exceptions and tagged records.

I would like the thank the editors for their hard work and dedication in 
bringing the standard to its current state.

Name: Brian Thomas Sniffen
Location: Cambridge, MA, USA

Mail: bts@alum.mit.edu
Web: http://www.evenmere.org/~bts/
Ratify: YES

Name: Carl D. Offner
Location: Boston, MA, USA

Affiliation: University of Massachusetts/Boston
Web: http://www.cs.umb.edu/~offner
Ratify: YES
I confess that I didn't follow the development process of R6RS 
closely, but I
have spent considerable time over the last few weeks reading the report and the
various email trails carefully.

I started out feeling pretty negative about the report.  I really liked the
50-page tight simplicity of R5RS.  But I've made my peace with most of R6RS.  I
do appreciate that there are a number of things that are specified in much
greater detail, and/or better explained, and/or made more consistent.  And while
I'm not sure of the need for *all* the macro facilities, I'm willing to believe
that they were felt necessary by people with more expertise in this area than

A few minor observations:

The terms *static* and *dynamic* scoping are used, and perhaps it can be assumed
that the reader of this report would know what they mean.  But it couldn't hurt,
for instance, when explaining how a lambda expression evaluates to a procedure,
that the particular method of evaluation implements static scoping.

The term *deprecated* is used twice in the report, and twice in the rationale,
but as far as I can see, is never defined.  And I think in addition, that some
justification should be given for the deprecation of features.  I'm particularly
concerned about force and delay, but the point is general.  Some answers are
hinted at near the end of the rationale document, in a very terse fashion, and
force and delay aren't dealt with at all.

I don't understand the way the base library functions in the report.  In
particular, I don't see why the base library isn't just part of the language.  I
mean, you don't have much of a language without arithmetic, for example, right?
Why does a program need to explicitly import it?  (Or did I miss something?)

I know that in general, there is no definitive answer to why something gets in a
language report.  The ultimate answer simply is that the vote went that way.
Nevertheless, I think the time may be right for an expository piece -- perhaps
even a short book -- that attempts to justify the current definition of the
language.  Another obvious question, for instance, is this: Since call/cc has
always been regarded largely as the Scheme escape mechanism, why was a new
escape mechanism introduced in addition?  And does this now do away with the
need for call/cc?  (I assume the answer is no, and I think I could even come up
with a reason myself, but I'd like to see some discussion of this.  It would at
least be interesting, I think.)

Maybe the answers to all these questions are available in the report or the
email trail.  But I'll bet that if I missed them, then a lot of other people
did, or will, as well.

Name: chris koehnen
Location: st.paul, mn, usa

Ratify: YES

Name: Danny Yoo
Location: Worcester, MA, USA

Affiliation: PLT
Mail: dyoo@cs.wpi.edu
Web: http://hashcollision.org/
Ratify: YES

Name: Dave Gurnell
Location: Birmingham, UK

Affiliation: Untyped Ltd
Web: http://www.untyped.com/about/dave
Ratify: YES

Name: David Fisher
Location: Boston, MA, USA

Affiliation: Notheastern University
Mail: dfisher@ccs.neu.edu
Web: http://www.cs.gatech.edu/~dfisher/
Ratify: YES
I find the current draft to be an excellent compromise.  
Building a standard that is acceptable to the community as a whole, 
especially one as opinionated as the Scheme community, is clearly going 
to make no one completely happy.  However, R5.97RS contains all of the 
elements that I feel the new standard needs, perhaps not in exactly 
the same form as I would have specified them, but definitely in a form 
that should be acceptable to any implementer.  Therefore I am voting TO 
RATIFY this draft of R6RS.

Name: David Frese
Location: Eningen unter Achalm, BW, Germany

Ratify: YES

Name: Donovan Kolbly
Location: Austin, TX, USA

Affiliation: RScheme Development Group
Mail: dmk@rscheme.org
Web: http://www.rscheme.org/~donovan/
Ratify: YES
R6RS is a huge step forward.  May its fulfillment match its promise.

Name: Dr. Thomas F. Gordon
Location: Berlin, Germany

Affiliation: Fraunhofer Gesellschaft
Mail: thomas.gordon@fokus.fraunhofer.de
Web: http://www.tfgordon.de
Ratify: YES
The 5.97 draft standard brings Scheme up-to-date,  
helping to make it a viable alternative to more popular languages  
such as Java and Python. It library feature promises to facilitate a  
much larger body of portable Scheme code. And although these  
languages are improving, by borrowing ideas from Scheme and other  
functional languages, they still sorely lack features of Scheme which  
are important for my work, such as s-expressions and macros, which  
are incredibly useful for implementing domain specific languages.  I  
understand that 5.97 may not be perfect from an academic point of  
view, but Scheme standards are living documents. The SRFI process and  
future versions of the Revised Report provide procedures for  
continuing to improve the standard.  And Scheme implementors are  
surely free to make non-standard improvements and extensions, as they  
have in the past.

Name: Eli Barzilay
Location: Cambridge, MA, USA

Affiliation: PLT
Mail: eli@barzilay.org
Web: http://barzilay.org/
Ratify: YES

Name: Eric Knauel
Location: Tuebingen, Germany

Affiliation: Universitaet Tuebingen
Mail: knauel@informatik.uni-tuebingen.de
Web: http://www-pu.informatik.uni-tuebingen.de/users/knauel/
Ratify: YES

Name: Erich H. Rast
Location: Berlin, Germany, Europe

Mail: erich@snafu.de
Web: http://www.peppermind.com
Ratify: YES
R5.97RS is a reasonable candidate. Ratifying it now  
is better than wait and quibble about details for an indefinite time.  
There is no doubt that this report has numerous advantages over R5RS  
and implementations should support it as soon as possible.

Name: Grant Rettke
Location: Milwaukee, WI, USA

Ratify: YES
Reading through all of the electorates stated concerns
makes me feel nostalgic; thinking back to that moment I first fell in
love with computer science. Scheme seems to have that effect on
people; love at first sight. Having read once that 'any truly good
language, no matter what its original goals, will eventually become a
general purpose programming language; that is the nature of a good
language', I can't help but think that Scheme has this nature. Scheme
is special. It draws people in. It is a place to learn, and play. My
hope is that the direction set forth by R6RS will prepare Scheme for
the masses, giving it an opportunity truly shine.

Name: Herman Ehrenburg
Location: Delft, Netherlands

Ratify: YES
The proposed standard is an enormous improvement in my opinion. It makes
the language much more complete and easier to use for various tasks. Most
importantly, it will allow practical support for the language to grow
rapidly. I would not be surprised if the proposed standard, if accepted,
turns out to be a major breakthrough for the language.

Name: Ian Barland
Location: Blacksburg, VA, USA

Affiliation: Radford University
Ratify: YES

Name: Jacob Jozef Anthonius Koot
Location: Spain Barcelona Mataro

Web: http://www.telefonica.net/web2/koot/
Ratify: YES
No comments

Name: Jay A. McCarthy
Location: Providence, RI USA

Affiliation: Computer Science Department, Brown University
Mail: jay.mccarthy@gmail.com
Web: http://jay.teammccarthy.org/
Ratify: YES

Name: Jean-Michel Hufflen
Location: Besancon, France

Affiliation: LIFC --- University of Franche-Comte
Mail: hufflen@lifc.univ-fcomte.fr
Web: http://lifc.univ-fcomte.fr/~hufflen
Ratify: YES
I think that this version (5.97) is good progress to a better standard
   of Scheme, the basic ideas---lexical scoping,
   continuations, ...---being still present.
      Concerning the language itself, I especially appreciate:
   ---the notion of libraries,
   ---the way the standard libraries have been built,
   ---the definition of exceptions.
      My regrets:
   ---some functionalities related to handling files and directories are
   ---the functions dealing with Unicode could have been more powerful.
      About the report, I appreciate the clear distinction among must/must
   not/should/shoud not/may.
      To conclude with a personal touch, I would be ready to rewrite
   MlBibTeX---my new implementation of the BibTeX program---using this new

Name: John Clements
Location: San Luis Obispo, CA, USA

Ratify: YES

Name: John Cowan
Location: New York, NY, USA

Affiliation: None
Mail: cowan@ccil.org
Web: http://www.ccil.org/~cowan
Ratify: YES
I vote yes, not because I think R5.97RS is perfect,
or because I agree with every detail of it, but because I think it is
good enough to become the next generation of Scheme.
See my registration for further explanations.  R5.97RS is a compromise,
and a well-crafted compromise is in my opinion the most sacred thing
that a secular age knows.

Name: John David Stone
Location: Grinnell, Iowa, USA

Affiliation: Grinnell College
Mail: stone@cs.grinnell.edu
Web: http://www.cs.grinnell.edu/~stone/
Ratify: YES
       Almost all of the proposed changes increase Scheme's
usability more than they reduce its simplicity and elegance,
even for novice programmers.

Name: Jose Romildo Malaquias
Location: Ouro Preto, MG, Brazil

Affiliation: Universidade Federal de Ouro Preto
Web: http://www.decom.ufop.br/prof/romildo/
Ratify: YES
Scheme needs facilities for portable development.

Name: Joshua Herman
Location: Darien, IL, USA

Ratify: YES

Name: Kathi Fisler
Location: Providence, RI, USA

Affiliation: WPI (Worcester Polytechnic Institute)
Web: http://www.cs.wpi.edu/~kfisler/
Ratify: YES

Name: Kevin Millikin
Location: Aarhus, Denmark

Affiliation: Department of Computer Science, University of Aarhus
Web: http://www.brics.dk/~kmilli
Ratify: YES

Name: Kevin P. Albrecht
Location: Tampa, FL, USA

Mail: onlyafly@gmail.com
Web: http://kevin.alteu.com/
Ratify: YES
I believe that R6RS will unite the Scheme community and
reduce incompatibility between implementations.

Name: Konstantin Matveev
Location: Moscow, Russian Federation

Ratify: YES
Other people express their opinions so good that I will refer
to them. Essay of Matthew Flatt says it all about a process of
standartization: polishing current document will take lots of time and will
add very little, we can wait for perfection forever. Let's make a milestone
and see what will happen next. Developers of Scheme implementations who will
like the result  will soon make their products to be standard-compliant,
others will stay with old standards, so we will clearly see how popular new
standard will be. Previous standards also had some missing parts, which were
added by subsequent standards, and had some unnesessary parts, removed by
subsequent standards. Regarding a direction where Scheme standard is going,
I will refer to essay of John Clements who calls for unity in areas which
are no longer experimental field, but practical nesessity.

Name: Kyle Cronin
Location: Bangor, ME, USA

Ratify: YES
I've looked over the 5.97 draft and read the criticism
that it includes too much. However, I disagree. While simplicity has
always been one of the hallmarks of Scheme, the extremely small core
language makes fragmentation between implementations inevitable. I
believe that a more thorough standard is required to ensure

Name: Kyle Smith
Location: Sugarloaf Key, FL, USA

Affiliation: Retired
Mail: mzscheme@gmail.com
Web: http://www.schemekeys.net
Ratify: YES

Name: M. Douglas Williams
Location: Denver, CO, USA

Affiliation: SAIC, Inc.
Ratify: YES
The current 5.97 draft standard represents a reasonable 
consensus among the Scheme community and will serve well as the basis 
for future evolution of the language.

Name: Marco T. Morazan
Location: South Orange, NJ, USA

Affiliation: Seton Hall University
Ratify: YES
Although not perfect and still containing many areas
that can be improved (as seen in the electronic discussion), I vote
for approval. What we have here is a solid basis from which we can
continue to guide the evolution of the Scheme standard. I see R6RS not
as having reached the end goal, but as a step in the devlopement
process. I thank the members of the committee for their time and

Name: Marcus Crestani
Location: Tuebingen, Germany

Ratify: YES

Name: Mark Engelberg
Location: Everett, WA, USA

Ratify: YES

Name: Matthew C. Jadud
Location: Canterbury, Kent, UK

Affiliation: The Transterpreter Project
Web: http://www.transterpreter.org/
Ratify: YES
The library system is an incredible step forward. It
brings us closer to being able to write large systems that are
portable across multiple implementations.

Name: Matthew Flatt
Location: Salt Lake City, UT, USA

Affiliation: University of Utah
Mail: mflatt@cs.utah.edu
Web: http://www.cs.utah.edu/~mflatt/
Ratify: YES

Name: Matthias Felleisen
Location: Boston, MA, USA

Affiliation: PLT
Web: http://www.ccs.neu.edu/home/matthias/
Ratify: YES
R6RS is "perfect".

Name: Michael Greenberg
Location: Boston, MA, USA

Web: http://www.weaselhat.com/
Ratify: YES

Name: Michael Sperber
Location: Tübingen, BW, Germany

Affiliation: DeinProgramm
Web: http://www.deinprogramm.de/sperber/
Ratify: YES

Name: Noel Welsh
Location: Birmingham, UK

Affiliation: Untyped Ltd
Web: http://www.untyped.com/
Ratify: YES
Progress before perfection

Name: Ogechi Nnadi
Location: Atlanta, GA, USA

Affiliation: Georgia Tech, as at 2007
Ratify: YES

Name: Paulo Jorge de Oliveira Cantante de Matos
Location: Southampton, Hampshire, United Kingdom

Affiliation: DSSE, ECS, University of Southampton
Mail: pocm@soton.ac.uk
Web: http://www.personal.soton.ac.uk/pocm
Ratify: YES

Name: Pinku Surana
Location: Jersey City, NJ, USA

Ratify: YES
I wanted to vote against ratification because some aspects of
the standard are less than perfect. It's the tension between "the right
thing" vs. "worse is better". This time Scheme needs a splash of "worse
is better" to move the language standard forward. Let's hope some
experience can help the next standards group reach for the right thing.

Name: Prabhakar Ragde
Location: Waterloo, Ontario, Canada

Affiliation: University of Waterloo
Ratify: YES

Name: R. Kent Dybvig
Location: Bloomington, IN, USA

Affiliation: Indiana University and Cadence Research Systems
Web: http://www.cs.indiana.edu/~dyb/
Ratify: YES
It's not perfect, but it's good enough, and I'm happy
   to leave pursuit of perfection to the r7rs editors.

Name: Reinhard Ruessau
Location: Nagold, Baden-Wuerttemberg, Germany

Ratify: YES

Name: Richard A. Cleis
Location: Albuquerque, New Mexico, USA

Affiliation: Starfire Optical Range
Ratify: YES
A more extensive standard will make it easier to  
convince colleagues to use it.

Name: Robby Findler
Location: Chicago, IL, USA

Affiliation: University of Chicago
Web: http://www.cs.uchicago.edu/~robby/
Ratify: YES

Name: Ronald Garcia
Location: Bloomington, IN, USA

Affiliation: Indiana University
Ratify: YES

Name: Ryan Culpepper
Location: Boston, MA, USA

Affiliation: Northeastern University
Web: http://www.ccs.neu.edu/home/ryanc/
Ratify: YES

Name: Ryan Rhodes Newton
Location: Boston, MA, USA

Affiliation: MIT
Web: http://people.csail.mit.edu/newton
Ratify: YES
Reason for voting yes: pragmatism.  If I am to  
continue to write Scheme code, I must be able to make use of multiple  
implementations without bending over backwards to do so.

Name: Sam Tobin-Hochstadt
Location: Boston, MA, USA

Affiliation: Northeastern PLT
Mail: samth@ccs.neu.edu
Web: http://www.ccs.neu.edu/~samth/
Ratify: YES
The current draft is not perfect, but it is a clear
improvement on R5RS and takes Scheme forward in the correct

Name: Shriram Krishnamurthi
Location: Providence, RI, USA

Affiliation: Brown University
Web: http://www.cs.brown.edu/~sk/
Ratify: YES
It is time for Scheme to move forward.

Name: Sven Hartrumpf
Location: Hagen, Germany

Ratify: YES

Name: Thomas Lord
Location: Berkeley, CA, USA

Mail: lord@emf.net
Ratify: YES

    Well, it's not terribly clever of me but I will steal
    a quote that J.H. Conway uses in the preface to 'On
    Numbers and Games' from Bunyan's 'Apology for his Book
    (Pilgrim's Progress):

        Some said 'John, print it'; others said 'Not so.'
        Some said 'It might do good'; others said 'No.'

   It will be a waste of time to drag out discussion of the
   draft much longer and, even for all the objections raised,
   'it might do good.'   Meanwhile, if there is long-term
   substance to the dissent, I am hopeful that that that
   dissent can gracefully congeal in and exploit the SRFI
   process to evolve things beyond the current draft.

   If it seems I'm saying 'Sigh.  It'll do I guess.  Good
   enough,' well, I suppose I am.   That's not feint praise,
   though -- not for R_RS.


Name: Tim McNerney
Location: Newton, MA, USA

Web: http://www.4004.com/
Ratify: YES
I no longer feel strongly enough about the case-sensitivity
issue to throw a monkey-wrench into the whole ratification process.
Besides, with Unicode being allowed as <constituent>s of <identifier>s,
the case mapping would get complicated.  If it was only <letter>s that
were at issue, then it would expose a certain 'Roman' bias in the language.
After all, it is easy to imagine someone having a good reason for an
upper-case Greek letter being destinct from its lower-case counterpart.

Name: Wayne Richards
Location: Houston, TX, USA

Web: http://www.taxupdate.com
Ratify: YES
greater compatibility between implementations

Name: Will Meierjurgen Farr
Location: Cambridge, MA, USA

Affiliation: Department of Physics and Kavli Institute for Astrophysics and Space Research, MIT.
Mail: farr@mit.edu
Web: http://web.mit.edu/farr/www/
Ratify: YES
I would gladly trade a report full of mistakes---not that I think
this is such a report, but some do---for a library system which
properly handles hygienic macros.  Therefore, I am voting "Yes" on
R6RS.  (The exception specification is just icing on the cake, as far
as I'm concerned.)

Some consolation for those who do think this report is full of

1. I expect we'll be seeing lots of "(r6rs base)"-compliant
implementations which leave off libraries they don't like, and

2. "...in most matters it is more important that the applicable rule
of law be settled than that it be settled right." --- Burnet
v. Coronado Oil & Gas Co., 285 U.S. 393, 406--408 (1932) (Justice
Brandeis dissenting).

Name: Aaron Hsu
Location: St. Louis, MO, USA

Mail: aaron.hsu@sacrificumdeo.net
Web: http://www.aaronhsu.com
Ratify: NO
There are a number of good, nice things that I see being
made available in this draft at a high level, and I greatly applaud the
efforts of the committee to develop something that fosters the important
goals of portability and simplicity. However, if I were to sum up my
objections to ratifying this current draft, it would simply be that this
draft no longer maintains what I have come to believe to be the core
philosophical values of the Scheme language. This draft appears to
diverge so significantly from the other drafts in terms of organization,
size, and scope, that it seems like it should not even be considered the
same species.

While I cannot call myself qualified enough to discuss the minute
details of language specification and detail, I can come at this from an
user who has utilized Scheme for pedagogical, professional, and research
uses. If the language fails to be able to provide for these three
sectors, it fails to adequately serve its purpose. I believe that the
standard falls short of meeting what I would consider essential
advantages of Scheme in all three of these areas. It appears as though
this standard attempts to bring in the ideas or concepts of other
languages in an attempt to convert the language from a Beautiful Lisp
language, to just another common programming language with some cool
features and a strange syntax. That is to say, the focus seems to have
been lost.

Let me first deal with the pedagogical area. This draft removes the
aspects of elegant simplicity and limited scope that make Scheme such a
great language for teaching. Right now, Scheme is easy to learn, because
the core concepts are simple, and they extend outward in reasonable,
predictable ways. A student who is learning to program can focus on a
small aspect of the language and feel comfortable with tackling the rest
of it later. As I see it now, the standard has become massive relative
to R5RS. Not only does its size hinder a new student, but it also makes
creating simple conforming Schemes that are easy for a newcomer to learn

Now, I do teach, but more pressing on my needs are research and
professional development. I see severe limitations of the language with
regards to professional development. Something that was great about
using Scheme for professional development was that I could precisely
mold my implementation and code to fit the task at hand precisely,
rather than using large, sledge hammer tactics, such as is often the
case with over engineered OO designs. Many of these features included in
this draft are absolutely useful features that I like to have in an
implementation. However, to require them in the standard limits the
capacity of the implementors to work in small, specialized fields.
Embedded devices immediately come to mind, but other things also come to
mind, such as applications that may not desire unicode, libraries, or
other pieces.

Granted, I do believe in the goals of interoperability, which is one of
the most problematic issues with Scheme's. I am not happy with the way
the library, unicode, disregard for very standard SRFI's, such as
SRFI-1. There does not seem to be enough flexibility given to the
implementors to do things in ways that might suit particular
applications. Put simply, the goal of interoperability should not be
achieved by demanding that one size fits all. Rather, there should be
discovered some way to simplify, rather than add on features, and to
reduce the total bloat in a way that permits such bloat as extensions if
desirable, but allows this to be done in a way so that applications may
have confidence of running unmodified on other implementations assuming
that the needed extensions exist. Rather, this standard assumes that
features exist, and hopes to provide portability in this way. I do not
like this. While I would love to see the features outlined here in
implementations, I also wish to respect the flexibility of the language
to permit specialized and very minimal implementations, without having
to break with the standard.

Now I'd like to come to one of my own personal rants. Case-sensitivity.
The change to case sensitivity flies in the face of Scheme tradition,
for little to no benefit. To suggest such a major change in the
standard, imo, for absolutely no significant benefit, against the
traditions of Scheme, seems to be very, very ugly. Besides the fact that
its easier to add Case-sensitivity in than to remove it in individual
implementations, I very much dislike this new addition, and take it as
my example that this standard is trying to change the heart of Scheme.

Thus, therefore, No.

Name: Adrien Pierard
Location: Paris, France

Ratify: NO
As many other schemers I think that what makes Scheme great is its
reduction to the strict minimum. I must agree that nowadays, a language
that does not handle UTF-8, should it be in strings or identifiers,
irritates me quite a bit. I also believe that a language that clearly lacks
a module/library/embedded-regexps system often ends up being a real pain to
use. And I am not the only one to reimplement FOLD-LEFT or FILTER more than
once a day. Of course, there are some SRFI's out there supposed to make our
lives easier. And I believe in that. In fact, I believe a lot more in time
spent developping new SRFIs, than in time spent wondering about the best
character set. For this reason, although I agree more than I disagree with
the R6RS draft, I decided to vote 'No'. I personnaly stick more to R4RS
than even R5RS (for I like plain old dirty DEFINE-MACRO and its lack of
hygiene), and I see no point in supporting R6RS. Moreover, I reckon that it
will make Scheme too much complicated for a gain not worth it. I suggest
well all focus on defining vital SRFIs, and that we all agree on portable
extensions of Scheme, to implement, say, TCP/IP, non blocking IOs or
bindings to a graphical library. I think that it costs too much to add a
module system, and that this should be left to the maintainer of
implementations to give their own if they want. Yet, whatever system they
use (shoud it even be built-in or 'built-over' as Snow), we should agree on
definining and sharing APIs for just anything we find useful.

Eventually, I decided to say No to R6RS, not because I think its
fundamentally bad, but because I think that it is definitely not what we
should be focusing on. Think of it as an 'I say no for your own good'. I
hope that the community will always be open and eager to share and compare
opinions, as it is now, and that the next major evolution of our langage
will not rely on its already genetically well fitted design, but rather on
its ease of use for whatever challenging task we encounter. And that
sockets will be implemented eventhough no generic portable implementation
could be given.

In fact, I see Scheme as someone with a psychic disorder. We have a well
defined language, we can think with it. But we spent (and still spend) so
much time in defining the language itself that we eventually forgot to
define the way to speak and communicate with the outside world. And R6RS
does not solve this issue, neither does it offer the tools to solve it.
Let's keep Scheme small, but let's add some new plugs to it.
(No Scheme implementation was hurt during the redaction of this ballot. And
the camel was already dead, I swear.)

Name: Alan Watson
Location: Morelia, Mexico

Affiliation: Universidad Nacional Autonoma de Mexico
Mail: a.watson@astrosmo.unam.mx
Web: http://www.astrosmo.unam.mx/~a.watson/
Ratify: NO

1. Prolog

The candidate R6RS has been prepared over several years by a
distinguished group of editors. They have worked hard to identify and
solve problems in the R5RS to make Scheme a more useful language while
remaining faithful to its origins. In particular, they have engaged in a
public discussion of various drafts over most of the last year. We are
indebted to the editors.

2. Vote

With regret, I vote to REJECT the candidate R6RS.

3. Reasons For Rejection

The steering committee requires that votes to reject the candidate be
accompanied by an explanation. My five reasons are given in this

3.1. Implicit mantissa widths

Section 4.2.8 of the candidate R6RS requires

   If x is an external representation of an inexact real number object
   that contains no vertical bar, then its numerical value should be
   computed as though it had a mantissa width of 53 or more.

Such implicit mantissa widths have not been justified in the rationale
or in discussions on the r6rs-discuss mailing list. It is not clear what
problem they solve.

The use of 'should' indicates that this is a recommendation. As such,
this does nothing to solve problems of incompatibilities between

On the other hand, it is simultaneously harmless and dangerous. Harmless
because the 'or more' implies that the value might be calculated in
infinite precision (i.e., exactly) and dangerous because it permits
double rounding (e.g., if the implementation would represent the result
using an IEEE double-precision format and the value is subnormal or if
the implementation would represent the result using an IEEE
single-precision format).

3.2 No Rounding Mode for Mantissa Widths

The candidate R6RS does not specify whether 0.75|1 should round to 0.5
or 1.0. This makes the mantissa widths unportable between

3.3 Explicit Mantissa Widths

Two reasons have been given for including explicit mantissa widths. Will
Clinger [1] stated:

   The |p notation is a replacement for the # notation that the R5RS used
   for nonsignificant digits. One of the things we learned from this
   process is that many Scheme programmers, perhaps even a majority, and
   apparently including several implementors, were interpreting # to mean
   5 rather than 0. That doesn't work, because it makes the numerical
   value depend upon the number of trailing #s, which are supposed to be

   We also learned that hardly anyone is using the R5RS notation.

Mike Sperber [2] stated:

   The way we have it now (I hope) at least gives implementations a
   chance to exactly represent binary floating-point numbers on output in
   external representations.

I note that these justifications are in apparent conflict. One suggests
that the |p notation is supposed to be an indicator of less precision
and the other suggests that the same notation is supposed to be an
indicator of a more precision.

I would suggest that the |p notation goes against the guiding principle
that 'programming languages should be designed not by piling feature on
top of feature, but by removing the weaknesses and restrictions that
make additional features appear necessary.' I would suggest:

   Continuing to use # to indicate imprecision, but tightening up the
   definition so that it is clear that it is to be interpreted as 0 and
   not 5. Alternatively, since 'hardly anyone is using' this notation,
   eliminate it.

   Extend the lexical syntax of inexact numbers to allow mantissas to be
   read and written in binary, octal, decimal, and hexadecimal. (An
   ambiguity in the syntax for non-decimals could be required by
   requiring a point at the end of the number or immediately before the
   exponent so, #x0e0 is an exact integer not an inexact zero whereas
   #x0. and #x0.e0 are inexact zeros.) The number->string procedure
   should also be extended to allow for non-decimal radixes for inexact

3.4 Records

Andre van Tonder [3] and Will Clinger [4] have pointed out an
incompatibility between the procedural and syntactic record layers. I
would like to see this issue discussed and, if possible, solved.

3.5 Library Versions

I am completely unconvinced by the need to embed library versions in
import specifications. I might support a means to label libraries with
versions and to make that information available to importing programs or
libraries at run-time (e.g., so they can abort if version X.Y of a
certain library is imported). However, in general I believe that
matching library versions should be solved outside of the language.

4 Other Issues

In this section I describe two issues which in themselves are not
reasons to reject the candidate R6RS, but which I find very

4.1 No Characters Beyond Unicode

Tom Lord [5] and John Cowan [6] have suggested that implementations be
allowed to support characters beyond Unicode. I support this suggestion.

4.2 Inappropriate Syntax

I am uncomfortable with the implementation of file-options, buffer-mode,
etc., as syntax rather than procedure.

[1] http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/003049.html
[2] Private email.
[3] http://lists.r6rs.org/pipermail/r6rs-discuss/2007-July/003080.html
[4] http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002825.html
[5] http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002863.html
[6] http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002878.html

Name: Alex Shinn
Location: Tokyo, Japan

Mail: alexshinn@gmail.com
Web: http://synthcode.com/
Ratify: NO

'Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary.'  This is the first sentence in
the introduction to RnRS for a reason.  It is the heart of what Scheme
is - a powerful general purpose programming language expressed with
just a few primitives.  As with any other good idea, it can be taken
to an absurd extreme, and there's more than a little room for leeway
in its interpretation, but the R6RS draft is so far removed from the
idea that it destroys the whole spirit of the language.

To be clear, I don't mind the large report, and am in fact happy that
a large selection of standard libraries was included.  What I object
to is the fact that these libraries are not built on simple
primitives, but many of them are in fact incompatible extensions to
the language, and features which imply core semantic changes.  The
R6RS draft has piled feature on top of feature with no attempt to
minimize.  There are many minor points to the draft I dislike that I
won't bother to mention - below I list only those issues which I
consider the most egregious.

* Identifier syntax.  Anything done with identifier syntax can be done
  with normal syntax, replacing X and (SET! X Y) with (X) and (X Y) or
  similar.  Thus this is purely syntactic sugar.  It's an interesting
  idea, with the intent of making pseudo-variables, but at the same
  time complicates the semantics of the language.  Identifiers may no
  longer be simple variable references, making code potentially more
  difficult to read.  Moreover, it weakens every macro in the entire
  language by removing knowledge about the language the macros are

  For example, the simplest implementation of the LET-OPTIONALS* macro
  used in many SRFI implementations I'm aware of is the following:

    (define-syntax let-optionals*
      (syntax-rules ()
        ((_ opt-ls () body ...)
         (let () body ...))
        ((_ (expr ...) vars body ...)
         (let ((tmp (expr ...)))
           (let-optionals* tmp vars body ...)))
        ((_ tmp ((var default) . rest) body ...)
         (let ((var (if (pair? tmp) (car tmp) default))
               (tmp2 (if (pair? tmp) (cdr tmp) '())))
           (let-optionals* tmp2 rest body ...)))

  This takes advantage of the fact that only parenthetical expressions
  need to be bound to temporary variables.  With identifier syntax,
  this is no longer true, and the above macro cannot even be written
  without helper macros or artificial pattern literals.

  This is a complication and inconvenience, but there are workarounds.
  There are other macros, however, such as the FAST-MATH macro at


  which are no longer even feasible.  The introduction of identifier
  syntax makes it impossible to write this kind of macro.

  Identifier syntax is a cute gimmick but is seldom used, and no one
  is clamoring for it to write portable code.  For the weaknesses it
  introduces, to make it a required feature of every Scheme
  implementation is absurd.

* SYNTAX-CASE.  Almost everyone wants low-level and unhygienic macros,
  but SYNTAX-CASE is an unfortunate choice of systems.  Both syntactic
  closures and explicit renaming macros are older, and are simpler and
  more in the spirit of Scheme.  SYNTAX-CASE provides a bizarre mix of
  low-level macros with high-level pattern matching, but a true
  low-level system should be orthogonal to such matching, allowing the
  programmer his choice of pattern matching or other utilities.

* `_' and `...' patterns.  It's unfortunate that R5RS macros can't
  match `...' as a literal in templates, but with the same restriction
  on `_' many existing macros will break, and moreover they have no
  easy workaround, requiring otherwise simple pattern matching macros
  to be rewritten in much longer and more convoluted low-level code.
  Simply allowing these as pattern literals solves the issue without
  introducing any new issues or ambiguities, and this was even
  suggested on the list but was ignored.

* Versioning in modules.  This is just premature.  There are a lot of
  different possible ways of handle the problem of library versions,
  and they need more exploration before standardization.  Everything
  done with versions in the current draft could be added in a
  backwards compatible manner in future drafts.

* Unicode.  Scheme has been around for a long time, and has seen many
  encodings come and go - there's no reason to bind it to a single
  encoding forever.  An appendix or separate document(s) specifying
  behavior for Unicode-based implementations could always be written
  for compatibility.

** Normalization forms.  STRING-NORMALIZE-NFD and the other three
   normalization procedures handle normalization at the wrong level.
   It's inherently an encoding issue, and is best treated as such.
   Providing this functionality at the string level forbids the
   implementation strategy of keeping all strings in the same
   normalization form - a very appealing strategy on many levels.

** O(1) string access.  This suggests all Schemes to use UCS-4
   character vectors for their string representation, discouraging the
   use of alternate representations such as UTF-8 and ropes or trees.

** Character-level case mappings.  Case in Unicode is a string-level
   concept - providing case utilities at the character level
   encourages programmers to write broken algorithms.

* I/O.  The I/O system was totally rewritten for no reason, and all
  aspects of it controlled with gratuitous syntactic forms - second
  class forms which discourage high-level procedures.

* Enumerations.  There's simply no reason for this, since Scheme has
  traditionally used symbols for the same purpose.  The one place
  where enumerations are truly required would be in an FFI, but the
  R6RS draft provides no FFI, and the enumerations provided would be
  insufficient for any FFI since they don't even let you override the
  integer values of individual symbols.

* Exceptions.  The exception system is far too large and
  over-specified.  Exceptional situations should be treated as such,
  and implementations should be free to experiment with extensions in
  these areas.

For these and other reasons I feel I have no choice but to vote
against ratification of the current R6RS draft.  The extent of the
change is so great I feel the draft can only be considered a new Lisp
dialect - the name `Scheme' does not suit it.

Name: Andre van Tonder
Location: Plettenbergbaai, South Africa

Ratify: NO
IMPORT LEVELS: The draft does not specify how to write portable
libraries that define or use macros with literals.  In particular,
the draft does not say whether uses of literals such as DEFINE,
ELSE, ellipses, and so on (in other words, the arguments of
free-identifier=? - when the comparison succeeds) count as references
for level checking.  Thus, users will be forced to resort to cargo-cult
programming in the hope that their code will be portable.

RECORDS:  I think the constructor-related parts of the syntactic
record layer and of the procedural layer are bewilderingly complex.
The custom constructor design is a good example of premature
generalization and piling feature upon feature, and since
their current API adversely affects other aspects, such as
modularity, of the design, as discussed on the list by Will
Clinger and myself, I believe it would be better to drop custom
constructors completely unless a simpler and better design can
be agreed on.  Such a design may be better left for a future SRFI.
Only a minority of record applications use custom constructors,
and these can always be expressed in terms of standard constructors
(we have libraries for hiding unexposed names from the client if necessary).
By the way, I do not think inheritance makes custom constructors necessary
in the base API, since users can easily roll the current
custom constructor functionality themselves without, I believe,
loss of performance or modularity.

LIBRARY VERSIONING:  I do not think that versioning information
should be in source code.  Also, the version reference syntax is
very complex and rather ugly.

ENUMERATIONS:  I cannot reconcile the presence of this library with
the philosophy of prior Scheme reports or with the r6rs mandate.  It seems
an example of premature generalization and piling feature upon feature.
I would prefer that it be dropped completely and left for a future SRFI
if enough people feel the need for it.

SET!: There is no way of importing set! for a single level.  This limits
the languages that a library designer can create.  I would suggest the
addition of a library (rnrs mutation) that exports only set! for level 0.
The (rnrs base) library can still export set! for levels 0 and 1 if desired.

LIBRARY INSTANTIATION:  The draft links library instantiation and
visitation not to import clauses, but instead to the presence of
identifier references in the client, and provides no guarantee of
instantiation otherwise.  Again, I worry that this may force users
to resort to cargo-cult-like programming (such as inserting otherwise
unnecessary variable or macro references in client code whose only
purpose is to force an instantiation or visitation) in an attempt
to ensure portability.  I would urge instantiation and visitation to
be guaranteed at least for the declared import phases (this should be
compatible with both explicit and implicit phasing models).

CONDITIONS:  Although the conditions API has seen improvement, I worry
that the division into simple and compound conditions, along with the
infrastructure required to manipulate these, is overly complex and
may be awkward to use in practice.  I would love to see a simpler design -
perhaps something as simple as an alist-like object may work quite well
and allow the current plethora of types to be replaced by properties


I do not consider the following objections dealbreakers, but I would like
to list them for the record:

SYNTAX-CASE:  The description of the mark-antimark algorithm significantly
lengthens and increases the complexity of this chapter.  It is hard for
me to understand despite being an implementor (granted, I use a different
algorithm).  The draft could be simplified by cutting this operational
description, especially since this is not the only algorithm, or even
(to me) the simplest algorithm for implementing hygiene.  A more
declarative description in the spirit of r5rs, as already given in
the introductory paragraphs of the draft section on hygiene
(perhaps with some small refinements and examples), already says it
all and could make this chapter considerably cleaner and shorter.

COMPOSITE LIBRARY:  I do not think (rnrs) should export
define-syntax and let[rec]-syntax for level 1, or syntax-rules for level 0.
In the context of the (rnrs) import, there is nothing one can do with these
bindings at those levels.

Name: Arto Bendiken
Location: Marbella, Spain

Mail: arto.bendiken@gmail.com
Web: http://bendiken.net/
Ratify: NO

Deliberating on the latest R5.97RS draft I find much that is  
agreeable about it, and it would be tempting to vote for its  
ratification. Indeed if but the programming language described  
therein would be named anything else than Scheme, it might seem the  
promising start of a practical and useful modern Lisp dialect.

Yet as the R5.97RS main and library reports still read today, the  
resulting language is most definitely not Scheme. My primary issue  
with the draft is that it betrays the spirit of its very own opening  
paragraph: 'Programming languages should be designed not by piling  
feature on top of feature, but by removing the weaknesses and  
restrictions that make additional features appear necessary.'

I should very much hope that paragraph will never be removed in  
future RnRS reports! Evaluating the rest of the main and library  
report against that principle, I think it stands out that the draft  
has simply suffered considerable feature creep and is vastly  
overspecified and overcomplex. In a word, it is too ambitious (or  
presumptuous, depending on your point of view).

I'm convinced the draft as it stands would derail Scheme, in the  
sense of putting the language on a course that it is unlikely could  
be easily corrected through later RnRS iterations. Thus I must at  
this time, with apologies to the editors, vote against ratification  
and hope that there will be enough dissenting voices to reopen the  
editorial process.

If the vote concerned only the main report in something not too far  
from its present form, ratification would not be an unfeasible  
prospect; and this despite the report having almost doubled in size.  
I do share others' misgivings on issues such as requiring the full  
numeric tower and chaining Scheme at the hip to Unicode; still, the  
main report all in all appears decent, and a standardized library  
definition facility, even if the current proposal seems rather  
overcomplex, would be a most important practical benefit provided by  
core R6RS.

However, the proposed standard library report is simply unacceptable.  
Not only does it gratuitously eschew important and widely-used  
existing SRFIs (such as the SRFI-1 list library, and SRFI-69 hash  
tables) in favor of its equivalent incompatible functionality, but  
one must ask why features such as, say, byte vectors, enumerations  
and hash tables should even be included in the RnRS reports in the  
first place?

The desire for a standard library is widespread, both for reasons of  
portability and practicability, but I think it is clear that when it  
comes to library functionality, the SRFI process has proven itself  
and works better than the committee process being voted on here.  
Attempting to evolve a standard library through the rightly slow- 
moving RnRS process seems to me shortsighted and counterproductive in  
the long run.

Thus, I consider the standard library report largely superfluous and  
indeed harmful. Instead of attempting to set in stone a  
controversially large standard library with the RnRS process, I  
believe the R6RS committee should strictly confine itself to the core  
language only, and fully embrace the SRFI process for the  
standardization and dissemination of all non-essential library features.

Name: Aubrey Jaffer
Location: Boston, MA, USA

Affiliation: ClearMethods Inc.
Mail: agj@alum.mit.edu
Web: http://swiss.csail.mit.edu/~jaffer
Ratify: NO

There are many flawed aspects of R5.97RS, which time does not permit
me to cover.  I will describe three.


In the R5.97RS introduction:

  Scheme demonstrates that a very small number of rules for forming
  expressions, with no restrictions on how they are composed, suffice
  to form a practical and efficient programming language that is
  flexible enough to support most of the major programming paradigms
  in use today.

This was true of R3RS and R4RS, but not for R5RS and R5.97RS.  In R3RS
and R4RS there were a small number of rules for forming expressions:

  LET*, LETREC, DO, DELAY, QUASIQUOTE, and combinations.

I have 70,000 lines of mathematical, scientific, engineering,
database, and scripting software written in (R4RS) Scheme showing that
this small number of rules is "flexible enough to support most of the
major programming paradigms in use today."

One reason that this large multi-author corpus of (free software)
Scheme code can be actively developed and maintained is because R4RS
code is very readable.  In a R4RS compliant file, it is easy to see
which lists are expressions which might be evaluated; there are no new
syntactic tokens which can be mistaken for identifiers.  The use of
LAMBDA in arguments to procedures establishes binding scope, no matter
what those procedures do.

The significance of this achievement by R4RS is not widely
appreciated.  Procedure are sufficient to create nearly any new
features.  Even new control features do not require new syntax.  EVAL,

In the R5RS introduction:

  More recently, Scheme became the first programming language to
  support hygienic macros, which permit the syntax of a
  block-structured language to be extended in a consistent and
  reliable manner.

Extending the syntax would be desirable if Scheme's "small number of
rules" were *not* sufficient "to form a practical and efficient
programming language ...".  But SLIB and other softwares show that
R4RS is sufficient.

The effect of adding macros to Scheme has been the proliferation of
mutually incomprehensible language dialects.  We have seen the growth
of "convenience" macros like WHENNOT and UNLESS, use of macros as a
substitute for compiler optimization, and use of macros to avoid using
symbols as tokens.  None of these uses increases the expressive power
of the language.

In a reusable software world, the use of incompatible dialects is
detrimental; it is only through documenting, publishing, and
deliberating, say in a SRFI, that new forms should be adopted into
that "very small number of rules for forming expressions".


Computations have been organized into multidimensional arrays for over
200 years.  Applications for multi-dimensional arrays are widespread
and continue to arise.  Computer graphics and imaging, whether vector
or raster based, use arrays.  A general-purpose computer language
without multidimensional arrays is an oxymoron.

Although multidimensional arrays are the subject of SRFI-25, SRFI-47,
SRFI-58, and SRFI-63, and portably supported by SLIB, search of
http://www.r6rs.org/r6rs-editors/ finds nothing to indicate that the
editors ever considered their inclusion in R6RS.

Can R5.97R Scheme be extended to support SRFI-63 arrays?


SRFI-63 redefines EQUAL? to work on arrays.  But in the R5.97RS module
system, a SRFI-63 library exporting EQUAL? will conflict with the RNRS
language export of the same name.  Thus any import of the array
library (and there are many in SLIB) will require that EQUAL? be
excluded from the import of RNRS.

Thus the R5.97RS library mechanism fails to be modular; users must
know and exclude from modules any exported redefinitions, whether or
not they use those identifiers!

This is more than an inconvenience.  R5.97RS prevents the sort of
language extensions which are a hallmark of LISPs.  Consider SLIB's
COMMUTATIVE-RING module, which captures and redefines *, +, -, /, and
ZERO? to work on expressions:

  (require 'commutative-ring)
  (set! *ruleset* (combined-rulesets distribute* distribute/))
  (define a 'a)
  (define z 'z)

  (* (+ a b) (- a b))  ==>  (- (^ a 2) (^ b 2))

  (require 'determinant)

  (determinant '#2A((a b c) (d e f) (g h i)))  ==>
     (- (+ (* a e i) (* b f g) (* c d h)) (* a f h) (* b d i) (* c e g))

In R5.97RS, the DETERMINANT module bindings for *, +, -, and / would
be unaffected by the COMMUTATIVE-RING extension.  Even creating a new
language binding to supplant RNRS is no help without modifying the
source code of the DETERMINANT module.

The R5.97RS library system has significantly reduced the expressive
power of Scheme; it is no longer possible to extend built-in
procedures to new types in a modular fashion.


The framework to extend R4RS and R5RS (through redefinition) made it
possible to provide those features that Scheme lacked in a portable
and modular fashion.  R5.97RS not only lacks the multidimensional
arrays essential to my work, it has removed the means for remediation
of its deficiencies.

Name: Bakul Shah
Location: Los Altos, CA, USA

Ratify: NO

- Requiring the full numeric tower works against using Scheme 
  in smaller environments such as embedded systems.

- Procedures such as div0-and-mod0, exact-integer-sqrt simply 
  do not belong in a base language.  In fact a lot of the numerical
  procedures belong in a library.  It is perfectly meaningful to say
  that if a specific library is implemented, it must meet the 
  entire spec. but *all* libraries must be optional in a base
  language and a base language implemener *does not* have to provide
  all libraries.  Even C does this!  Surely, one of the rationale
  for Scheme was minimalism?

- R6RS is not good enough for commericial usage since it lacks a
  FFI to interface it with libraries implented in C/C++ (such 
  as system libraries, graphics etc).  And it specifies too 
  much for an experimental language.  Neither fish nor fowl.

- I would have preferred R6RS to be *smaller* than R5RS, where
  some of the required features get moved to optional.

Name: Barak A. Pearlmutter
Location: Maynooth, Co. Kildare, Ireland

Affiliation: Hamilton Institute, National University of Ireland Maynooth
Mail: barak@cs.nuim.ie
Web: http://www.bcl.hamilton.ie/~barak/
Ratify: NO
When this process started, I expected to reluctantly vote for
approval.  However the discussion has been very illuminating, and the
arguments against ratification have been both cogent and convincing,
while those in favour have, at least to my mind, been less so.

Here are the arguments that convinced me.  Some are due to an
excellent post by Alex Shinn dated 29-May-2007, while others are
distilled from posts by David Rush and Jeffrey Mark Siskind.

First, there is the question of why we want or need an Official Scheme
Standard, and what the goal of the "RnRS process" should be.  It seems
to me that, broadly speaking, the draft R6RS has the goal of making
Scheme be like C or perl: a workable programming language like other
programming languages.  This seems reasonable on its face, but Scheme
has survived for a long time by not being a programming language like
others, but rather by being an oddball: minimally specified, usable
for real-world programming only by using numerous
implementation-specific features, but ideal for teaching and research.
Scheme is the defacto lingua-franca for programming language theory.
R6RS and its associated mindset flies directly in the face of Scheme's
historic strengths, and to my mind risks diluting them.  If this were
to occur it would be a disaster.

In other words, it is not clear to me that the draft R6RS is moving
Scheme in an appropriate direction.

Second, it is not clear to me that the draft R6RS even specifies the
right things to make Scheme industrial strength.  This argument was
made quite forcefully by people who actually do use Scheme in
real-world settings.

Third, the draft R6RS contains many features that are highly complex
to specify and that are quite un-lispy.  The enum stuff comes to mind.
Records.  The exception handling system.  Symbol macros.  Unicode
enshrined.  Each is individually motivated, but all together we end up
with a very large ball of mud.  The size of this ball directly impairs
one of Scheme's important features from an industrial perspective: its
role as a small language suitable for automatic program transformation
and other PLT sorts of techniques.

To sum up: I have come to the conclusion that ratification of the
draft R6RS will not be healthy for the Scheme community.  This draft,
and the process behind it, puts the mindset of the community at risk,
and is moreover unlikely to achieve its intended effect of industrial

For these reasons, I have been reluctantly dragged into a negative

Name: Brad Lucier
Location: West Lafayette, IN, USA

Affiliation: Purdue University
Web: http://www.math.purdue.edu/~lucier/
Ratify: NO

The following is not as polished as I'd like it to be, sorry.

Most of my codes have the following features:

1.  Homogeneous numeric vectors.
2.  Various I/O features (read/write pgm/ppm/... files, open tcp  
sockets, ..
3.  Unsafe arithmetic/list operations/...

The standard does not explicitly help me in these areas.  I'll comment a
bit more.

Re: Unsafe arithmetic and other operations.

I understand that draft does not address these issues; that is fine.

Re: Homogenous numeric vectors.

The suggestion is made in the rationale that bytevectors plus sealed
and opaque types can lead to efficient implementations of homogeneous
vector types.  To my mind, this assumes the existence of a "suitably smart compiler", and I no longer believe in such a thing.  I appreciate
Will Clinger's attempts to explain how various features in the proposed
draft (including this one) could be implemented efficiently, but I don't
think that these efficient implementation of specific features will
be found in most R6RS systems.  I've participated (mainly as an  
in compiler development (gcc and gambit), and there are a lot of
considerations that people bring to the table; a fancy implementation
of a specific feature that is nearly trivial to implement as a
primitive (homogeneous numeric vectors) is going to be hard to get to
the top of a Scheme implementer's priorities.

The parts of the proposal that I most object to are bytevectors and
the I/O library.  As the draft explains, these two features are
intertwined.  I think both of them are ad hoc, having a plethora of
related procedures that still do not cover the facilities offered by
other R5RS I/O extensions in existing Scheme systems.

The fact that bytevectors are, by their nature, type aliasing
nightmares is too lightly ignored in the draft.  Making these
the basic implementation strategy of homogenous vectors makes it
harder for Scheme systems that compile to C for portability
to implement homogeneous vectors efficiently, due to the C
aliasing rules.  (The authors of
the draft clearly had certain implementation strategies in mind
when they inserted or deleted various features into the draft;
in this case I think their estimate of the affect of this feature
was incorrect.)  And this situation
does not lead to portable code.  (And, BTW, IEEE-754 does *not*
specify the bit patterns for single- and double-precision
floating-point numbers in a way that this report seems to think
can be exploited in bytevectors.)

I tried to go over some of my own codes to see if the changes in the
I/O system would allow me to do what I wanted to do inside R6RS,
either (what I would consider) reasonably, or at all.  The answer
generally was no.  I consider the proposed I/O system and
bytevectors to be a solution to problems that are nowhere near as
important to me as they appear to the editors of the draft; at
the same time the draft doesn't offer solutions to the problems
I find in my code.  I'm stating this in a very personal way so
as not to claim universality for my perspectives or needs, but
I think my concerns are valid.

I consider the proposed bytevectors and I/O large parts of the
draft that would be difficult or impossible to fix in R7RS,
so I vote no.

Name: Brian Jaress
Location: Honolulu, HI, USA

Web: http://brian-jaress.livejournal.com
Ratify: NO
Although my initial impression of the draft was mildly positive, after
looking it over more thoroughly I am voting against ratification.  My
vote is based on my overall impression of the draft, but here are some
illustrative examples of particular things I don't like about it:

Fist, the problem of two record systems that don't quite work together.
This was raised by Will Clinger, most recently in his essay "Fixing the
Syntactic Record Layer"

Second, the fact that you cannot simply take a record value and access
one of its fields by name.  I explained my problem with that on the
mailing list
None of the explanations given for this in the rationale, the mailing
list, or the srfi discussions satisfy me.  (And the only direct reply
seemed to misunderstand the example -- we want a container that requires
certain behavior of the values it contains while not requiring that they
be on an approved list or inherit from the same ancestor.  Importing the
accessors of each type of value we wish to contain makes the container's
import list the approved list.)

Third, the condition system with its simple conditions and compound
conditions.  After reading through this part of the specification and
disliking it, I found a reasonable counterproposal on the mailing list
It was rejected with a statement that it conflicted with other decisions
of the editors and did not appear to be different in any other way.  (It
is, however quite different.  It makes all condition types record types,
eliminating the need for almost everything in section 7.2, and it makes
it much easier to handle an exception by supplementing the condition
with more information and re-raising it.)

Those three are just illustrative examples.  I am casting my vote based
on my overall impression of r5.97rs: Too many things in the draft are
designed primarily to work around limitations imposed by other things in
the draft.

The explanation of the condition system in particular helped me
crystallize what I had felt while reading the draft.  It was yet another
explanation of the form "We must do X because we have decided to do Y
and Z."  Meanwhile, Y and Z are required by W, which is required by P
and Q, which we need because we have X and Y.  The editors are happy to
explain each feature by pointing to the features that require it (or at
least conflict with every alternative they are aware of) but don't seem
to have considered the glaring possibility that all are bad and that
this is why they are mutually forcing each other into a series of

The introduction to the draft still begins with, "Programming languages
should be designed not by piling feature on top of feature, but by
removing the weaknesses and restrictions that make additional features
appear necessary."  I feel I understand that principle much better now
that I have seen r5.97rs itself violate it.  If you start by planning to
add lots of features, add them in ways that introduce weaknesses and
restrictions, then refuse to remove or replace any of your additions as
a way of repairing the damage, you end up with a mess that piles
workaround on top of workaround and calls them features.

Name: Chris Hanson
Location: Cambridge, MA, USA

Affiliation: MIT
Web: http://swiss.csail.mit.edu/users/cph/
Ratify: NO
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

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.

Name: Christopher Dutchyn
Location: Saskatoon, Saskatchewan, Canada

Affiliation: Computer Science, University of Saskatchewan
Mail: dutchyn at cs.usask.ca
Web: http://www.cs.usask.ca/faculty/cjd032
Ratify: NO
I think it is pointless to ratify a Scheme standard that
doesn't hold true to the founding principles -- expressiveness and  
simplicity --
of Scheme.  The key benefit to me, portability derives from  
standardization; but
developers of significant compilers do not support this draft -- this
fractures the community and reduces the likelihood of portability.   
summarized it this way: this draft seems to nail down the (more-or- 
less) easy-to-
nail down things, and reduces the scope of solutions to the difficult  
without making substantial progress on them.

Name: Dan Muresan
Location: Bucharest, Romania

Web: http://alumnus.caltech.edu/~muresan/
Ratify: NO
Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses and
restrictions that make additional features appear necessary.

The R6RS draft strays far away from the simplicity that characterized
earlier versions of the report. As a result, the effort required to
implement a standard-compliant Scheme becomes much larger than before.
This will discouraging future implementors, endangering the diversity
that is one of Scheme's present strengths (there are Schemes running
in almost any imaginable environment -- embedded, desktop, in a
browser, on top of Java and Ocaml etc). Furthermore, because of this
complexity (as well as because R6RS is controversial)  many existing
implementations will choose not to support R6RS, thus splitting the
Scheme community and codebase (some authors will choose to write R6RS
code that will not be directly usable by those running R5RS-only

I believe that, given Scheme's present maturity, the proper way to
evolve and enhance the language is via SRFIs, which provide a more
democratic and less biased process, and which minimize the destructive
effect of poor design decisions.

Other reasons for which I do not believe the R6RS should be ratified
are: identifier macros, which make the job of code-walking macros much
more difficult (especially as there is no way to programatically
expand macros); the syntax-case macro system (even if relegated to the
standard library); the complex and over-specified exception system;
and immutable pairs, which may make optimization easier, but do not
fit at all with the practice and spirit of Lisp.

Name: David Haguenauer
Location: Montreal, QC, Canada

Mail: ml@kurokatta.org
Web: http://www.kurokatta.org/
Ratify: NO
It seems to me that, at 91 pages, the proposed
  Revised^6 Report would make Scheme something bigger than it should
  be. I think that this violates an important part of the spirit of
  Scheme, which is to keep the language small, so that learning and
  implementing it remains relatively easy. Yet the proposed Report, as
  far as I can tell, fails to address some criticisms that are more
  than likely in our day and age, such as the absence of network
  connection capabilities. If such features are to be omitted from the
  Report, why could not many other features be deemed "recommended
  yet optional", and grouped in a common library, that does not have
  to be a de jure standard? Other languages appear to live quite
  successfully with de facto standard libraries that are separate from
  the language description. One thing I definitely would not like is
  to have the R6RS be a widely-ignored standard, in the way that, many
  years after its publication, C99 has but very few implementations,
  none of them popular.

Name: David Rush
Location: Dublin, Ireland

Affiliation: Heureka Software Systems, Limited
Web: http://cyber-rush.org/drr/scheme
Ratify: NO

The shortest explanation for my dissatisfaction with the R6RS is that
it appears to have gone fairly far off-track. There are some things I
like in it, and would like to vote 'maybe' except for the core
structural issues that I see.

I have always felt that the brevity of the RnRS spec was one of it's
stringest points. Now, with R5.97, the document has expanded to cover 4
interrelated specifications - which would not be bad in and of itself,
but the documents seem heavily interdependent. Make no mistake about
it, I actually *wanted* the standard split into core and library
components, but I was looking at something rather closer to the SML
2000 split.

The library machinery; however, is quite nice and I would like to see
it preserved. In fact, it is the primary reason why I would like to
vote maybe or even yes. It specifies modularization in terms of
build processes, which is exactly the right level of abstraction. One
minor error though seems to be the in the definition of top-level
programs: it appears that only one import form is allowed for a
program, which will certainly be violated in an interactive
session. Perhaps I have missed the text which allows the REPL to
behave differently from a program - but I'm not sure that such a
behavior is actually desirable, anyway.

An example of where the library/core breakdown is inadequately
addressed is the persistence of DYNAMIC-WIND. It has been clearly
shown that DYNAMIC-WIND (and R5RS CALL/CC) is implementable in terms
of R4RS CALL/CC, but that the reverse is not true. Given the renaming
facilities available in the library system, it would seem *really*
obvious that R4RS CALL/CC should be in the core and R5RS' DYNAMIC-WIND
and CALL/CC should be a separate library.

I am quite ambivalent on the topic of exceptions and conditions. I
have found that the under-specification of R5RS in this area has
actually led me to write better and more comprehensive error handling
code. However; I have often wished for a better standardization of
error-handling procedures across implementations. The gripping hand
holds that the exception and condition-handling behavior is
insufficiently worked out. First of all, this functionality *should*
be part of the core specification - as is shown by the inclusion of a
section on exceptions in the formal semantics. Secondly, the
interaction of exceptions and continuations is not clear. It is clear
that someone has a notion of how it should all interact, but that does
not come out in the document.

This last issue is a definite showstopper and points out something
that I would very much like to see in the Scheme specification: a
solid model for asynchronous events. That alone would be justification
enough for R6RS, but it is sadly lacking. A sound asynchronous
semantics would enable more things than I can even begin to list at
this point.

I also feel that the approach to Unicode and non-ascii character sets
to also be immature. There are two areas of concern here: program text
and I/O. In Scheme the line between these two blurs because of the
traditional representations of programs as s-expressions. After
seeinng the example of Ruby, I am not convinced (in fact I have begun
to be unconvinced as Ruby had its origins in a non-english
environment) of the value of supporting unicode for program text. That
said, the capability of sexp read makes it hard to avoid. I will only
say that the addition of Unicode escapes is ugly to say the least.

I am actually moderately pleased with what I see in the I/O system
changes. I feel there is a fairly sound basis for extensions to
include non-blocking I/O and (dare I say it) interrupt-driven I/O.

Multiple-return values *still* has not been fixed. The most
straightforward solution is simply to make all continuations
multi-valued - or rather that apply a single-argument continuation to
multiple values results in the coercion of the actual arguments to
some list form. I hate to appeal to Ruby for examples of The Right
Thing, but this is a Ruby practice which does seem to work well in
practice *and* it would alleviate a major asymmetry in Scheme
continuation semantics.

It would actually be even better to eliminate multi-valued
continuations entirely, but that would be at the cost of breaking
existing code (SRFI code even). Personally I have shunned
call-with-values and use explicit CPS whenever I have multiple values
to return.

There are a number of other issues about which I have heard rumblings
from the more editorially involved and/or experienced implementors
which leave me very worried. While I have not been able to fully
evaluate their claims, I will state that I am in agreement with any
concerns which reduce the ability of compilers to optimize my
code. I am also quite concerned that there are gotchas waiting for
prospective implementors (I *do* intend to become one :) - the R5RS
spec was much clearer in that respect.

A petty irritant for me is the official sanction of square
brackets. Given the extensive training the my optical neural networks
have received, I find the use of square brackets ugly and unhelpful in
reading code. They create a very discordant visual rhythm and should
be summarily outlawed. Square brackets are a gross violation of the
LISP Party Ethic and offending implementors shall be required to
submit thorough self-criticism of their motivations and then will be
summarily shot. I really mean this.

Finally I will say that it is nice to have a 3-state vote, although
perhaps a continuous rating system would have been even better yet. I
am not happy enough with the R^(5.97)RS to vote 'yes', or even
'maybe', but I am not far from it. I suppose the fault is mine for not
engaging the process at an earlier date. Either way, my vote for the
current draft is: NO.

Name: Felix Winkelmann
Location: Göttingen, Germany

Ratify: NO

R6RS completely breaks with Scheme's traditional values of simplicity,
and throws in gratuitous assortments of needless features, while lacking
coherency and generally appearing to be thrown together in haste. R6RS is
controversial even among the R6RS editors, and tries to standardize insuffienct
compromise solutions for things that are better left unspecified.
R6RS is a misguided attempt to make Scheme more suitable for the mainstream,
but effectively does the very opposite by removing the assets that always
distinguished Scheme from other dialects: smallness and simplicity.

I feel not represented by the people that call themselves 'R6RS editors'.

This s-expr text format is idiotic.

What the heck do you mean with 'an explanation is mandatory'? Need a
refresher in democracy, folks?

Name: Guillaume Germain
Location: Montreal, Quebec, Canada

Mail: guillaume.germain@gmail.com
Web: http://toute.ca
Ratify: NO

I think an update to R5RS is needed, particularly to add a module
system.  Unfortunately, the current proposal doesn't simply add
what is missing to R5RS: it tries to do much more.

However we put it, the base library is a fundamental part of the
proposal.  But its design ignores a significant part of the SRFI
process, for example by being incompatible with SRFI-1.  It is also
big and gratuitously complicated.  The records, I/O and exceptions
are good examples of the unneeded complexity.

I'm against making Scheme a bloated and complicated language.
I think the current proposal doesn't respect the philosophy of

Name: Harold Ancell
Location: Joplin, MO, USA

Mail: R6RS-vote@ancell-ent.com
Web: http://ancell-ent.com/
Ratify: NO
For me the single most important aspect of R6RS is what I will refer
to as specifying a suitable system for "standardized portability":
portable programming for library and application developers who want
to move more easily beyond Scheme's solid established niches, while
not endangering the virtues of the language that support both these
niches and what we are trying to accomplish beyond them.

The core language is the crown jewel of Scheme, and most of us would
say the crown jewel of programming languages.  In its current
minimalist form, it is critical to Ivan Raikov's "holy grail of
high-performance scientific computing", and the work of many others.

But the failure of our community "to build a large collection of
shared libraries" (Ryan Rhodes Newton) must be addressed.  Or as
Arthur A. Gleckler put it:

  I want to help make sure that R6RS maintains the right balance
  between the diamond-like jewel Scheme has always been and the
  practical everyday programming language that we have always wanted
  Scheme to be.

The proposal took the tried and true approach of making a core
language definition, a library mechanism, and a set of standard
required libraries, and I approve of this.  It is the only approach I
can see that satisfies the needs of all the stakeholders.  If done
right, this approach does not have to compromise Scheme's current
strengths---in fact, this can profitably be used to reduce the size of
the core, while at the same time a few necessary things are added to
it, like exceptions.

While I appreciate the concerns of those who want to keep Scheme
minimalist, to the point that I am voting against ratification first
and foremost because this proposal does not satisfy them, I fail to
see how any considerations beyond hooks in the core for library
efficiency provide a compelling reason to not standardize it beyond
the core, for those who want to get work done beyond the domains a
minimalist core excels in.

The devil is in details, and that is where this proposal most
grievously fails, in the particulars of drawing the lines between the
core and its various libraries at various levels.

I therefore I pose this question: if the proposal is sufficiently bad
that it endangers what we've got in an effort to get something more,
why accept it?  It is rather common in this sort of effort to lose
what one has and thus never gain what is attempted.

It is better to reach *correctly* for something new, or as David Rush
in comp.lang.scheme put it "In RnRS, the middle 'R' means 'Report' and
initially reflected the common and agreed practices in the Scheme
community - this is a *retrospective* term and could never reflect the
bleeding edge of language innovation."

There is much good in this proposal; a lack of time and relevance to
the voting process prompts me to focus on only two specific issues
related to the all-important library mechanism that I caught on my
first reading of it, and that I found had prompted formal comments:

1. The reason for ABSOLUTELY prohibiting linking to multiple versions
of the same library per formal comment #130 is very weak.  Scheme and
the LISP family in general are incisive, powerful languages that give
their users great power that can be easily misused.

They are not "restraint" languages (e.g. Java), and the "potential for
confusion" here seems to be balanced by the information and control
the library system gives the user.  I am certain that situations as
outlined in the comment will occur and harm the efforts of developers,
if a sufficiently rich set of library implementations following the
standard's mechanism are developed---which is the motivation of
creating such a library mechanism in the first place.

Those of us who have plenty of scars from "DLLHell" are POWERFULLY
motivated to avoid anything like it, but this goes too far, too
against the grain.  This single problem's damage to the raison
d'etre of libraries and R6RS itself is a show stopper.

2. I feel that Scheme should accommodate the desires of library
writers to intermix definitions and expressions [insert usual
platitudes about needless restrictions---and how Scheme is perhaps
more than anything else a system for communicating to other
programmers...].  I found the response to formal comment #212 to be
singularly unimpressive: that this "might be more useful, but there is
no a priori reason to think so" is in frank contrast to the code
survey made to reply to formal comment #117.  The crowning touch of
the response's justification by how it might confuse a Java programmer
learning Scheme was for me the final nail in the coffin of R5.97RS.

What I'd like to see happen if the proposal is not ratified and the
community tries again for a R6RS:

It should be *in the direction* of previous revised reports in
requiring unanimous consent *for the core* (which includes the library
mechanism, but precious few libraries).  Therefore the process in the
future must continue to require super-majorities for core ratification
and maybe even greater ones than the current 60%---and that helps to
properly draw the line between it and the required standard libraries.

Library ratification does not need to be as strict: as long as they
are "acceptable" and have nothing dreadfully wrong with them, it is
better to have usable standards than no standards at all, and in
theory the SFRI process has allowed the community to discover what
works in practice and it worth standardizing.

Therefore if this proposed version of R6RS is not ratified (and even
if it is), I recommend serious consideration of separating the
standardization of the core and standard libraries.  They're different
beasts for sometimes different audiences.

As for what that next R6RS should be: it should define as absolutely
minimal a core as is reasonable, keeping all the good things in
R5.nnRS, especially exceptions (I think) and a requirement to
implement the full numeric tower.  Raising the bar for a minimally
compliant implementation is worth it for these features---but maybe
not Unicode per se, so that the embedded community is not overly taxed
by that requirement.

The above core will include a library mechanism like the proposed one
with the show stopper problems fixed.

Then a standard library set *with a reference implementation written
in pure Scheme using only the core language* (and other required
standard libraries).

Part of the required standard core will be hooks required by the above
standard libraries needed for minimal efficiency.

Implementors wishing compliance with the full standard need only
implement the core and ship the reference libraries with it.  They and
their users can write more efficient implementations of the standard
libraries that take advantage of their lower level extensions and
special capabilities as they see fit.

The core should be satisfactory to the "minimalists" as long as it is
not soiled by the additions and is not too "big" for them.

The total should be a satisfactory base for those who want do things
that would move well beyond what the core supplies.

(The above is mostly from a discussion in comp.lang.scheme.)

In the longer term, certain things should be added to the core, e.g.
I think that continuations should be extended to full first class
status, but it should become pretty stable pretty soon.  *Ideally*
there should be no major *changes* (e.g. case significance) to the
core after not many more RnRSs.

What I'll do if the proposal is ratified:

I will decide that we no longer live in an civilized age
( http://xkcd.com/297/ ), for official "Scheme" will have lost too
much of the elegance and correctness that has up to now defined it (I
didn't realize it at the time, but so did our parent community when
they standardized on Common Lisp, a harsh object lesson in language
stagnafication we would do well to remember).

There are many signs that ratification of this proposed standard will
shatter the Scheme community.  For many language implementors, the
position of the standard is akin to that of Glendower in Shakespeare's
King Henry the IV:

  I can call spirits from the vasty deep.

Because as Hotspur replied:

  Why, so can I, or so can any man; But will they come when you do
  call for them?

This standard if ratified cannot perforce move the entire community to
it.  Enough of the wrong things in the proposal can never be undone,
and it is very unlikely the splintering of the community that this
proposal will cause if ratified will ever be undone, precisely because
these wrong things cannot be undone.

The lead developer of my favorite Scheme implementation will not vote
in favor of this proposed standard, and I would not be at all
surprised if he and others fork off their own standard ... call it
"Uncommon Scheme".  And I think there will be more than enough people
going in this direction to make a community with critical mass,

That would be an truly unfortunate development, but while my most
important personal interests are best served by a widespread
acceptance of standardized portability, I cannot support it if it
destroys that which makes Scheme so attractive in the first place,
including the core upon which my other interests depend.

                                        - Harold

Name: Ivan Raikov
Location: Okinawa, Japan

Ratify: NO
I find that Scheme R5RS has become a convenient tool
 for research and education because it is small and elegant. Its
 orthogonal feature set invites experimentation with the
 language. Because of its small size, the programmer has to learn only
 a few fundamental principles in order to master it. Consequently,
 there is a proliferation of competing R5RS implementations, which
 puts Scheme in a unique position, as no other current programming
 language can claim it has fostered such a diverse software ecosystem.

I believe that the R6RS proposal is moving Scheme in a fundamentally
wrong direction.  It is my opinion that the Scheme community will
benefit far more by rejecting the R6RS proposal and continuing the
experimentation and innovation fostered by R5RS, than it would benefit
from any potential interoperability gained by a new and far-reaching

I believe that a high-level language based on lambda calculus must
permit precise formal algorithmic specifications of software systems
that are invariant on all possible hardware platforms, operating
systems, and that are independent of data formats, protocols and
standards. Historically, Scheme has fulfilled such a role, and it is
my opinion that any features that specify implementation details, as
opposed to formal semantics and abstract implementation requirements,
do not belong in the core language.

The SRFI process has evolved to be the universally accepted
standardization process for Scheme libraries, and R6RS must not
attempt to subvert it. Each library must undergo its own
standardization process.  If one wants a standardized Unicode Library 
for Scheme, then the proper way is to develop an SRFI for a Scheme
Unicode library and convince the implementors and users of existing
Scheme systems to adopt that SRFI.

However, the R6RS proposal demands a large set of extra libraries that
are not universally adopted by existing implementations.  It does not
include widely used and implemented SRFIs, such as SRFI-1, yet it
features SRFIs that impose very particular restrictions in fixnum
representations, it relies heavily on Unicode, which may evolve and
change as a standard, it imposes an imperative hashtable API, where
many Scheme implementations feature purely functional dictionary

If the core language is sufficiently minimal and well-thought-out, and
if the libraries are sufficiently high-level and general, the issues
of organization and interoperability can be left to the
implementations. A good language standard should support
interoperability, not impose it. 

Following is a list of R6RS proposal features that I consider
unnecessary and complicating the language:

1) Unicode

It is perhaps better to remove those features of R5RS that prohibit
Unicode implementation (such as char->integer and integer->char), and
relying on extended SRFI-13 and SRFI-14 for Unicode support.

If Unicode support is relegated to a library, the character and string
representations will not be rigidly coupled to the language
specification, and core Scheme will remain implementable on platforms
without Unicode support.

2) Byte-vectors

The core language must only include abstract vector type. Having
particular types of vector representations is precisely the domain of
SRFIs. The R6RS proposal byte vector syntax is not widely agreed upon,
and it requires two sets of vector procedures in the core language. 

3) Lists

SRFI-1 is a well-thought API, which is widely implemented and used in
the Scheme community. Yet the R6RS proposal uses incompatible names to
several SRFI-1 procedures. Although R6RS claims to emphasize the role
of the community, it seems that it is ignoring a previous community
effort, and puts future SRFI work in a questionable position.

4) Dictionaries & hash tables

The core specification must not mandate any particular standard for
dictionary structures, as the existing implementations vary widely in
APIs. A side effect free association list structure may be permitted,
but anything more sophisticated must be relegated to a library. 

5) Exceptions

The R5RS report used the phrase "an error is signaled" to indicate
that implementations must detect and report an error, without going
into specifics. In contrast, the R6RS proposal requires the signaling
of exceptions, and it goes further to propose a complex and very
specific hierarchy of exceptions. Once again, common practices in the
Scheme community are ignore, and instead of relying on the SRFI
process, exceptions are mandated in the core language.

6) Modules

The enforced phase separation in the module system described in the
R6RS proposal overspecifies the module system and disallows different
implementation strategies, thus prohibiting the Scheme community from
experimenting and innovating.

In addition, the module system becomes an obstacle to the use of
Scheme as a teaching language, because beginners now must deal with it
long before it can be explained to them why. Syntactically, library
descriptions need to be enclosed in an additional layer of
parentheses, as opposed to a single definition at the top of the file.

The versioning system is complex and not obviously necessary, or tried
in practice. Again, matters like these must be relegated to the SRFI

7) I/O

All but fundamental I/O primitives should be put in a library. As with
vectors, non-abstract operations do not belong in the core language. 

8) R5RS compatibility

The identifier macros in the R6RS proposal break R5RS compatibility by
eliminating a specific invariant on which R5RS programs and macros can
rely, namely that a reference to an identifier has no side effects.

With identifier macros as proposed for the R6RS, an identifier may not
actually be a variable reference, which can be confusing both for
programmers and for code analysis algorithms -- again obstructing
experimentation with compilers and language semantics.

In the few cases where identifier macros are useful, it is again
better to relegate them to a library. 

Name: Jay Reynolds Freeman
Location: Palo Alto, CA, USA

Mail: Jay_Reynolds_Freeman@mac.com
Web: http://web.mac.com/Jay_Reynolds_Freeman
Ratify: NO
The proposed R6 draft materials are almost four times as long as
the R5 report: That's scary in its own right, the more so because
the Scheme community relies in considerable part on the efforts of
individual developers, or small teams of developers, who have to
implement these reports -- or who would presumably like to do so
if it did not take forever.  I think the Scheme community would
be better served by a much smaller language, whose features included
the minimum necessary so that the language could easily be extended
by loading Scheme source code itself (and perhaps compiling it).
In that case, implementers could concentrate on getting a small
feature set correct and fast, feature-developers could work on
whatever enhancements they liked, and users could use such
enhancements as they chose.  Perhaps the community would eventually
settle on a standard group of libraries for common use (though not
everyone would have to use them); but such a development might
take a while.

The current thrust of Scheme development makes me worry that the
language will go the way of C++, which seems to have given rise
to a large variety of mutually nearly incomprehensible C++
dialects and programming styles, and to a great deal of
confusion about what the various features are supposed to do:
I don't know anyone who claims to understand the entire C++
language, and I _do_ know at least one product-development team
at a large computer company that will remain nameless here, who
are forbidden to use certain features of C++ because they are
allegedly so ill-defined that they behave substantially differently
in different widely-used implementations.

I don't want to see Scheme go that way, so I am voting against
the R5.97 draft.

-- Jay Reynolds Freeman
    http://web.mac.com/jay_reynolds_freeman (personal web site)

Name: Jeffrey Mark Siskind
Location: West Lafayette, IN, USA

Affiliation: School of ECE, Purdue University
Mail: qobi@purdue.edu
Web: http://www.ece.purdue.edu/~qobi
Ratify: NO
I have explained some of my sentiment in the following post to comp.lang.scheme
on 6 August 2007:

> Guys come on it is not as though Schemers are a bunch of stodgy old
> uptight conservative worry warts who aren't willing to experiment, is
> it?

> Scheme was an experiment, and the results were pretty good.

> How many people get things perfect on the first try? :)

It is precisely for this reason that some of us argue against standardization
efforts such as R5.97RS and R6RS. We want to experiment and innovate. And the
purpose of standardization is the exact opposite: to prevent experimentation
and innovation. The objective of standardization *is* to get it right on the
first try, to allow long term stability and interoperability, when the
benefits of such outweigh the benefits of innovation. It is my opinion that
the Scheme community will benefit far more from experimentation and innovation
by rejecting R5.97RS/R6RS that it would from any potential for
interoperability that it would afford. We are not an electric power
utility. Nor are we C.

I think most of the proponents of R5.97RS/R6RS confuse the desire for features
in the implementation that they use with desire for standardization. R5.97RS
should not be ratified as R6RS. That would be disasterous for the
community. But that should not prevent anybody from experimenting with any or
all of the features from R5.97RS in their favorite implementation.
I have explained some more of my sentiment in the following post that I have
prepared for comp.lang.scheme but have not yet sent:

There are fundamental flaws in your argument. I suspect that these flaws are
what motivate many of those who advocate adoption of R6RS.

 1. To the best of my knowledge there is only one vendor of Scheme
    implementations: Chez. What I mean by vendor is a person or organization
    that is paid by customers to maintain and develop the core of the
 2. To the best of my knowledge, there is only one community-supported Scheme
    implementation: Guile. What I mean by community supported is that there
    is a sustainable community distinct from the original implementor that
    actively maintains and develops the core of the implementation.

The vast majority of Scheme implementations are part time labors of love of a
single person or a small group that includes current and former graduate
students of a single person. While most such implementations are open source,
none has attracted an exogenous developer community. Many/most of such efforts
are motivated by the fact that such implementations are part of the
implementor's research program. For them, innovation is the driving force.
Satisfying a customer base is not.

Almost all of us in the Scheme community would love for Scheme to catch on in
the mainstream. We would love for there to be many profitable vendors selling
high-quality Scheme implementations. We would love for there to be a vibrant
open-source community that actively maintains and develops many high-quality
Scheme implementations. And we would love for there to be a large customer
base of real-world Scheme users that would create a demand for the above. Some
people believe that the only factor that prevents this from happening is
standardization (of a big language). Thus they advocate adoption of R6RS.

I think that there is a huge body of compelling historical evidence that this
belief is false. There are at least three prior efforts to standardize Lisp:
Common Lisp, IS Lisp, and EuLisp. All adopted standards that were essentially
supersets of the functionality of R6RS. At one time, there were numerous
profitable commercial vendors of Common Lisp implementations: Symbolics, LMI,
TI, Gold Hill, Chestnut Hill, Lucid, Harlequin, Franz, Xerox, MCL, ExperCommon
Lisp, Star Sapphire, IBCL, ... just to name a few. (There were others that I
can't remember at the moment.) And there were many noncommercial
implementations actively maintained and developed either by individuals or by
well funded research efforts: KCL, AKCL, GCL, CMULISP, CLISP, ... just to name
a few. (Again, there were many others that I can't remember at the moment.)
And there were many large mainstream companies that developed products that
relied on these implementations. That marketplace demand fueled the supply.

But that marketplace has essentially disappeared. Today there is only one
commercial vendor: Franz. And only one active community-supported development
effort: CMULISP.

I find it untenable to believe that standardization of R6RS with all of its
`real world' features will catalyze growth of a Scheme marketplace. What does
R6RS provide that the real-world needs that is not provided by Common Lisp?
(No, as much as I like call/cc and a single namespace, they do not fit the

Scheme occupies a unique niche. A research niche and an educational niche. It
is not a language. Not R6RS, not R5RS, not R4RS. It is an idea. Or a
collection of ideas. It is a framework. It is a way of thinking. It is a
mindset. All of this is embodied in an ever growing family of languages or
dialects, not a single language. It is a virus. It is the ultimate
programming-language virus. The cat is already out of the bag and there is no
way to get it back in. Once someone gets the mindset, they can implement their
own implementation, which is often a slightly different dialect. This has
happened hundreds if not thousands of times over. (Probably hundreds of
thousands or more if one counts all of the people doing homework for Scheme
courses.) This happens for Scheme in a way that it doesn't for any other
language. Scheme also has served as a testbed for innovative language ideas
more than any other language, either by fueling such innovation or by adopting
such innovation. I'm talking about the most major innovations of all of
computer science. Things like: scoping, nondeterminism, parallelism, lazy
evaluation, unification, constraint processing, stochastic computation,
quantum computation, automatic differentiation, genetic programming, types,
automated reasoning, ... just to name a few. Not crap like libraries, unicode,
FFIs, assembler escapes, bit twiddling, module systems, case sensitivity, ...

Before entertaining the standardization of a feature, I would need to see:

 1. Evidence that a sizable community of people need that feature and agree on
    the standardized spec. I won't be convinced by mere claims that a feature
    is needed because many people confuse desire with need. I need to see
    compelling evidence of actual need.
 2. Evidence that there is a need for many/most/all implementations to support
    that feature in the same way. Again, I won't be convinced by mere claims of
    such need. I need to see compelling evidence of actual need to run code
    unmodified in many/most/all implementations. And it must be the case that
    addressing all such standardization issues successfully allows such code
    that needs to be run in many/most/all implementations to actually do so.
    I.e., that there are no other limiting factors that prevent such and
    require code modification.

I have written Scheme code many hours a day essentially every day for the past
15 years. (And I did this in other dialects of Lisp for 11 years prior to
that. And I did this in other languages for 8 years prior to that.) Hundreds
of thousands of lines. Much of it runs on at least two Scheme implementations:
Scheme->C and Stalin. Almost all of it requires capabilities that are not
standardized in R4RS, R5RS, or R6RS. Things like operating system access, file
system access, network access, window-system access, camera access, microphone
access, speaker access, robot arm access, and access to millions of lines of
code written by many other people in many other languages. This is as
real-world as it gets. R6RS does nothing to help that. My extensive experience
is that I personally need nothing that R6RS adds over R4RS and many things that
it doesn't add.
Some of my sentiment is expressed in the following post to comp.lang.scheme by
David Rush on 9 August 2007:

On Aug 6, 4:59 pm, Steve Schafer <st...@fenestra.com> wrote:

> But if you're experimenting and innovating, then you do whatever. How
> does the existence of the language standard/building code impede you?

I don;t know if you recall the amount of grief given to certain high-
performance Scheme implementations  over their 'non-conformance'
issues. Some of those idiosyncracies were a clear outgrowth of
particular optimization experiments. And some of those experiments
were  based on very simple ideas and some on very complex ones - but
the implementors were continually lambasted for not conforming to
R5RS. And they even had the clearest documentation of their non-

I *used* these systems heavily because I was doing some very heavy
lifting with data mining jobs. I don't recall any  stupider debate
(except maybe #f/'()/nil :) than the ones about conformance issues -
but people seem to make a big deal about it anyway. The goal in R6RS
should be to make it easier to achieve conformance *and* easier to
experiment without getting the pedants' backs up. A good standards
document helps the documentation effort and frankly, R6RS achieves
none of the goals mentioned above.

There. I said it.

david rush
...knowing I will regret this in the morning :)
Some of my sentiment is expressed in the following post to comp.lang.scheme by
Aaron Hsu on 11 August 2007:

On 2007-08-11 15:14:34 -0500, Griff <gret...@gmail.com> said:

> That is what standards aim to do, make things easier.

In this particular case, though, it will likely create a schism between
the various scheme implementations, because it ignores the desires of
parts of the community, in order to cater to some others. Scheme can't
operate under the assumptions of one-size fits all, because the Scheme
community is naturally already heavily invested in areas where
divergence (to some degree) is encouraged. To attempt to change this
outlook, by forcing everyone into one single paradigm, will mean that
some Schemes are going to go for it, and others won't, so you'll end up
with wider divergence than before, and portable code writing will not
improve; the contrast will be greater.
Aaron Hsu <aaron....@sacrificumdeo.net>
Also, I think module systems in general, for all languages, not just Scheme,
and the proposed library system are really bad ideas, from a scientific and
technical perspective. But discussion of that will have to wait for a
technical paper.

Name: Jeffrey T. Read
Location: Portland, OR, USA

Mail: bitwize@gmail.com
Ratify: NO
The debate over the development and ratification of R6RS has been
characterized by the minimalists on one side, who want a Scheme standard
that continues the tradition of being a general, abstract, minimal yet
powerful language, hewing close to the lambda calculus and the natural
simplicity of Lisp; and the pragmatists on the other, who want a Scheme
standard that is comprehensive and readily used in software engineering
applications. These two camps may be considered the extreme endpoints of a
spectrum of thought concerning Scheme and its role in the
programming-language ecosystem. I daresay that I place myself much closer
to the minimalist camp than the pragmatist camp, and consider the
pragmatist turn that the proposed R6RS has taken to be not good for Scheme
in general.

Feynman once wrote, "What I cannot create I do not understand." A big part
of Scheme's appeal is the fact that it is a powerful, usable language based
on a very small core of abstractions, the implementation of which is easy
to create and hence, easy to understand. The proposed R6RS strays from this
tradition in several ways. While I welcome some additions, like bytevectors
and a library system, others, such as conditions and Unicode strings, have
warts resulting from arbitrary decisions, with cleaner and more general
abstractions obviously struggling below the surface to get out. Perhaps
worst of all, the operational semantics for the proposed R6RS is nowhere
near as clean and succinct as the denotational semantics for
R5RS. Considerations of their non-normativeness aside, the denotational
semantics presented, in a couple of pages, a clear formalization of the
basis of Scheme.

Furthermore, if you are in the pragmatist camp, the proposed R6RS does not
go far enough. Pragmatists want things like complete, pervasive object
systems; built-in support for concurrency; and beefy standard libraries
including most common OS and networking functions, having been spoilt on
such features from exposure to the likes of Common Lisp, Perl, Python, C#
and Java. As a pragmatic standard the proposed R6RS doesn't go nearly far
enough; its benefit is mainly in political issues, as a "step in the right
direction" for the Scheme community. Many of the problems that the proposed
report addresses have been addressed better by SRFIs to R5RS, with which
the report conflicts in subtle ways.

In short, I cannot in good faith vote to ratify a standard which
simultaneously breaks with the Scheme tradition to favor homogeneity and
software-engineering appeal and still doesn't go far enough towards
becoming a useful engineering tool. I would rather see a thousand more R5RS
implementations, each subtly different in implementing extensions to the
standard, than to see the standard for Scheme lose its place as an
approachable but extremely general kernel upon which to construct a
practical language implementation.

Name: John Nowak
Location: Sunnyside, NY, USA

Mail: john@johnnowak.com
Web: http://johnnowak.com
Ratify: NO
Scheme is not intended to be the most axiomatic language possible. For such
purposes, other languages exist. Accordingly, I am not necessarily opposed
to additions such as records or modules. Such additions could be very
beneficial and help improve Scheme in areas where it already excels.

That said, simplicity is one of Scheme's most critical features. I'm sure I
will not be the only one to do this, but I will quote the first sentence of
the introduction anyway: 'Programming languages should be designed not by
piling feature on top of feature, but by removing the weaknesses and
restrictions that make additional features appear necessary.'

The addition of Unicode is not in the spirit of Scheme. If one needs
Unicode, simply use an implementation with Unicode support. Scheme is a
language I expect to be around for many more decades, and tying it to
Unicode seems shortsighted.

One feature I particularly wanted to see was records. Unfortunately, I am
very unhappy with how the system turned out; it is simply far too
complicated. Solid critiques of the system have been given on the mailing
list and elsewhere so I won't rehash them here.

There are also a number of small annoyances in the draft: I/O is too
complex, partially due to Unicode; hash tables, while useful, are not
necessary (after all, other equally useful data structures were not added);
rules regarding things like square brackets should not exist, even in
non-normative appendices; WHEN and UNLESS forms should not be specified;
exceptions are an unfortunate (if understandable) addition; and so on.

The current draft is far from what I'd like it to be. There is no sense in
eliminating one of Scheme's most important features -- simplicity -- for
the sake of things like Unicode. After all, even with such additions, much
"real world" Scheme code will be far from portable given the lack of
standard POSIX libraries, a standard FFI, and so forth.

Scheme, thankfully, will never be the next Python. Therefore, future drafts
should shift focus to refining Scheme as it is; clarifying top-level
semantics is a good example. Additional features should be treated with
severe skepticism. As it stands now, Scheme is an amazing pedagogical
tool. It would be a shame to compromise that in any way.

Name: Jonathan Rees
Location: Cambridge, MA, USA

Affiliation: Creative Commons Corp.
Mail: jar297@mumble.net
Web: http://mumble.net/~jar/
Ratify: NO

A new language definition, composed by a new set of people with a new
technical style, a new poitical process, and a new set of goals, is a
good thing, but it needs a new name.  Simply as a matter of branding I
consider it confusing to recycle the 'Revised^N Report on the
Algorithmic Language Scheme' title - a joke that was tired years ago,
by the way - for something that is clearly not in the spirit of
previous Scheme reports, much less the Algol 60 report.  Public
understanding of the programming language literature is bad enough -
Scheme doesn't need this additional source of identity crisis.

The above consideration would be sufficient reason for me to be
disinclined to 'ratify.'  But I'll give some other reasons why I'm not
too happy with this report.

Assuming that the report will represent pressure on me to change how I
write programs and teach programming, I am vexed by the switch to case
sensitivity.  This incompatibility would require major changes to my
programs, is not to my taste, and seems gratuitous.  The loss of
brackets as an extensibility option is also a loss.

There are many technical problems with the report, none of which is in
itself a reason for me to vote no, but cumulatively they tell me that
either not enough time has been taken to produce a quality document,
or that the process for producing drafts is not one that is likely to
do so.  I would be happy to evaluate the document on its own terms,
but these terms are not stated clearly enough for me to know how.  For
example, I can't predict based on principles why assoc and memq (for
example) are exiled to 'libraries' without bringing along the equally
derivative append, string-for-each!, vector-map, and so on; the
library system fails to delineate a kernel, which I had thought was
one of its goals.  As another example, why would one aim to nail down
so many boundary conditions without also specifying order of argument
evaluation?  I could understand either aggressive underspecification
or aggressive specification, but this report's in-betweenness  
mystifies me.

I do not mean to single these issues out - there are many other
puzzling aspects. Each one may have a perfectly sound explanation,
but in combination they spell trouble.

The rationale document is a very welcome addition, by the way.  It is
unfortunate that it appeared at the end of the process leading to
the draft instead of the beginning.

The modern Scheme community needs to work on a sustainable process for
generating reports.  Although the change in goals has undoubtedly  
required many
changes to the language, and a consistent (such as it is) revision may
have required making many changes in concert, the jump from R5RS to
R6RS is too big for its users (implementors and other programmers) to
digest all at once, and has not set a good example for R7RS.  To make
sure we all continue communicating and learning from one another, the
revision process needs to be more open and incremental in the future,
I think.

Name: Jude Arnout Durieux
Location: Bamako, Mali

Affiliation: Private
Mail: At the org called biep, the address rrrs
Web: http://www.biep.org
Ratify: NO

  [Tired and isolated.. :-)]
  Scheme clearly needs some minimal extensions in order to become a
  generally practical programming language.  It also needs some cleaning up
  at the base.  But it has no place for creeping (or gallopping) featurism
  - the name Scheme should guarantee the well-thought-out, correct, in
  hindsight even obvious, decision.  All else should go under another name,
  lest Scheme loses its unique appeal (= selling point).

  Some examples:
  (1) Strings always were a bit sore in Scheme, with their manifestly-typed
  locations.  Instead of solving that, this draft adds bytevectors.
  Neither can contain variables in the right-hand side of a syntax rule -
  the kind of arbitrary restriction of which Scheme should be free.
  (2) The draft recognises libraries, a top-level and scripts, three
  variants of what is basically the same thing (see Queinnec&Padget:
  Modules, Macros and Lisp) - not the Scheme way.
  (3) Mr. Clinger's remarks on the record systems.

  So, by all means provide these things, but under its own (inferior)
  brand name.

Name: Marc Feeley
Location: Montreal, QC, Canada

Affiliation: Universite de Montreal
Mail: feeley at iro.umontreal.ca
Web: http://www.iro.umontreal.ca/~feeley
Ratify: NO

I am voting against ratification of the draft because the language it
specifies violates some of the fundamental design goals and principles
which are behind Scheme's fame and respect in the circle of
programming languages.  The proposed language is both too complex for
the user to grasp easily and too complex to implement.  One of R5RS
Scheme's strengths is that it can be implemented with minimal effort,
merely a few days for an experienced implementor.  Because of this
several implementations have come into existence whose collective
features cover a wide range of niches (platform, speed, size,
interoperability, debuggability, ...).  Among the over 50 existing
Scheme implementations I believe at most 5 will have the energy to
convert to the R6RS spec, and I fear that very few in the future will
have the courage to embark on developing new implementations.  The
Scheme community will fragment and Scheme innovation will slowly die.

It would be tedious to describe the detailed problems with the draft,
and others have pointed out many of them.  I will simply state some of
the ones which are most obvious to me.

1) One of Scheme's strengths is its dynamic nature and in particular
    the ability to be used interactively through a REPL.  The draft
    moves away from this by removing ``load'' and offering only a
    static linking model for programs.  The draft does not explain how
    this affects program development and debugging using a REPL, which
    is the bread-and-butter of a large number of Scheme users.

2) Several features specified in the draft have been tested in
    existing implementations of Scheme insufficiently to warrant
    inclusion in the standard.  Some features of the draft, such as the
    I/O system and records, are completely new and clearly suffer from
    feature creep.  The standard is not the place to experiment.  I do
    not think that R7RS can easily retract major features like these.
    A legitimate approach would be to use the SRFI process to introduce
    new features and APIs, to wait and see which SRFIs are adopted by
    users and implementors, and to standardize when there is a clear
    winner.  For most features the last step could be skipped if the
    SRFI process was combined with a package repository in the spirit
    of Snow.  This would remove the need for the whole ``Standard
    libraries'' document, and bring the language spec to a more
    palatable size.

3) The draft puts too much emphasis on performance.  Is R5RS Scheme so
    slow that we need to introduce into the standard immutable
    variables, fields, and pairs?  I am all for speed, but not at the
    expense of inconsistencies in the language design.  Immutability
    hinders debugging and ``live-repair'', and goes against the basic
    design principles of Scheme:

      Programming languages should be designed not by piling feature on
      top of feature, but by removing the weaknesses and
      **restrictions** that make additional features appear necessary.

    Given that the draft requires the full numeric tower and bignums,
    and that fixnum and flonum types have implementation dependent
    ranges, I see no need to require fixnum and flonum types in the
    standard.  They should be moved to a SRFI.

4) The syntax for libraries is just too complex.  Syntax-case is
    overkill.  This is another unfortunate instance of feature creep.
    Scheme needs a simple module system that can be grasped easily.
    Scheme can live with the R5RS hygienic macros for a while still.

Name: Nils M Holm
Location: Hemsbach, Heidelberg area, Germany

Web: http://t3x.org/nmh/
Ratify: NO

The gap between R5RS and the proposed R6RS is simply too big.
R6RS would make Scheme a different language, which is particularly
unfortunate because there would be alternatives.

(Just for the record: I am also opposed to Unicode in symbols for
 reasons that I will not outline here, because I could live with it,
 if the larger issue outlined below would be resolved.)

The principal reason for my ``no'' vote is entirely contained in the
first sentence of the introduction to every Scheme Report I have read
so far:

``Programming languages should be designed not by piling feature on
  top of feature, but by removing the weaknesses and restrictions that
  make additional features appear necessary.''

R6RS contradicts this principle by including a lot of features in the
language itself. Many of these features are certainly necessary in a
``real-world'' programming language, but these features are included at
the cost of simplicity and orthogonality. They are included arbitrarily
and not by applying the principle outlined at the beginning of the
Scheme Reports.

Of course, many of these features are useful and definitely should
be part of the standard, but rather than arbitrarily including them
in the language, the should be defined *on top of the language*.
Only features that are required in order to support the libraries
should be carefully added to the language itself. This approach would
lead to a ``core language'' and a set of ``extension libraries'' that
is implemented in terms of the core language. These libraries should
be optional extensions to the core language. This has been done before,
for example in Standard ML and ANS Forth.

This approach has several advantages:

- More libraries could easily be added at a later time without
  having to revise the core language too frequently.
- Implementors could decide which libraries they want to include
  and which they want to omit.
- Libraries would be exchangeable between implementation, allowing
  users of pure core languages implementations to use libraries of
  other implementors.
- Reference implementations could be included in the report or
  supplied as supplementary material.

The simplicity and elegance of Scheme has always attracted researchers
and teachers who were searching for a small, well-defined language. By
splitting the standard into the ``core language'' and a set of libraries,
the beauty of the language could be preserved *without* restricting its
use to research and education. People who want a small language could
just use the core, and people who want a big language could use the
libraries. Everybody wins, nobody loses. I think that this is a chance
that should not be passed up.


R5.97RS contains a lot of very, very good ideas. I am not really opposed
to any specific part of it (with the exception of Unicode in symbols). It
is the sum of its parts which leaves me no other choice than a ``no'' vote.

If the library part of R5.97RS was optional, and the language part
would be modelled in order to support the new libraries, I would have
voted ``yes''.

In case R5.97RS will not be adopted, please split the language into
a small and elegant core language and a set of optional extension
libraries, preferably implemented in the core language itself. I
know that modelling the core language would be some hard work, but
the reward would be a language that is both small and elegant and
ready for real-world programming at the same time.

Name: Onnie Lynn Winebarger
Location: Indianapolis, IN, USA

Ratify: NO

   I am voting against the adoption of the R6RS draft candidate.  It mouths
the words:

     Programming languages should be designed not by piling feature on top
     of feature, but by removing the weaknesses and restrictions that make
     additional features appear necessary. Scheme demonstrates that a very
     small number of rules for forming expressions, with no restrictions on
     how they are composed, suffice to form a practical and efficient
     programming language that is flexible enough to support most of the
     major programming paradigms in use today.

but fails to honor them.  The innovations of the draft fall into
essentially two pieces.  The first is a syntax for defining and importing
identifiers from "top-level libraries".  The second is the addition,
through the library mechanism, of a variety of data types and attendant
functional and/or syntactic interfaces.  While both of these are useful for
general programming, I do not believe either of them deserve a place in the
Scheme language standard.  Finally, the draft utterly neglects the notions
of "top-level program" and "top-level environment", which are absolutely
fundamental to Scheme as a language and a system.

   Scheme historically embodies the implementation of the definitional
interpreters of Reynolds using the CPS transform.  A major theme in the
development of Scheme and its compilation was that the inefficient
implementation of procedures in languages of the time were due to being
overly committed to particular representations of control and
environments. Reducing the number of control constructs to one, lambda, his
compiler was free to choose any advantageous local representation of
control it could find.

   The treatment of data manipulation was minimal in the original language,
as these primitives were punted to the implementation language, MacLisp.
Steele stated in his RABBIT dissertation, "We have no new ideas to present
here on such issues, and so have avoid this area entirely."  While the
subsequent revisions of the Report on Scheme have specified support for
specific data types and attendant functional interfaces, they have also
lacked support for low-level data type specification, allowing
implementations to punt such questions to "lower-level" implementation
languages.  This neglect is unfortunate, as it plays against the
(efficient) metacircular definability of Scheme.

   Scheme is not so much a language in the usual sense as a commitment to
providing a certain kind of continuation semantics.  This fact is evident
in R5RS's refusal to make the core syntactic keywords immutable in the
top-level environment.  Regrettably, the R6RS draft candidate and its
library-driven programming model effectively abandons this concept.
Indeed, far too much of the draft appears fixated on defining and punishing
syntactic errors.

   Instead of the approach taken by the R6RS draft candidate, the Schemey
method would be to define generic mechanisms for implementing libraries and
data types.  One set of candidates might be:

  * a safe way of specifying the layout of data structures down to the bit,
  * a generic way of introducing distinct namespaces into a running system and
     providing linkage into other namespaces,
  * extending the continuation model to communicating processes, and
  * defining program properties guaranteeing no dynamic memory allocation
    (similar to the tail-recursion guarantee).

Having these mechanisms in the core language would allow the efficient
implementation of the current R6RS proposal in Scheme as opposed to
requiring a separate implementation language.  I do not have specifics for
these mechanisms, but then I do not believe an R6RS is necessary in the
short-term.  Scheme is best understood as a challenge to efficiently
implement semantics that were thought to be inherently inefficient, and its
revisions should always add fresh challenges.

Name: Phil Bewig
Location: St Louis, MO, USA

Ratify: NO
I believe Scheme is best served by retaining its jewel-like
character: tiny, beautiful and perfect.  There is no need to
expand Scheme as the editors propose -- if I want Common Lisp,
I know where to find it.  I favor only a very small expansion
of Scheme to add a module system that enables numerous other
extensions to be added without conflict.

I like most of the proposals about numbers, because they
specify dark corners where current systems may differ.  But
I do not believe the full numeric tower should be required,
because some small and specialized implementations of Scheme
may find that the full numeric tower conflicts with their other

I do not like the adoption of unicode.  There are competing
character sets that may be preferable in some circumstances,
and requiring unicode would forestall their use.  Unicode
necessarily requires more storage space than ascii, and more
complicated runtime support, which may not be desirable in
all cases.  If unicode is to be introduced to Scheme, it
should be done by way of a command-line switch that defaults
to ascii.

Both the numeric tower and unicode are instances of what I
see as a larger problem -- the proposal mandates too much.
The editors seem to be concerned that there is too much
variety in the Scheme world, and propose to eliminate it
by making the rulebook thicker.  That is exactly the wrong
approach.  Celebrate the variety, and encourage it, so that
Scheme implementations can make their own decisions about
what is important to them.

One of the problems with making a standard too large is
that it leads to 'hardening of the arteries.'  Once something
becomes part of the standard, it can be hard to change -- for
instance, consider the difficulty of changing the boolean-ness
(is that a word) of '() several years ago.  By making the new
standard too large (whether you call it the language standard
or the library standard really doesn't matter), you make a
whole bunch of decisions that can't be changed, because
changing them would break too many things.  It is much better
to define a small language standard, and let the SRFI process
develop new libraries, which can be adopted or not as they fit
the needs of users.

Another problem caused by a large standard is stagnation, as
has happened in the Common Lisp world, where the standard is
aging and there is no motion toward a new standard.  I prefer
to keep the standard small.

I suggest that the only change needed for a new Scheme standard
(other than tightening some currently-underspecified corners of
the standard, particularly with regard to numbers) is a simple
module system that permits users to extend their Scheme systems
cleanly.  The module system should do for macros what lambda
does for functions: permit macros to be visible only within a
limited portion of a program.  There is no need for the
complicated module system the editors propose, and especially
not for built-in versioning.

Things that can be easily added given a module system should
be excluded from the proposal.  For instance, SRFIs currently
provide both records and errors, so there is no need to put
them in the proposal.  All of the standard libraries should
also be excluded from the proposal -- let implementers propose
new libraries via SRFIs, and the Scheme community can choose
which it prefers.

In addition to these technical matters, I am also concerned
about the reaction of the Scheme community.  During the work
of the committee, four editors resigned, and in his voting
statement, a non-editor implementer pleads with voters to
reject the proposal.  It would be a disaster if the proposed
standard causes outright schism in the Scheme community, and
given the number of passionate objectors, that seems at least
possible and perhaps likely.

I ask the editors to retain Scheme's jewel-like properties:
fix the few underspecified holes in the current standard, add
a simple module system that permits clean inclusion of libraries
(including macros), and let the Scheme community grow its own
extensions via SRFIs.

Name: Pierre-Alexandre Fournier
Location: Montréal, QC, Canada

Affiliation: Carré Technologies Inc.
Ratify: NO
They are some good things in draft 5.97, but we can't
say it follows the caution used by previous committees. This time,
committee members felt they had to resign during the review
process. Implementors felt their criticisms were not heard. De facto
standard SRFIs were ignored and replaced arbitrarily. Features with
unnecessary complexity (e.g. Records, Syntactic Layer) were added when
people didn't ask for it.

Draft 5.97 should be trimmed down to a document that raises
concensus. More features can be added in future RnRS if needed.

Name: Scott Bell
Location: Calgary, AB, CA

Affiliation: IBM
Mail: sebell@gmail.com
Ratify: NO
I would like  to first thank the Editors of  the current draft report,
their  past and  present  contributions to  the  Scheme community  are
significant  and  much  appreciated.   Thanks  also  to  the  Steering
Committee for their efforts in making this process possible.

The language described in the R5.97RS draft is powerful, complete, and
relatively unambiguous. It extends R5RS  to provide the user with more
features,  and clarifies certain  areas of  the language  where R5RS
implementations tend to differ. I  believe that many of the goals from
this draft to make  the language implementations more predictable have
been achieved.

The current  draft report, however, has imposed  far more restrictions
on the Scheme implementation than R5RS, which I believe will limit the
implementor's freedom  to experiment  within a conforming  system. The
numerical  tower,  module/library   system,  exceptions,  and  Unicode
characters are examples of this.

The  current draft  makes huge  strides in  the direction  of unifying
Scheme implementations  by way of imposing such  restrictions, which I
believe is  moving the language  too far in  a single report. It  is a
marked departure from previous reports, which carries with it the risk
of fragmenting the Scheme community.

The reason I have voted  against the ratification of the current draft
is because  I believe that the  spirit of the Scheme  language has not
been preserved.

Name: Shiro Kawai
Location: Honolulu, HI, USA

Affiliation: Scheme Arts, L.L.C.
Mail: shiro@acm.org
Web: http://practical-scheme.net/
Ratify: NO
This is a constructive 'No'.

 Language design is such a subtle and difficult process that I wouldn't
 naively expect the draft to converge into something that everybody agrees on.
 However, the discussions on 5.9x draft did yield better drafts (in my
 opinion) for each iteration.   Even on the controversial features where
 multiple mutually-exclusive ideas compete, it is good for R6RS to choose
 either way, at least knowing that some of us agreed to disagree.

 However, some suggestions and formal comments are not considered not 
 because of a conscious design choice but because of the lack of time 
 to change the draft to meet the deadline of the ratification draft;
 some because of the discussion being active too late, some because
 of the change in the draft is made in the last minutes.  It would be
 regrettable if something becomes a standard because ``we didn't have
 time to come up with a better one by the last couple of days''.

 Of course we can't discuss forever.  I believe, though, a few more
 rounds of discussions concentrating on the details would make much better

Name: Taylor R Campbell
Location: Boston, MA, USA

Mail: riastradh@gmail.com
Web: http://mumble.net/~campbell/
Ratify: NO
The R6RS proposal attempts changes far beyond the
spirit of Scheme that has always attracted me.  The proposed language
is complicated far beyond the original intent of Scheme, its
description thrice the upper bound of fifty pages set by one of its
inventors.  It imposes restrictions on implementation design that
impede future development of the language outside the three or four
main implementations in the authors' minds, in the areas of numbers,
text manipulation & Unicode, and the module system.  Overspecification
in the proposal is abundant.  Portable code is hindered by the
overreach of the module system's definition, which could have been
designed to coexist peacefully with other systems, but which was
not.  This is not the definition of Scheme that I first found, and
that I want to see; call it something else, but not Scheme.

Name: William D Clinger
Location: Boston, MA, USA

Affiliation: Northeastern University
Web: http://www.ccs.neu.edu/home/will/
Ratify: NO

The editors and steering committee have given us
several reasons to vote against ratification.  Two
reasons are procedural:  (1) Although the editors
were "encouraged to record electronic discussions
and meeting minutes in a publicly readable archive",
they have apparently refused to make those archives
public for the nine and a half months between 12
September 2006 and the present; (2) as described at
greater length below, the editors made substantive
technical changes in the candidate draft, including
two new paragraphs of tendentious nonsense; these
last-minute changes had the effect, whether intended
or not, of exempting those changes from meaningful
technical review, thereby forcing the registered voters
to choose between ratification of a nonsensical R6RS
and what some would happily misinterpret as rejection
of the entire process.

There is substantial risk that this candidate draft
will be ratified, which means this may be my only
opportunity to attach comments to my vote.  I will
therefore begin with a statement I had drafted when
I believed the candidate draft might be worthy of

                            * * *

[Although the editors' addition of a last-minute
show-stopper obsoleted the argument made below, I am
including this extraneous apology because it explains
why I feel the R6RS process was worth a try, even though
it has not yet succeeded.  This apology may also convey
some sense of my disappointment with the candidate draft
we were asked to ratify.]

Were I voting against ratification of the R6RS, the rules
would have required me to apologize for my vote.  Since I
am voting in favor, it seems only fair to apologize for
that too.

A negative vote would have been easier to explain.  To
explain a negative vote, it would be enough to pick any
of the things I dislike about the proposed R6RS and to
say it is my reason for voting against.  To explain my
positive vote, I must explain why none of the many things
I dislike about the R6RS are show-stoppers, list some
positive benefits of the R6RS, and explain why I think
those benefits would leave us better off with the R6RS
than without it.

When evaluating the R6RS, I look at it as a programmer
who has written, is maintaining, and wants to write more
portable programs and libraries in Scheme.  Since I am
also an implementor of Scheme, I understand the burden
of implementing the proposed R6RS, but that burden falls
on a small number of implementors and will be amortized
across the far larger number of programmers who use
Scheme to write portable programs and reusable libraries.
Even if the R6RS were so difficult to implement that only
one out of five implementations would ever be upgraded,
well, so be it; we do not really need 65 different
implementations of Scheme.  Had we but 10 R6RS-compatible
implementations, we could write Scheme programs that are
far more portable than is possible now with the 65.

The proposed R6RS offers improvement in several areas
where absent or weak or incompatible standards have
been making it unnecessarily difficult to write portable
programs and libraries.  Ratification of the R6RS would
improve the portability of lexical syntax, libraries,
arithmetic, error reporting, Unicode characters and
strings, records, binary and transcoded i/o, file
querying and deletion, non-hygienic macros, and hash
tables.  The R6RS would also provide standard libraries
for sorting; for bytevectors, which are substantially
more compact than vectors for some purposes and may
assist with development of more portable interfaces to
libraries written in other languages; and fixnum,
flonum, and bitwise arithmetic, which many programmers
do not need but will help to make certain kinds of
applications run much faster.

The proposed R6RS also has many flaws, but we can work
around most of those flaws and could even repair some
of them in a future report.  As to why these flaws have
not already been repaired, well, my personal opinion is
that I was outvoted.  Furthermore, I do not believe the
current editors are likely to change their collective
minds with respect to the flaws that bother me, just as
I am unlikely to change my putative mind on other flaws
that may bother them.

My list of the R6RS's flaws would amount to a list of
dissenting opinions.  Every editor, indeed everyone
who considers the R6RS, would come up with a different
list of its flaws.  By contrast, its improvements are
more objective: hardly anyone will deny that ratifying
and adopting the R6RS would improve portability in the
ways I listed earlier---although some would prefer to
improve portability by other means, and a few might
prefer not to improve portability at all.  The objective
nature of its improvements and the subjective nature of
its flaws persuaded me to vote in favor of the R6RS.

It was not an easy decision.

                            * * *

[The essay that follows was sent to r6rs-discuss@r6rs.org
on Tue Jul 10 06:52:31 2007.  I have edited one sentence
for the sole purpose of avoiding a software bug that led
the official archive of that mailing list to truncate my

an essay on language design:
fixing the syntactic record layer


More than twenty years have passed since I wrote this [1]:

    Programming languages should be designed not by
    piling feature on top of feature, but by removing the
    weaknesses and restrictions that make additional
    features appear necessary.  Scheme demonstrates that
    a very small number of rules for forming expressions,
    with no restrictions on how they are composed,
    suffice to form a practical and efficient programming
    language that is flexible enough to support most of
    the major programming paradigms in use today.

I still believe that first sentence, and I still believe
Scheme ought to demonstrate what is claimed in the second
sentence, but the draft we are being asked to ratify does
not always do that.

This shortcoming of the candidate draft can be seen in the
modularity and interoperability problems that beset the
syntactic and procedural record layers.  As I will show,
these problems are caused by artificial restrictions that
have been imposed upon the syntactic layer.  Removing those
weaknesses would remove the problems.

A last-minute change in the 5.97 draft attempted to fix
things by piling yet another feature, a parent-rtd clause,
on top of the syntactic layer [2].  The presumed purpose of
that parent-rtd clause was to address Andre van Tonder's
observation that incompatibilities between the syntactic
and procedural record layers create a modularity problem:
You cannot define a new record type that inherits from
an existing record type without knowing whether the base
type was defined by the syntactic or by the procedural
layer [3,4].

That also implies that record definitions are brittle:
Unless a record type is sealed, its definition cannot
be changed from using the syntactic layer to using the
procedural layer, or vice versa, without breaking all
record types that inherit from it.

Although the editors acted with the best of intentions,
their addition of the parent-rtd clause did not solve
the problems it was intended to solve.  Even with the
parent-rtd feature, you *still* have to know whether
the base record type was defined using the syntactic
or record layer, and you *still* can't change a record
definition from one layer to the other without running
the risk of breaking client code.

To make matters worse, the 5.97 draft added a couple
of questionable statements that attempt to excuse the
interoperability problems while asserting privileged
status for the draft's syntactic layer.  One of those
statements is based upon a patently false claim.

The editors have submitted this draft to the Steering
Committee as a candidate for ratification, so there is
no meaningful technical review of these last-minute
changes apart from the ratification vote itself.


I will summarize the interoperability problems mandated
by library chapter 8 of the 5.97 draft, trace them to
their root cause, show how they could easily be fixed
by removing artificial restrictions that are imposed by
the syntactic layer, and conclude by showing that the
two exculpatory statements of that chapter are partly
false and thoroughly misleading.


That the syntactic and procedural record layers do not
interoperate well has been known for a while now, and had
been acknowledged by the editors, who had declared their
intention not to do anything about it [5].  I did not
consider that to be an absolute barrier to ratification,
because better syntactic layers would have been proposed
as SRFIs, and one of those alternatives might eventually
have replaced the R6RS syntactic layer.  That would have
been a better outcome than piling on still more features
without fixing the fundamental problem.

The last-minute addition of parent-rtd addressed the
most obvious of the interoperability problems, which was
first mentioned in public by my formal comment 90 [5],
but left these others in place:

  * Record types defined by the syntactic layer are not
    interchangeable with record types defined by the
    procedural layer.

  * In consequence, the code you write for a record type
    definition that inherits from some base type depends
    upon whether that base type was defined using the
    syntactic or procedural layer.

  * Both layers are complex, which makes it hard for a
    casual reader to understand their relationships.

  * The procedural layer is the more expressive layer,
    so the draft's new warnings that try to frighten
    programmers into preferring the syntactic layer
    would have limited impact even if they were true.

The procedural layer is more expressive because it can
do everything the syntactic layer can do, and it can
also be used to create multiple constructor-descriptors
for a single record type descriptor [6].

That, of course, is a cue for someone to jump up and
say "We can fix that by adding a new clause to the
syntactic layer!"  Adding yet another feature would be
exactly the wrong thing to do.  We ought to fix the
problem, not try to cover it with still more sterile
adhesive strips.

The proper course of action is to understand why these
problems matter, why they arose, and how to fix them.
Then we should fix them.

The Impending Records War

By specifying two barely interoperable record systems,
and advocating the more complex and less expressive of
the two, the 5.97 draft would create an unnecessary
dilemma for organizations that use Scheme.  Most will
deal with incompatibilities between the two record
layers as they arise.  After dealing with several
instances of the problem, some organizations will
standardize on one or the other of the record layers.

Some will choose the procedural layer, because it is
more expressive or because it is more in keeping with
Scheme's roots as a higher order procedural language.
Others will choose the syntactic layer because that
is what the 5.97 draft suggests, or because Scheme's
macro system is really cool.  When these organizations
import code that uses the "wrong" record layer, they
will rewrite it to use their organization's standard
layer.  When they get tired of rewriting code, they
will clamor for the "wrong" record layer to be expunged
from the standard.

That conflict is unnecessary.  We do not have to fight
over which record layer is wrong, because we could fix
things so both are right.  That is not hard.  We should
do it.

The Root Cause

The root technical problem is easy to understand.
I'll digress for a few paragraphs to give you a
chance to figure it out before I do.

A friend of mine remarked that it is impossible to
design a record system for Scheme that won't lead
to interoperability problems.  This is Scheme, after
all.  Any Scheme programmer can define a new
syntactic layer for records, and its notion of a
record type might be different from the standard
notion, so programmers shouldn't expect to be able
to define a record type that inherits from any other
programmer's record type.

That's true, up to a point.  The point, of course,
is that we should be able to define records that
inherit from any record system that uses the
standard notion of a record type.

The 5.97 draft doesn't have a standard notion of
a record type.  It has *two* standard notions of
a record type, with context-restricted coercions
between them.

That is the root technical cause of the modularity
and interoperability problems.  The solution is to
define a single standard notion of a record type,
and to use that one notion as the basis for both
the syntactic and the procedural layers.

To do that, of course, the standard notion of a
record type will have to be a first-class object.
The syntactic layer can deal with first-class values
by deferring them to run time, but the procedural
layer can't reach back in time to deal with macro
or expand-time values.

This has been a source of controversy among the
editors.  The 5.96 and earlier drafts fudged by
saying a record type is an "expand-time or run-time
description".  The 5.97 draft changed that phrase
to "expand-time representation of the record-type",
thereby institutionalizing the interoperability
problems even as it pretended to do something about

In the 5.97 draft, the procedural layer's notion of
a record type is an rtd (record type descriptor).
The syntactic layer's notion of a record type is an
expand-time representation that bundles an rtd with
a preferred constructor-descriptor.

I will now describe a straightforward solution to
this muddle, based upon the following standard
notion of record type:

    A record type is an rtd.

To maintain compatibility with the syntactic layer
of the 5.97 draft, and for that reason only, every
non-opaque rtd will be associated with a preferred
constructor-descriptor.  The preferred
constructor-descriptor is the one associated with
the rtd in a special global table or, if that table
contains no preferred constructor-descriptor for rtd,
then the preferred constructor descriptor is the one
computed by

         rtd <parent-preferred> #f)

where <parent-preferred> is the parent's preferred
constructor-descriptor, or #f if there is no parent.

Note that the global table is a run-time object that
holds run-time constructor-descriptors.  Note also
that any implementors who would like to maintain an
expand-time or compile-time table of (conservative
approximations to) the information contained within
that run-time table are welcome to do so.

How does an rtd become associated with its preferred
constructor-descriptor?  By having the two be passed
as arguments to a special procedure that is known to
the macro/library/compiler/whatever system, but is
not exported by any of the standard libraries.  In
other words, only the syntactic layer can associate
an rtd with a preferred constructor-descriptor other
than the default.

I understand that the preferred constructor-descriptors
are an ugly hack.  They would not be present in any
record system I would design from scratch.  Why then
am I proposing these preferred constructor-descriptors?

Because I am taking a lesson from C++, which caught
on in part because it was bug-compatible with C.
The system I am about to describe is, in one of Mike
Sperber's favorite phrases, a conservative extension
of the 5.97 record system.

That means everything that would work in the 5.97 system
would work in the system I am about to describe, and a
number of things that wouldn't work in the 5.97 system,
but should, will indeed work in the system I describe.

How do we arrange that?  By removing the artificial
restrictions mandated by the 5.97 draft.

(We'll keep the artificial restriction that limits the
procedural layer's preferred constructor-descriptors to
default constructor-descriptors.  That restriction would
be easy to remove also, but removing it might complicate
the optional expand-time or compile-time bookkeeping that
appears to have been the driving force behind the 5.97


To avoid still more discussion of the API for the R6RS
record layers, I propose we keep the syntax and almost
all of the semantics of the 5.97 syntactic layer, and
keep all the procedures and all the semantics of the
5.97 procedural and inspection libraries.

I further propose we extend the syntactic layer by
eliminating certain weaknesses and restrictions.
We will:

  * Require define-record-type to bind the <record name>
    to the rtd, in the same group of definitions that binds
    the constructor, predicate, accessors, and mutators.

  * Allow the <parent rtd> and <parent cd> of a
    parent-rtd clause to be arbitrary expressions,
    as in the 5.97 draft.  (Notice, however, that
    the <record name> bound by a define-record-type
    is now an ordinary variable and can serve as the
    <parent rtd> without having to resort to a use
    of record-type-descriptor).

  * Extend the parent clause to allow any expression,
    which must of course evaluate to an rtd.

  * Extend record-type-descriptor to allow any
    expression as its <record name>, provided the
    expression evaluates to an rtd; in other words,
    record-type-descriptor would become a procedure.

  * Extend record-constructor-descriptor to allow
    any expression as its <record name>, provided
    the expression evaluates to an rtd; it would
    then evaluate to the rtd's preferred
    constructor-descriptor.  In other words,
    record-constructor-descriptor would become a
I might have missed something, but I believe that's
all it takes.

Note that record-type-descriptor has become unnecessary.
It is nothing more than the identity function restricted
to record type descriptors.  If I weren't trying to
describe a conservative extension of the 5.97 draft,
I would urge removal of record-type-descriptor from
the language [7].

Note that both the scope and semantics of a <record name>
bound by the syntactic layer have become clearer.  The
<record name> is no longer a name for some mysterious
"expand-time representation" that is neither a run-time
object nor a macro.  It is now an ordinary variable that
obeys ordinary scope rules, can be exported or imported
in the usual way, for run time, and has a first class
object as its value.

I'm not going to claim this is a good record system,
but it offers all the features of the 5.97 draft,
all of the performance (for all use cases that can
even be expressed using that draft), and none of the
modularity and interoperability problems associated
with the record layers of that draft.


The 5.97 draft contains a couple of new paragraphs
that attempt to justify its limitations by appeal
to matters of performance.

Page 16 says:

    However, the record operations provided through
    the procedural layer may be significantly less
    efficient than the operations provided through
    the syntactic layer.  Therefore, alternative
    implementations of syntactic record-type
    definition [sic] should, when possible, expand
    into the syntatic [sic] layer rather than the
    procedural layer.

To put that in perspective, let me point out that
the map procedure may be significantly less efficient
than using a do loop.  Indeed, there have been many
implementations of Scheme in which do loops are more
efficient than calls to map.  Despite that fact, none
of the Scheme reports have ever advocated using do
loops instead of map.  To advocate such things would
be inappropriate for an implementation-neutral

In typical uses of records, the base record type
will be defined at the top level of a library, where
the variable that holds the rtd will be immutable,
as will all of the other top-level variables that
are defined in terms of the rtd.

That makes it almost as easy to optimize code written
using the procedural layer as code written using the
syntactic layer.  Sure, some compilers may optimize
one without bothering to optimize the other, but most
would optimize neither or both.

In any case, it is obvious that any program that can
be written under the restrictions of the 5.97 draft
is also a program under my proposal.  If some macro
expander and/or compiler were written to record some
expand-time information when the syntactic layer of
the 5.97 draft is used, then they can record exactly
the same information for the syntactic layer of my
proposal.  The only additional complication of my
proposal is that the macro expander and/or compiler
would have to recognize when the <record name> is
an expression other than a variable that was bound
by define-record-type.  Recognizing that is trivial.

My proposal would not require any new flow analysis.
The advanced optimizations that require flow analysis
would use essentially the same flow analysis under my
proposal as they would under the 5.97 draft.

Consider, for example, that the 5.97 draft allows the
rtd associated with a <record name> to escape via the
record-type-descriptor syntax.  That means the rtd of
a <record name> that is exported by a library, whether
explicitly or implicitly, may escape within some
importing library [8].  Hence any optimizations that
require flow analysis of the rtd must either defer the
optimization until a whole-program analysis can be
performed, or else assume that the rtd of an exported
<record name> will flow into arbitrary contexts.  In
other words, the rtd-flow analysis required by the
5.97 draft is already as bad as it could be, so my
proposal can't possibly make it any worse.

Page 18 says:

    Note:  Use of the parent-rtd clause generally
    forces an implementation to delay the generation
    of constructor, accessor, and mutator code until
    the record-type definition is evaluated at run
    time, since the type of the parent is not generally
    known until then.

That is a false statement.  The editors might as well
claim that the code for a lambda expression cannot be
generated until run time, since the values of its
free variables will not be known until then.

Even in the current release of Larceny, all of the code
generated for constructors, accessors, and mutators is
generated at compile time.  None of that code is ever
generated at run time.

In future releases, an unoptimized record access will
consist of a procedure call, a double tag check, an
indirect load, an eq? check, and a load.  Twobit's
existing optimizations, or easy extensions of them,
will eliminate any or all of that code when it is safe
to so.

The code that isn't eliminated by optimization will
be generated at compile time.  No code will ever be
generated at run time.

And that's for the procedural layer.  There is no
earthly reason for a compiler to generate worse code
for the syntactic layer than for the procedural layer,
or to generate it any later.

    The parent clause should therefore be used instead
    whenever possible.

This recommendation is based upon a false premise.

So What?

The substantive changes that were made in the 5.97
draft are immune to meaningful technical review, so
why did I write this?  Partly to blow off steam, of
course, but there were at least three other reasons
as well.

As Andre van Tonder wrote, the only way for us to
register disagreement with changes made in the 5.97
draft is to vote against ratification [9].  Under
the rules of that vote, any negative vote must be
accompanied by an explanation, so I had to write
something like this anyway.

I am told that, if this draft is not ratified, the
Steering Committee intends to pay a lot of attention
to the reasons cited in those explanations.  If you
vote against ratification for reasons that include
some of the issues I have discussed, then you may be
able to save some writing by citing this essay.

The second reason has to do with what happens after
the vote.  As I see it, there are three possible

    1.  The vote is negative, which would give the
        editors an opportunity to get it right.

    2.  The draft is ratified, and everyone pretends
        to live happily ever after.

    3.  The draft is ratified, and the unhappy folk
        design alternative syntactic layers, probably
        written up as SRFIs, that build upon the R6RS
        procedural layer.

This little essay of mine might be of some use, or
at least have some influence, in the event of outcomes
1 or 3.  I don't think outcome 2 is stable in the long
run.  I think it would evolve into outcome 3.

Thirdly, writing this essay gave me a chance to consider
whether I still believe what I wrote so long ago.


Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses
and restrictions that make additional features appear

R6RS Scheme should demonstrate that a very small number
of rules for forming expressions, with no restrictions
on how they are composed, suffice to form a practical
and efficient programming language.

William D Clinger
5-9 July 2007


[1] Jonathan Rees and William Clinger [editors].
Revised^3 report on the algorithmic language Scheme.
ACM SIGPLAN Notices 21(12), December 1986, pages 37-79.

[2] Michael Sperber et al.  Revised^5.97 report on the
algorithmic language Scheme -- standard libraries.

[3] Andre van Tonder.  Rationale issues.  Posted to
r6rs-discuss, 26 June 2007.

[4] William D Clinger.  Response to [3], 27 June 2007.

[5] William D Clinger.  Record layers are not orthogonal.
Formal comment #90, 13 November 2006.

[6] It doesn't matter whether the descriptor was created
using the syntactic or the procedural layer.  This is an
example of the interoperability we should have throughout
the record system.

[7] It is analogous to endianness, buffer-mode, et cetera.

[8] Whether the 5.97 draft allows a <record name> to be
exported from a library may not be entirely clear, but
disallowing such exports would be disastrous, so I assume
the 5.97 draft is meant to allow such exports.

[9] Andre van Tonder.  parent-rtd clauses in records.
Posted to r6rs-discuss, 3 July 2007.

                            * * *

[These final paragraphs were sent to r6rs-discuss@r6rs.org
on Tue Jul 24 15:28:07 EDT 2007.  I have edited the first

It now appears that the primary technical basis for the
two paragraphs of tendentious nonsense on pages 16 and 18
consists of two load instructions that fetch the free
variables of a closure.  Furthermore one of those load
instructions is easily eliminated for almost all record
accesses even with the procedural layer, and the other
is just as hard to remove with the syntactic as with the

I can accept poor language design.  I cannot accept false
and misleading attempts to excuse poor language design
or to discourage programmers from using closures.

If the editors wish to advocate nonsense, they should
do so in their individual publications, not in the R6RS.