Additional Correspondence

The poll closed at 10:00:00 GMT on Monday, August 13 (the end of the day on August 12th in Honolulu - the location of our westernmost voters). After the poll closed, people continued to send us additional ballots and requests to modify their ballots. Since we had been quite clear about when the poll would close, this additional correspondence could not be counted in the official results.

Because these messages were clearly sent in the honest (but mistaken) belief that they were not too late, the Steering Committee agreed to publish this additional correspondence as an appendix to the permanent record.

In favor of ratification:

Opposed to ratification:

Wishing to change to opposing ratification:

Name: Etienne Bergeron
Location: Montreal, QC, Canada

Affiliation: Universite de Montreal
Ratify: YES
Scheme is a small core language with some evoluated
features built on the cores. This way, it s easy to port it on small
embedded devices. I really do not like the way you manage
modules/librairies/external. You seems to make the Java mistakes and try
to have a language with so many librairies instead of a language AND
some librairies you can plug in. I prefer the concept of SRFI. The
language and the libraries must be distinct... but, it must have a
standard way to plug libraries.

Name: Geoffrey S. Knauth
Location: Williamsport, PA, USA

Affiliation: Lycoming College
Ratify: YES
Thank you for all your hard work.

Name: Kent M Pitman
Location: Arlington, MA, USA

Ratify: NO
Although I am happy that appropriate changes have
been made to better acknowledge the work of the authors of
the previous document, I continue to believe that there
has been a strong change in the nature of the document
that makes it not suitable for continued rev'ing of the
old name.  I would prefer to see a new name.

My negative vote at this time should in no way be taken to
deny the important work being done now, however I strongly
believe that this latest work is the beginning of a new
series, not the end of an old one.  I think a new series
of documents, beginning with a version zero (which may be
the drafts leading up to this) and a version one (which 
might be the ratified version) is the right way to tell
that story.

I think the old effort had different goals and that it's 
better to leave it historically stable and consistent with 
existing publications than to force the community into a
sense of upheaval.

There may well be a sense that beginning a new document 
could fragment the community.  If that happens, so be it.
I don't think it will.  The fact is that the new changes 
should attract the lion's share of the audience, so I don't
really see that happening.  But if to my surprise there are
people that don't accept the new document, they should be
entitled to continue to have the old document available under
a name they can easily refer to.

I think the breaking out of the document into multiple 
documents is also appropriate and again will confuse the
naming if one wants to compare this set of documents to the
old single document.  Again this is a reason to separate
the series-identification.

I would change my vote to Yes if this document were renamed
to have a new identity that did not conflict with the old

Name: David Van Horn
Location: Somerville, MA, USA

Affiliation: Brandeis University
Ratify: NO
The R5.97RS draft represents a significant and valuable contribution
to the Scheme language and I look forward to the eventual ratification
of a draft in this series, however I feel the current report has a few
fundamental issues that must be addressed before finalization.  There
are also numerous smaller issues, both technical and editorial, that I
would like to see resolved.

My hope is that, should the ratification of 5.97 fail, the editors
will consider and respond to the issues raised by the electorate in
their ballot comments and produce a revised draft, then conduct
another one or two public review rounds with formal comments and
responses, perhaps on a shorter schedule than with the previous
rounds.  With each round, the editors should produce another draft
revision.  I'm confident the current draft would be vastly improved by
such an effort and would feel comfortable ratifying the document.

Name: Joshua Herman
Location: Darien, IL, USA

Ratify: NO
I feel that the scheme standard is making a wrong
decision in presenting with the current draft because the SRFI process
is largely ignored by the draft. Also the removal of load is a problem
because of the fact that I believe it should still exist in the
standard because of its importance to scheme especially using a REPL.
Another problem I have with the standard. Another problem is the
record library which is horribly broken and must be replaced before I
can approve of the draft.

Name: Tim McNerney
Location: Newton, MA, USA

Ratify: NO
The language as proposed by 5.97 has gotten too complicated
both for students and for implementors.
Too little attention has been paid to backward compatibility.
There is a large body of existing Scheme code that no one
has time to rewrite to meet the new standard.
In the past, new language features were implemented, and
only then proposed as standards.  The latest draft standard
is proposing too many features for which the community has
little or no experience.
This is not to say that the proposed new features don't have
technical merit.  I thought individually they all were quite worthy.
The problem comes more in the area of "marketing."  Collectively
do the new features make up for the burden of implementation
and learning curve by making the language more popular?
If the answer is "no," then we need to ask ourselves what is the
point if the revision endeavor.
Moving forward, I think we should be able to vote for or against
individual features.
In general I think 5.97 needs more discussion.
My recommendation is to take in the feedback provided during
the balloting processor, write a 5.98, and have a new vote.