R6RS Electorate

Pursuant to the ratification procedure, here is the final listing of the R6RS electorate:



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

Mail: Jay_Reynolds_Freeman@mac.com
Web: http://web.mac.com/Jay_Reynolds_Freeman
I have been a Lisp user for more than twenty-five years, and a Scheme
user for twenty years.  My stake in the outcome of the Scheme
standardization process is that I develop Scheme implementations for
my own use, and am in the habit of releasing them as shareware as a
public service.  (My releases to date are all for the Apple Macintosh.
They include Pixie Scheme, with several R3.xx releases in 1988-1991,
and more recently Wraith Scheme, which started as R3.99 and has just
made it to R5.  Unreleased, but potential candidates for release, are
versions of Wraith Scheme that run in a straight Unix shell, one with
and one without the help of ncurses.)

Clearly, I can create whatever software I like for personal use
without worrying overmuch about standards, and clearly, there are
enough well-established Schemes that the community would not suffer
unduly for lack of my efforts (unless perhaps someone likes my user
interface or documentation).  Yet there is virtue in using an
established standard as a base for development; namely, that if any of
my explorations and side trips should be of general interest, the
community will better be able to investigate and evaluate them if they
are presented as enhancements to a standard rather than as additions
to something that wasn't quite Scheme in the first place.

For that reason, I have consistently tried to make sure that the
Schemes I create contain a core that closely follows a recent
"rn" report, with clear documentation and user-friendly features, and
with such enhancements as I have made all precisely described,
carefully documented, and constrained to a well-defined namespace.
Since I hope to continue this practice in the future, I am
consequently concerned with the continuing development of Scheme
standards, for they are the standards I would like and intend to
underly my own implementations.

I hope this line of reasoning qualfies me for a vote on R6.

(I note that notwithstanding much, er, discussion, there is no
indication in the registration instructions that my statement of
interest is supposed to say what I think of R6; I am not trying
to be coy, I will tell you if you want to know, but the wording of the
registration stuff does not seem so to indicate.


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

Web: http://t3x.org/nmh/
I am an active Scheme user since the early R4RS days. The day I got
my hands on a copy of R4RS I knew I had found the language I had been
looking for for many years.

R5RS Scheme is what LISP always should have been: a bridge between
lambda calculus and applied programming. It adds some interesting
features, like continuations and hygienic macros, but manages to
keep a small footprint, which is reflected by both its implementations
and its standard documents. Scheme is a local optimum for expressing
algorithms in an abstract and portable way.

This is why I introduced Scheme as the principal implementation
language on my CS and programming web site a few years ago. The web
site carries Scheme-related information, software, and documents.
Among other things it provides the full text of my introduction to
functional programming in Scheme (also available as a book), PS/Tk
(a portable Scheme interface to Tk, which I maintain), two toy Scheme
implementations, and lots of Scheme code.

Scheme is also my language of choice for implementing commercial
software, and I plan to promote it as an extension language for
professional customers in one of my projects.

Finally, I think that Scheme is an ideal teaching language, because
it encompasses all essential abstractions without adding any useless
load. My future textbooks will definitely use Scheme as their
implementation language.


Name: Ben Simon
Location: Arlington, VA, USA

Mail: contact.ben.simon@gmail.com
Web: http://benjisimon.blogspot.com/
My interest in Scheme is quite practical: I have found it to be a
language that I can write efficient, maintainable and beautiful
programs in.  And I have done so, in a production and commercial
environment. Most recently, I developed Tenspotting
(http://tenspotting.com), a Web 2.0 application written in Scheme using
the SISC implementation and the SISCweb library.   I am absolutely
sure that I had linguistic advantages by using Scheme rather than
Java, PHP or other available options.

Previously, I have used Scheme as a scripting language for front end
of a Java web application.  By using Scheme myself and my team were
able to quickly add functionality  to the application that would have
otherwise required significant Java development.   By making use of
Scheme we were also able to leverage a network based REPL, which
allowed us to interactively update the application on the fly.

Along with on-the-job uses of Scheme, I have also benefited immensely
from the lessons I have learned while studying Scheme related
material. Topics such as what makes a well defined abstraction, OO,
threading, distributed systems, lexical vs. dynamic scoping, are all
general purpose topics that were made much clearer through studying
them in a concrete Scheme environment.

I look forward to using Scheme in additional projects, and I am quite
appreciative to have even the smallest impact on its growth and
improvement.


Name: Ronald Garcia
Location: Bloomington, IN, USA

Affiliation: Indiana University
The Scheme programming language has provided an interesting medium for
investigating programming language design, teaching the art and craft of
programming, and constructing useful and interesting software.  I 
personally use Scheme, in a number of dialects, to persue all three of these
practices.  The standardization process that led to R5RS resulted in a very
intentionally designed, clean but sparse language representing a set of
widely accepted and mature language features.  Individual implementations of
Scheme and Scheme-like languages have continued to explore aspects of
language design and have arrived at new widely accepted but non-standard
features.  I use many of these features in my work, and I am not alone.  I would
like to see their acceptance expressed in an updated language standard, and
their representation made consistent across implementations.  I have no
misconception that a new language standard will be perfect: no language
standard has ever been.  Nonetheless, standardization has the potential to
advance Scheme and my work by documenting the lessons learned since the last
standardization, decreasing the unnecessary differences between
implementations, and providing a new platform from which language designs can
be started, programming can be taught, and software can be crafted.


Name: Kathi Fisler
Location: Providence, RI, USA

Affiliation: WPI (Worcester Polytechnic Institute)
Web: http://www.cs.wpi.edu/~kfisler/
I am a computer science professor who uses Scheme extensively in my
courses.  I teach introductory-level programming courses (for each of
novice programmers and die-hard non-functional programmers) and upper
level/graduate courses in programming languages.  I touch on several
topics that are unique to, or best suited to, Scheme, including
macros, continuations, and quote/quasi-quote.  These have allowed me
to give students a whole new perspective on both web programming and
domain-specific languages.  I want to see Scheme thrive as a language
because of the value these exercises give to the students who are open
to them.  We are all familiar with students who reject Scheme as a
mere "teaching language ".  Those of us who use this language know
that Scheme is neither trivial nor dead, but keeping the language
alive through a healthy standard matters to keeping the language fresh
and usable for realistic programming tasks.  Students who see and like
the language want to be able to use it for non-curricular
programming.  The standardization process says that Scheme continues
to be a language worth developing. I strongly believe in this view
and am registering to vote to keep this process alive and well.


Name: Prabhakar Ragde
Location: Waterloo, Ontario, Canada

Affiliation: University of Waterloo
I have been a professor at the University of Waterloo since 1988.
For the past few years I have taught an introductory programming course
to CS and Math majors using Scheme. By the fall of 2008 we expect to have
over a thousand students a year moving through courses using Scheme.
I have also used Scheme for various administrative tasks related to 
teaching
(generation of Web pages, slides, course handouts, checking and typesetting
of logical proofs). My interest in this standard is not just to ensure that
Scheme remains the best introductory language for computer science that 
I know of,
but to ensure that I am able to demonstrate to students how it can form 
a valuable
part of their toolkit, both for upper-year courses and in their 
professional lives.
I will be reading the final draft of the standard and the discussions 
surrounding
it to try to decide if the standard preserves those features of Scheme I 
find
valuable (clarity, concision, and a smooth learning curve that avoids 
needless
complexity or obscurity) while enhancing the previous standard in ways that
will facilitate the deployment of Scheme in the ever-increasing range of 
uses
to which computers are being put. 


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/

My primary interest in the Scheme standard is its the potential to
make my work, in terms of Scheme libraries and tools like PLT Scheme,
more useful to a wider group of programmers.

I will vote in favor of ratification, even though the document
has technical flaws --- and even though it says too much about
some things, too little about other things, and includes some
design elements that could be much improved. On these general
opinions, I have lots of company, but opinions vary on which
parts are too much, which parts are too little, and how the
design of various pieces should be improved. In the end, it's a
compromise.

Further discussion and work will certainly lead to a better
compromise and a better candidate standard. Of course, any
improvement will also preserve many flaws. It seems to be human
nature, when faced with the certainly of imperfection, to think
that if we at least fix X and Y (for whatever X and Y one happens
to care about), then everything will be good enough --- while not
fixing X and Y means certain disaster. In reality, it's rarely so
simple; consider the last few 5.9x drafts, which attempted to fix
a few Xs and Ys, but created little perceptible change in the
community's overall opinion of the draft. Moreover, I see few
examples where an implementation, specification, or user
community collapsed due to one or two wrong details.

Utter collapse and significant progress both take time. Looking
back from this point in Scheme's history, collapse seems to have
a head start. The 5.97 compromise is progress. Let's name it
`R6RS', start getting more practical experience with it, and
start working on a better standard named `R7RS'.


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

Mail: bts@alum.mit.edu
Web: http://www.evenmere.org/~bts/
I use several functional programming languages professionally.  Right now,
Scheme isn't used for any of the projects for which I'm paid.  It's been
supplanted by languages with better standard support for modularity.  These
are mostly ML dialects such as OCaml and Haskell.  I'm being burned by
reliance on single implementations there (INRIA OCaml and Glasgow Haskell).
I'd like to use Scheme for many purposes.  It sure is easier to embed a
Scheme than to embed one of those languages!  I also value the ability to
quickly explain very basic Scheme to users.  This is the same feature that
made Scheme attractive for GNOME Guile and Lua attractive for World of
Warcraft.  For this use, I'm most interested in a Scheme standard that is
big enough to provide the features I want, like libraries and modules,
without burdening implementors enough to distract them from building the
nonstandard features I want, like concurrency and type inference.

I am also interested in Scheme for education.  Having benefited
tremendously from SICP as a student, and from a broad base of SICP-educated
students while teaching higher-level students, I am particularly interested
in maintaining a language that can be shown in a very simple way, support
better tools for advanced students, and avoid the contempt of students who
see customary commercial languages.


Name: Ian Barland
Location: Blacksburg, VA, USA

Affiliation: Radford University

  A standardized module system for R6RS is important to me as an educator,
  because of the long current shadow Java & O.O. is casting -- when some
  people claim  "classes are necessary for exporting names in a controlled
  way",  many current students have no reason or experience to disbelieve
  that.  Scheme, as an syntactically elegant language with minimal syntax,
  is one which can be pointed to as an alternative, providing defense
  against "OO is a necessary paradigm for all languages".

  Moreover, it's healthy for a language as a whole to have a
  reasonable language standard which is broad enough to provide
  industrial-strength features which are portable across several
  major implementations.  Sure, if the language standard is too
  difficult to implement or does things poorly, then it can be bad
  for the language's acceptance, but much worse is to not have
  a standard at all, for necessary features in large-scale programs.

  Evidence that use of modules is pervasive -- and therefore an issue
  which should be dealt with by the language standard -- is that to check
  the word count of this submission, I loaded the regular-expression
  library...
  


Name: Joshua Herman
Location: Darien, IL, USA
The Scheme programming language is an elegant language that
deserves to be continued. I believe that it is in the best interest of
programmers at large that scheme should be revised to keep up with the
current definition of what a programming language is. Scheme
demonstrates that languages can be made to do the right thing and
still be an effective programming language. A great deal of language
innovations have been introduced in scheme and through its revision we
can hopefully introduce more. What I like about scheme is the fact
that it is a language that is based upon a small set of primitives and
language features are not just mindlessly tacked onto the language but
instead thoughtfully added to the language. This is what I hope that
will continue to be a part of the language and is my personal stake in
the outcome of the scheme standardization process.


Name: John Clements
Location: San Luis Obispo, CA, USA
Scheme is a loose confederation of languages, with a well defined  
core.  R5RS
has been the core definition of Scheme for many years, and could  
concievably
serve as a core for many more.  But it shows its age more with every  
passing
one, and certain omissions (structs!) now seem fairly appalling.

Naturally, these omissions don't prevent the individual  
implementations of
Scheme from adding these features.  However, each implementation will  
almost
certainly differ from all the others in the particulars of these  
features'
implementations, and over time the languages will diverge until  
Scheme seems
less a language than a set of guiding principles.

For this reason, I strongly support the ratification of R6RS, perhaps  
more as a
simple statement of unity than as a set of new language features.  I  
earnestly
hope that R6RS will bring the Scheme implementations closer together, so
that--as a DrScheme user and sometime author--I feel less as though I'm
traveling in a foreign land when I use Gambit, or Scheme48 (or ...).

Many thanks to the current committee, and all their hard work. (I'm over
the 150-word limit before this paragraph, so I no longer feel that I  
have
to stick to the topic at hand.) Again, thanks.


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

Affiliation: Carré Technologies Inc.
(string-append "I use Scheme as my primary computing language since 2003, and I
have used it for academic research and enterprise software
development. I have used several implementations for different
projects, including Gambit, Chicken, Guile, STklos, and PLT Scheme. I
have worked on several applications developed in Scheme, including
applications for Speech Processing, Data Mining, Digital Signal
Processing, Medical Diagnostic and Artificial Intelligence. The areas
of the language I am most interested in are domain-specific languages,
compilation issues, libraries/modules systems, foreign languages
interfaces, and parallelism." "I adopted Scheme because it allows me to express the paradigms of
many programming languages using just one language (e.g. symbolic
programming, functional programming, object-oriented programming,
logic programming, etc.). It is an excellent tool to learn all these
concepts and use them to develop robust and powerful software. I like
the simplicity of the language and find very interesting the large
variety of Scheme flavors available on the web. R6RS could have
several implications regarding the nature of the language, and that is
why I want to vote.")


Name: Felix Winkelmann
Location: Göttingen, Germany
I'm the implementor and lead-maintainer of CHICKEN, a popular
Scheme implementation. I do not support R6RS out of following
reasons: it introduces arbitrary and redundant language
constructs into a language that has been designed from the start
to be minimalistic. The minimalism in Scheme was and still is the
base which distinguished it from all other languages and makes it
an excellent experimentation platform and language design tool.
Minimalism is the very essence of Scheme: to express as much as
possible with as little as possible. Designing such a thing is
naturally extremely hard which made the original authors of the
Scheme report (quite wisely) to decide on only making changes
with unanimous consent. R6RS does away with that process and
tries to remodel Scheme as some sort of mainstreamish language
and so completely removes itself from the roots that make Scheme
what it is.  R6RS will improve cross-implementation portability,
but not by deliberate language design, but by artificially
reducing the number of conforming implementations. R6RS has not
adapted common and widely used SRFIs, yet includes less used or
even obscure fringe SRFIs (mostly by one author, who incidentally,
is member of the R6RS committee).  In my opinion, R6RS shows
disturbing signs of dilettantism in the selection of language
features added to the report: arbitrariness, unnecessary syntax
constructs where procedures would do and completely redundant
language features.

It sucks, folks - face it.

DEAR SCHEME USERS: DO NOT ADOPT R6RS! SEVERAL MAJOR SCHEME
IMPLEMENTATIONS HAVE DECLARED NOT TO SUPPORT IT, WHILE NEARLY
ALL SCHEME IMPLEMENTATIONS WILL STAY R5RS COMPATIBLE OR PROVIDE
R5RS COMPATIBLE MODES IN THE FUTURE.

DEAR SCHEME IMPLEMENTORS: DO NOT ADAPT R6RS! DON'T WASTE YOUR
TIME RUNNING AFTER A BROKEN STANDARD WHILE YOU COULD HELP YOUR
USERS MORE BY ADDRESSING REAL PROBLEMS.



Name: Tim McNerney
Location: Newton, MA, USA

Web: http://www.4004.com/
I learned Scheme while taking MIT's 6.001 and have been a fan ever
since.  I even went back and read all of Guy Steele's 'Lambda: The
Ultimate' papers.  Since I was a student, my professional programmer
'hat' and my programming language semantics/aesthetics/mathmatician
'hat' have frequently been at odds.  A number of times when I tried to
use Scheme for a project, I would invariably wish Scheme had a rich
set of standard 'libraries' like Common Lisp so I wouldn't have to
re-invent the wheel, even though CL has never been as elegant, and
certainly suffered from committee-itis through its development.
Recently, there have been (proposed) changes to the Scheme standard,
like case-sensitivity, that (to me, at least) go against a
long-standing tradition, though I do understand that most modern
languages are case-sensitive.  There are other changes that I think
are 'the right thing.'  I am very happy with the direction that Scheme
macros have gone in.  I wish there were better hooks/tools for
debugging deeply nested runtime environments.  In general, I am
interested in monitoring the standards process in the hope that things
don't get gratuitously out-of-hand.


Name: Brent Benson
Location: Burlington, MA

Affiliation: Oracle, USA
My interest in the outcome of the Scheme standardization process stems
from my 20+ year involvement with programming language design and
implementation.  I have been an implementor of optimizing compilers
for imperative languages like C and Fortran, but my primary interests
are in the area of functional and dynamic languages.  I am the
original author of the libscheme implementation of Scheme and the
Marlais implementation of Dylan.  I was introduced to Scheme by the
book _Structure and Interpretation of Computer Programs_ and have
followed its evolution through many implementations, research papers,
and standards changes.

One of the major problems I have faced when trying to write large
programs in Scheme, is the lack of standard solutions to everyday
programming requirements like tagged records.  When starting a new
program, I am forced to either manufacture my own records using tagged
vectors, or learn a new record mechanism based on the implementation I
am using.  This is a big disadvantage that Scheme has when compared to
other modern dynamic languages.  I am very encouraged by the move to
provide a standard library mechanism which will allow the core of the
language to remain small, while making it easier to program in the
large.  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.


Name: Adam Blinkinsop
Location: Hillsboro, OR, USA
The release of R6RS is coming into a world of languages that have
   been getting closer and closer to Scheme in the past few years.  With
   Java gaining more functional features, Python coming up strong, and
   Haskell gaining steam, the world is prepared for a properly designed
   and implemented Scheme.

   Of course, this next revision cannot expect to be welcomed.  The
   prefix expressions and 'superfluous' parenthesis that makes the
   code-as-data paradigm so elegant is generally disliked by those who
   don't yet understand it.  Scheme also has a reputation for being weak
   and slow, while implementations like Bigloo and Chicken are working
   to reverse that prejudice.  R6RS is one more step towards general
   acceptance and usage.

   I hope to implement a Scheme compiler for R6RS.  This compiler will
   initially be written in C++, targeting LLVM, and eventually be
   rewritten in R6RS itself.  This makes me extremely interested in the
   standardization process, as a well-written standard makes the compiler
   design much more straightforward.


Name: Etienne Bergeron
Location: Montreal, QC, Canada

Affiliation: Universite de Montreal
Mail: bergeret@iro.umontreal.ca
Web: http://www.iro.umontreal.ca/~bergeret/
I'm a PhD student working on dynamically reconfigurable FPGA and the
use of Scheme was a must because our system is running in embedded
devices. I'm using Scheme for about 10 years. Scheme is important to
me because it is a small and compact language, easy to learn and can
be so expressive by using high-level features. I port Gambit on Xilinx
FPGA and use its runtime. We are trying to implement a JIT compiler to
produce on-the-fly hardware (configuration for a FPGA) and improving
performances on some applications. Scheme is a good choice for
studying compilers because it's easy to manipulate code as data (and
vice versa). I wrote about 3 others compilers in Scheme, and I will
continue to use it for its simplicity. So, I'm interested in the
standard because I need more uniformity in the interface between
runtime and applications. Actually, programmers do not choose Scheme
language, but a specific implementation. The language is supposed to
be portable!? The standard must give more effort on this lack.


Name: Kevin Millikin
Location: Aarhus, Denmark

Affiliation: Department of Computer Science, University of Aarhus
Web: http://www.brics.dk/~kmilli
My interested in Scheme is as both a programmer and an educator.  As a
programmer, I have been using Scheme since 1996 and I have used Scheme
professionally for the rapid prototyping of language processors.  For the
professional programmer, Scheme should continue to offer useful languages
features and the possibility of high-quality implementations.  As an educator,
I believe that (a) an introductory programming language should have a simple
semantics with a minimum of syntactic baggage and (b) that the study of
programming languages and their implementation is an important part of an
undergraduate CS curriculum.  Scheme has been successful as an introductory
programming language.  It serves very well as an implementation language for
language processors, and as a realistic and interesting source language for
them.  The Scheme standard should continue address the requirements of
programmers and educators alike.


Name: Mark Engelberg
Location: Everett, WA, USA
As a computer science educator, I use Scheme (specifically PLT's
DrScheme) along with the "how to design programs" curriculum to teach
the art of programming to teenagers and kids as young as 7 years old.
Despite its usefulness as a pedagogical tool, Scheme suffers from a
number of problems.  The struct syntax is clunky, it lacks important
syntactic sugars (such as comprehensions), and most importantly, it
lacks a coherent set of standard libraries for lists, strings,
streams, resizable arrays, GUI, OO, searching, sorting, permutations
and more.  After initial concepts are learned, the next step in
programming education is to learn about libraries -- what sorts of
data structures and algorithms are typically available, and how do you
use them.  It seems a shame that my students can't do this kind of
learning in Scheme.  Ultimately, this prevents me from giving my
students challenging, real-world problems to solve in Scheme, because
without a base of well-documented, standard libraries, it becomes
impractical to try to tackle these sorts of problems. Clearly, Scheme
needs to grow as a language, and the standardization process is part
of that growth and change.  My hope is that the new standard will
better allow for the construction of standard libraries, making my job
as an educator easier.


Name: Phil Bewig
Location: St Louis, MO, USA
I am a professional programmer, though I have not
yet found a job that allows me to program in Scheme.  I use Scheme for all
of my personal programming.  I have been active on comp.lang.scheme for many
years, and am the author of SRFI-40 A Library of Streams (I am currently at
work on a revision).  Scheme embodies for me the perfect programming
environment -- it allows zen masters like Oleg to write a mini-prolog, and
lesser mortals like me to write csv parsers and sudoku solvers.  I am
interested in the R6RS process because I want Scheme to grow and prosper,
but retain its jewel-like properties.  I know from my work on SRFI-40 that
writing a language standard is ridiculously hard work, constantly requiring
decisions both great and small, and I applaud the committee for its great
work.  And I am very intrigued by the fact that the community is being asked
to vote on the standard -- I don't know any other language that has done
that, and it will be interesting to see what happens.


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/
My stake in the Scheme standardization process is that of a  
user.  I use Scheme in my work as a theoretical astrophysicist at  
MIT.  Currently, I use Scheme as 1) a scripting language controlling  
computational codes written in another language (usually C) and 2) a  
prototyping language for codes which will eventually be re-written in  
another language (usually C).  But, I think Scheme could be so much  
more than this.  With macros and first-class functions, Scheme could  
be a premier scientific development language---a "domain-specific"  
language for every problem, with the power of closures, customized  
class and unit systems, and automated compiler optimizations through  
macros would be incredible.  Unfortunately, Scheme is not there yet:  
the implementations fall into two camps (particularly with respect to  
macros).  Either an implementation produces machine code which  
executes rapidly, *or* it has powerful syntactic and modular  
abstraction capabilities (with the possible exception of Chez).  I am  
particularly interested in the R6RS module system and the numeric  
operators.  Designed properly, and implemented, these systems would  
greatly improve the macro capabilities of the fast implementations,  
and possibly improve the speed of the "rich" implementations; this  
is a win-win situation for me.  Based on this (relatively unique)  
perspective, I am requesting the capability to vote on the proposed  
R6RS standard.


Name: Arto Bendiken
Location: Marbella, Spain

Mail: arto.bendiken@gmail.com
Web: http://bendiken.net/
Scheme has been my primary programming language for the past  
three years.
    I was drawn to it due to its elegant yet powerful core as well as  
the
    ready availability and accessibility of a great number of
    implementations.

    At present, I'm particularly well acquainted with the CHICKEN,  
Gambit-C
    and Gauche implementations of Scheme. I've also read a good deal  
of the
    available literature from the past three decades, and am on the  
path of
    graduating from being a mere user and contributor to becoming an
    implementor myself.

    My primary areas of interest in R6RS concern namespaces,  
portability and
    the standard library. Lurking on comp.lang.scheme and the R6RS  
discussion
    list for the duration, I've gained an appreciation for the tension
    inherent between the desire for minimalism on the one hand, and
    portability and practical usefulness on the other. I don't envy the
    editors' task in attempting to strike a balance on the matter  
given the
    diversity of stakeholders involved.

    R6RS seems to me a crossroads for Scheme as a programming  
language, and
    indeed for me personally; R6RS and its adoption by respective
    implementations will determine whether I will stick with Scheme, or
    whether I will set out in a diagonal direction, bootstrapping  
from R5RS
    to create something of my own.


Name: Donovan Kolbly
Location: Austin, TX, USA

Affiliation: RScheme Development Group
Mail: dmk@rscheme.org
Web: http://www.rscheme.org/~donovan/
Since the early 1990s I have worked on the RScheme implementation
of the scheme language, primarily as a platform to experiment with
language and system features such as object systems, modules, macro
systems (see my 2002 Ph.D. dissertation on this subject), and
persistent object storage.  More recently, I have been using RScheme
as a platform for rapid development of novel applications, to varying
degrees of commercial success.  My interest in the standardization
process is primarily in how hard it will be to (a) support the new
features required by the standard in RScheme
(RScheme strives to be standard-compliant, although since R5RS the
divergent macro systems have been troublesome), and (b) tweak existing
and conflicting implementations of certain features (such as modules)
to be compatible with both the new standard and with the RScheme
install base of applications.

I also currently serve as a SRFI Editor, so I have an interest
in the standards-track Scheme insofar as it defines the platform
upon which SRFIs are built.


Name: Reinhard Ruessau
Location: Nagold, Baden-Wuerttemberg, Germany
We have used Scheme at our school Otto-Hahn-Gymnasium in Nagold, Germany for several years now.
We used to work with various programmes in the course of years, among which were Pascal and Java.  At that 
time we have learned that Scheme is much better for the training of students. Particularly the graphic user interface
of DrScheme makes work for beginners with the programme very simple. You immediately get to the essentials with 
DrScheme without having to deal with a lot of unnecessary gadgets.
It is especially the compact notation  which really does help beginners and does support practical teaching. 
Sample programmes  often are so short that they fit on one board or one overhead transparency so that 
explanations become easy as you can see everything which is importance at a glance. 
The notation is relatively easy for the learner as it is based on  mathematical algebra. 
Thus you can easily link mathematics and computer science. As the computer language of Scheme is relatively limited, 
you can save a lot of time in contrast to other programming languages because you have to explain 
much fewer language elements. Neither the students nor the teachers have to deal with a lot of dead freight, which 
often distracts from what is really essential.


Name: Martin Gasbichler
Location: Urdorf, Zuerich, Switzerland

Affiliation: Zuehlke Engineering AG
Mail: martin@gasbichler.de
Web: http://martin.gasbichler.de
For me, Scheme is an excellent research
platform, first because it is easy to adapt the language to support
new features, but also because it includes features that are still
areas of active research such as continuations or hygienic macros. I
spent 7 years of research in the field of programming languages and
most of the time, I used Scheme as my starting point.

At the university, I have used Scheme for teaching students of all
grades and in my opinion . For beginners, the teacher has the
possibility to start with a small subset and extend the language
gradually when new areas of programming and programming languages are
covered. For advanced students, it is not only possible to teach
features such as concurrency or object-orientation with little startup
cost but also to show the implementation of these features within the
language itself. So, Scheme is a ideal tool for teaching as well.

The one thing that has been missing so far in the Scheme language is a
portable framework for building real-life applications. Having to
tailor my Scheme code to a specific implementation almost right from
the start took away a lot of room for improvement from my programs in
the past. I hope this will change real soon now and I will do my best
to support the adaption of my favorite Scheme implementation, Scheme
48, to R6RS.


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

Affiliation: Indiana University and Cadence Research Systems
Web: http://www.cs.indiana.edu/~dyb/
I am involved with Scheme as an implementor, researcher, educator, and
   user.  My interest in the standardization process is simple:  Scheme
   has been a useful language, at least for my purposes, and I want it to
   remain so.  As the needs of the community and individual users grow,
   and as the world outside of Scheme changes, this means that Scheme must
   grow and change as well.  Although views differ on the exact
   mechanisms, there has been a clear consensus since even before the
   features of R5RS were agreed upon 15 years ago that we need some sort
   of library system, some sort of record system, some sort of exception
   raising and handling system, and support for more general forms of
   syntactic abstraction.  The need for Unicode support has become clear
   since.  More generally, R6RS should support the construction and
   sharing of substantial, useful programs and libraries to a greater
   extent than did R5RS.  Yet, any changes need to be made in a way that
   doesn't destroy the character of the language, inhibit research and
   development of new and improved language features, make efficient
   implementation unduly difficult, or make the language less useful for
   teaching.  This is a difficult task, and I don't expect perfection. 
   People have widely differing opinions for what constitutes a good
   standard, and even my own opinions differ by viewpoint.  So we should
   expect compromises to be made and not to be happy with all of them.


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

Affiliation: Lycoming College
Mail: geoff@knauth.org
Web: http://knauth.org/gsk/
I have two main concerns.  The first is that R6RS specify a  
Scheme that increases modularity and fosters interoperability between  
implementations of Scheme, so that newcomers to the language will not  
be put off by differences, but rather will see more easily how to  
leverage existing code.  I am particularly fond of the SFRIs and the  
PLaneT archives.  The SRFIs are widely shared among implementations,  
and I'd be tickled if PLaneT could evolve via R6RS into a repository  
directly useful to more Schemes.  Second, there is a tension between  
not wanting to scare off new users, and keeping advanced users  
interested in Scheme.  Current experts love Scheme's role as a  
language with which one can create new languages, since the power of  
transformative techniques is almost unbounded.  For Scheme to remain  
relevant and continue generating productive and lively intellectual  
debate, it must preserve its attractiveness to the expert community.   
If I put these two goals together, R6RS should make life a little  
easier for the newcomer or the software integrator, without taking  
anything away from the expert.


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

Affiliation: Purdue University
Web: http://www.math.purdue.edu/~lucier/
I've used Scheme (mainly Gambit-C) for over 10 years for several purposes:
numerical computing (numerical methods for partial differential equations, image
processing, graphics generation, etc.); education (student projects in numerical methods
for partial differential equations, homework-on-the-web server for
pre-calculus students, general computing projects by me and my graduate students, graphics
generation, etc.); hobby/research (the Gambit-C bignum library, totally written in Scheme).

My interest has
generally been in speed of (unsafe) generated code, ease of debugging, full numeric
tower, proper tail recursion, good support for numerical programming.
For example, I added the first homogeneous vector implementation to the Gambit-C
runtime and compiler (which
Marc Feeley totally rewrote before it was first released to the public).
Lately I've become more interested in having "safe" code run reasonably
fast (perhaps I'm getting tired of debuging Scheme->C code with gdb).
I've spent time and energy since 1998 in reconciling Scheme with the
IEEE 754 arithmetic standards.

In support of my extensive use of the Gambit-C
Scheme->C compiler, I've participated in the GCC development
process for many years, mainly by testing development versions of gcc
on Gambit-C--generated code; this process has found several bugs and many
inefficiencies in the algorithms used internally in GCC, and the GCC
developers have been gracious enough to respond with better, faster
algorithms.  (Often, Gambit-generated code, which generally compiles a
complete Scheme file to a single C procedure, was the first to truly exercise
certain gcc algorithms, and so such extreme testing exposed O(N^2) or
worse algorithms.)

I also have an interest in random number generation, which is what motivated me
to participate materially in the SRFI-27 process.

So, my stake in the standardization process is as a heavy user,
especially of numerical code.


Name: Onnie Lynn Winebarger
Location: Indianapolis, IN, USA
I use Scheme to investigate various problems in programming languages
and mathematics.  I have an interest in preserving the aspects of the
language that make it so elegant and desirable to use, and its
location in the spectrum of programming languages and systems.  Scheme, in
its original and current form, serves as a excellent target for exercising
implementation techniques.  It also, like the lambda calculus which inspired
it, provides a basis for modeling all paradigms of computation, favoring none.

Scheme is the archetype of a language which reifies its internal constructs
in a sound manner.  Like the original LISP, its creation is a landmark
in language design and implementation.  In creating Scheme and RABBIT,
Steele (and Sussman) showed that (a) lexical scope was efficient, (b)
CPS is a feasible intermediate representation for compilation, and (c)
the metacircular approach to developing defunctionalized interpreters
described by John Reynolds was practical for designing and
implementing real languages.  In creating call/cc, they were ahead of
their time in demonstrating what Sabry and Wadler formally described
in "a reflection on call-by-value":  that constructs introduced in the
target language of a program transformation could be reflected back to
enrich the source language.

The ethic of parsimony in language design also was and is an important
part of the Scheme language.  As in mathematics and writing in other
human languages, less is more when the right formulation is found.
This ethic sets Scheme apart from most programming language designs.

I am certain I am leaving out many reasons Scheme is an important
language, but I believe I have given enough reasons to demonstrate a
reasonable interest in Scheme.  In particular, an interest that
whatever language is blessed by the name of Scheme be true to the high
standards and design principles of the original.



Name: Shriram Krishnamurthi
Location: Providence, RI, USA

Affiliation: Brown University
Web: http://www.cs.brown.edu/~sk/
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.  When, however, those weaknesses
and restrictions have been excised, the programming language should be
free to grow wings and fly.  That time is long past for Scheme.

Here is my stake in the Scheme community:

Roles: Software designer and implementor.  Textbook author.  Educator.
Community activist.  Usenet prognosticator.  Defender of the faith.

Actions: Build real systems in Scheme on which I stake my reputation.
Manage schemers.org.  Coordinate TeachScheme! workshops.  Jointly
initiated SRFIs.

Resources:

- Books: How to Design Programs.  Programming Languages: Application
  and Interpretation.

- Software: DrScheme programming environment.  PLT Scheme Web server
  framework.  FrTime functional reactive language.  Continue
  conference manager.  Margrave access control analyzer.  Resume
  faculty search manager.  MzTake scriptable debugger.  DivaScheme
  speech interface.  XeLda unit-checker for Excel.

- Projects: TeachScheme!.  SRFI.

- "Kickassing Genial" Talk: The Swine Before Perl.


Name: Aubrey Jaffer
Location: Boston, MA, USA

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


I am both a Scheme implementor and user.  Guile being derived from
SCM, mine is arguably the most widespread Scheme implementation.  As a
user, I have stretched the envelope for Scheme to an incredible
variety of applications, some of which are detailed below.

JACAL is an interactive symbolic mathematics program.  JACAL can
manipulate and simplify equations, scalars, vectors, and matrices of
single and multiple valued algebraic expressions composed of numbers,
variables, radicals, and algebraic differential, and holonomic
functions.

In 1990 I converted my symbolic math system from Common-Lisp to R3RS
Scheme in order to be able to run on small computers.  George
J. Carrette's SIOD: Scheme in One Defun compiled and ran on my
computer, but wasn't a full Scheme implementation.  So I converted
SIOD into the last C program I would ever need to write: the SCM
Scheme interpreter.

SCM's approach is unusual; it is not a byte interpreter.  Tom Lord
describes it as "essentially a hand-compiled partial evaluation of a
simple Scheme compiler coded in a lazy, functional style, composed
with a simple, imperative and eager-style graph-code interpreter".
Its approach is motivated by objective measurements of running time
and startup latency as described in several articles on my "Computer
Natural Science" webpage, http://swiss.csail.mit.edu/~jaffer/CNS.

Other major contributors to SCM are Radey Shouman, Jerry D. Hedden,
and Hugh Secker-Walker.

I wrote SRFIs 58, 59, 60, 63, and 94, which are implemented in SCM.

Since 1990 I have done nearly all my computing in SCM, which has
extensions and libraries to perform tasks as varied as
image-processing, scripting, and interactive HTTP-service.  SCM is
well suited as an extension language; and in 1995 became the basis for
Guile, Project GNU's extension language.

SCM development continues toward the APL paradigm of array (SRFI-63)
computation.  Instead of iterating a complicated calculation over each
element of an array, an APL interpreter can apply primitive
calculations to a succession of (temporary) arrays.  These simple
array primitives can be compiled (in the runtime library) to use
native vector-execution operations.

For programs operating on regular data structures of more than a few
elements, the overhead of interpretation will then be negligible.
Although this paradigm may use more memory than serial element
replacement, the arrays will usually be compact in the cache.

Radey Shouman has implemented some whole-array arithmetic operations
in SCM.  I hope the full APL set will eventually be supported by SCM
and SLIB.  APL computation in Scheme would reduce the interpreter
penalty to the point that interpretation (versus compilation) would be
sufficient for many scientific programs.

APL, like Scheme, is a functional language.  Unlike Scheme, most of
its operators are inherently parallel.  Incorporating APL primitives
would seem the straighforward way to break Scheme's serial
straitjacket.

SLIB is the largest and longest collaboration facilitating portable
(implementation-neutral) Scheme for non-trivial applications.  Its
breadth is comparable to libperl, but with higher quality, unified
documentation, and better integration between modules.

SLIB supports Bigloo, Chez, ELK 3.0, GAMBIT 3.0, Guile, JScheme, Kawa,
MacScheme, MIT/GNU Scheme, PLT Scheme (DrScheme and MzScheme), Pocket
Scheme, RScheme, scheme->C, Scheme48, SCM, SCM Mac, scsh, Stk, T3.1,
umb-scheme, and VSCM.

I founded the SLIB Scheme Library to supply those elements of the
richer Common-Lisp function set which JACAL uses.  SLIB has grown to
encompass a broad spectrum of capabilities, from color to
discrete-Fourier-transforms to sequence-comparison to
relational-databases.

SLIB is written in R4RS Scheme.  How can it manage without a module
system?  Through the judicious use of prefixes in names; and because
it is a curated (by Radey Shouman and myself) library.

I wrote SRFIs 59, 60, 63, 94, and 95, which correspond to SLIB
features.

A talent with parsers and translators, all written in Scheme, has
enabled me to work in the Scheme language through much of my career in
electronic and software design.  The SCM script "Schlep"
(http://swissnet.ai.mit.edu/~jaffer/Docupage/schlep.html) translates a
list-less subset of Scheme into ANSI-C code.  Originally developed to
implement the WB B-Tree C library, it has been used to implement
complex Linux kernel drivers for video decompression boards.  These
boards were designed using the SIMSYNCH digital simulator (also in
Scheme).  The SIMSYNCH board simulations ran together with the Scheme
kernel driver source, enabling early debugging and dramatically
reducing hardware/software integration effort.  And SIMSYNCH
translated the Scheme circuit designs into Verilog or VHDL for logic
synthesis.

SIMSYNCH is a simulator for digital electronics at scales from chip to
board.  Design files are composed of Scheme definitions and
expressions.  These design files can be run as a Scheme program at
high speed.  SIMSYNCH has programs which translate the design files
into formats suitable for logic compilers (MACHXL, VHDL, and Verilog).

"Schmooz" (http://swiss.csail.mit.edu/~jaffer/Docupage/schmooz), also
written by Radey and me, creates a TeXInfo (documentation) file from
specially formatted comments at top level in Scheme source.  The
Schlep, Scm2Java, and Scm2Cs SCM scripts also produce TeXInfo files
for their target language APIs.

"Pas2scm" (http://swiss.csail.mit.edu/~jaffer/Docupage/pas2scm)
translates Pascal programs to Scheme.

On http://swiss.csail.mit.edu/~jaffer/Scheme, my scheme program
rrrs2txi.scm translated the LaTeX r3rs, r4rs, and r5rs to texinfo
format (r3rs.txi, r4rs.txi, and r5rs.txi), from which the online HTML
versions were derived.

WB (http://localhost/~jaffer/WB) is a B-Tree, sorted associative array
library.  It is fast and reliable, routinely handling database file
sizes of several hundred MB.

WB is a Scheme-intensive project.  The source code is written in a
list-less subset of Scheme; the test code exercising all the limit
cases for block splits and deletes is written in Scheme.  SCM scripts
(Schlep, Scm2java, Scm2cs) are used to translate the WB Scheme source
code into C, Java, and C#.  The libraries compiled from these
different languages (and databases created by them) inter-operate
transparently.

WB includes a SCM interface to the WB C-library and an identical
interface to the (Scheme) source.  Thus the same test code can be run
against source and compiled versions.

Other major contributors to WB are Jonathan Finger, Roland Zito-Wolf,
and Ravi kiran Gorrepati.

WB includes a higher-level SCM interface to WB which supports SLIB
relational and relational-ISAM databases.  With integer and IEEE
floating-point numerical keys having numerical collation order,
RWB-ISAM is well suited to storing and manipulating sparse numerical
data sets.  SLIB's database-interpolate module emulates continuous
functions from stored measurements.

A Numerical relational-ISAM database is used by FreeSnell
(http://swiss.csail.mit.edu/~jaffer/FreeSnell/), a program which
computes optical properties of multilayer thin-film coatings.
Dielectric, metallic, and granular metallic films are supported.  It
includes utilities to create, manage, and query its large spectral
refractive-index database.

So, in addition to a large body of Scheme code for proprietary
electronic design, simulation, and software, I have initiated,
organized, coordinated and coded several large, multi-author, free
software projects encompassing over 70,000 lines of Scheme code.




Name: Jude Arnout Durieux
Location: Bamako, Mali

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

The world already abounds in more or less interesting programming
languages,
and turning Scheme into yet another one would constitute a real loss.
Scheme ought to try capturing the platonic ideal behind these languages,
and people should be justified in assuming 'This is the correct way,
because this is how Scheme does it.'
I certainly encourage extensions to Scheme to make it a practical
general-purpose language,
but such extensions should be clearly labelled as such:
(preferably standardised) extensions, not Scheme itself.
I have been programming Lisp since 1980, Scheme since 1985, and teaching
it since 1986 or so,
and I have always immensely enjoyed the awakening insight in my
students:
'This is how programming is supposed to be!'
Other languages often do things in a certain way because,
well, one must make a choice, mustn't one?,
but Scheme does it consistently because it is the correct way.
Once that insight has come, the Scheme way becomes the *obviously*
correct way
- which of course often means: 'a certain way implemented in Scheme is
the obviously correct way',
but that's how it ought to be: in different situations, different
solutions are obviously correct,
but they always transparently reduce to the platonic assembly language -
Scheme.



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

Affiliation: Fraunhofer Gesellschaft
Mail: thomas.gordon@fokus.fraunhofer.de
Web: http://www.tfgordon.de
I am a senior research scientist at one of Europe's largest  
research organizations for computer science, the Fraunhofer  
Gesellschaft.   (Fraunhofer is perhaps best known as one of the  
developers of MP3.)  Most of my research has been in the field of  
Artificial Intelligence, on topics such as knowledge representation,  
nonmonotonic logic, planning and computer models of argumentation,  
with a focus on legal applications.  I am the current president of  
the International Association for Artificial Intelligence and Law.  I  
have been doing research in the field of AI since 1984.   Scheme has  
been my preferred language for building research prototypes, starting  
with my work on OBLOG in 1986-87.  (See http://www.tfgordon.de/papers/ 
papers.html for a list of publications.)  Most recently I have used  
Scheme in a computational model of argument, called Carneades.  An  
article about this work has been accepted for publication by the  
Artificial Intelligence Journal (in press).

   So my interest in R6RS is as a user of Scheme for over 20 years.   
My research is not conducted in isolation, but in teams, for example  
as part of European research projects with many partners.  And  
Fraunhofer is expected to work closely with industry to produce  
innovative products.  It has  always been a struggle for me to have  
Scheme accepted for use in these projects, due to the small size of  
its user community, the small number of libraries and the lack of  
portability between implementations. In the 80s the struggle was with  
Common Lisp.  More recently with Python and, especially, Java.  I've  
been hopeful of a breakthrough for Scheme at various times over the  
years, for example when Apple announced its Dylan project, when it  
appeared Sun might support Scheme in a big way, before it focused  
instead on Java, and when Scheme was adopted by James Clark for use  
in the DSSSL ISO standard, in connection with SGML.  (Incidentally, I  
may have had some small influence on the choice of Scheme for DSSSL.   
I was the developer of the qwertz document processing system, which  
used SGML, and was later used for the Linux documentation for several  
years.  During this time James Clark and I had a brief email  
discussions about DSSSL in which I may have promoted Scheme.)

   My hope for Scheme is that it will become a viable alternative for  
building not only research prototypes but also commercial  
applications.  Other languages used by industry are becoming more  
like Scheme as time proceeds.  There is a renewed interest in  
functional programming, as evidenced for example by Microsoft's F#  
project, Sun's recently announced javaFX Script language and Martin  
Odersky's Scala language.  Or the functional features of Python.   
None of these languages are better suited for my research on  
knowledge representation, reasoning and argumentation than Scheme,  
since I make extensive use of symbolic expressions and macros for  
building what has come to be called 'Domain Specific Languages', by  
extending Scheme.  There is a window of opportunity for Scheme at the  
moment and R6RS, if adopted, would help Scheme to take advantage of  
this opportunity.

   Following the debates on the Scheme newsgroups, my feeling is that  
much of the opposition to R6RS is coming from some of the  
implementors (e.g. Bigloo, Gambit, Chicken, SCM).   Although it would  
be a shame to lose their support, from my perspective as a user I  
would be willing to take this risk, if it is the price to pay to have  
a viable standard.  Of course implementations are essential for  
viability. But, judging by the success of Java, Python, and Perl, for  
example, we do not need many implementations.  A few good ones would  
suffice.  If Chez, MzScheme, Scheme48 and Larceny would all work  
together to support R6RS, I am optimistic that Scheme has a good  
chance to succeed.

   I have no sympathy for those who want to keep the Scheme standard  
minimalistic and 'pure'.  I do not understand why the interests of  
those who prefer such a small language are not already served by R5RS  
or even older versions of Scheme.  Indeed, I do not understand why  
people primarily interested in teaching computer science or  
experimenting with programming language design require any standard  
for their work.  Was the huge success of Abelson and Sussman's course  
on the Structure and Interpretation of Computer Programmers, which  
uses Scheme, in any way dependent on some Scheme standard?

   To be fair, my work also does not depend on their being a Scheme  
de jur standard, but only on there being some de facto standard.  If  
R6RS fails, I can only hope that at least one Scheme implementation,  
preferably PLT Scheme, which I now use, grows and prospers, to become  
a viable competitor to such languages as Python or Ruby, which also  
do not have standards.  It seems odd to me that the implementors  
opposed to R6RS might prefer this scenario, where they would lose all  
influence on the future development of Scheme.


Name: Alex Shinn
Location: Tokyo, Japan

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

I've been an active member of the Scheme community for over five years,
participating in the SRFI process and contributing to a number of
implementations, most notably Chicken and Gauche.  All of my personal
code, without exception, is written in Scheme; the HTTP server running
my site is implemented in Scheme, and I've implemented an SMTP server, a
text editor with vertical text layout, a video game, and numerous
Unicode and linguistic utilities, all in Scheme.  I've participated in
the past 3 ICFP contests using only Scheme.  I think in Scheme.

Using multiple Scheme implementations has always been a source of
difficulty for me, and I've tried many approaches to writing portable
code, including the abandoned tongue-in-cheek "common scheme" project.
More recently, in desperation, I've been working on my own compiler with
C and native x86 ASM backends, and am deliberating which standard to
align it with.

This Fall I will begin graduate studies in computational linguistics,
and intend to use Scheme for my research.  Several other students in the
lab use Scheme, and I hope to encourage its use even further.
Standardization and interoperability of implementations is an important
factor when proselytizing to a language.

But mostly, Scheme is the only language that is beautiful to me, and I
want to ensure that it stays that way.


Name: Hans Oesterholt-Dijkema
Location: Zutphen, Gelderland, Netherlands

Affiliation: ICT Architect
Web: http://www.elemental-programming.org
I'm curious why a stake statement should be more original than 
'I'm depending on this programming language for my daily work'. However,
I'll try to be original. I'm currently using scheme to write business programs.
Being practical, but also loving beautifull languages, I have adopted
scheme some years ago, both because it is a clean language, but also
because it is such a powerful language. The macro language is both clean
and extremely powerful. It always makes me curious why so many people
use Java, which is a cripled language compared to scheme. However, I'm
also a practical guy. The scheme community is a scattered community. 
Everyone wants his or her own implementation of scheme. Because of this
a new RSRx specification is in my opinion very important. The RSRx specification
keeps scheme implementations at least somewhat standardized. Of course,
the SRFI process also helps standardizing scheme implementations. I think, scheme 
programs should be easily portable between different scheme implementations and
RSR6 will help that a lot.


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

Affiliation: Starfire Optical Range
We use Scheme in an electro-optics laboratory to efficiently  
develop and control precision devices such as telescopes and dynamic  
optical systems.  Scheme could be used to improve more aspects of  
laboratory software such as data distribution, executive control of  
experiments, and algorithm research.  However, programmers and  
managers avoid Scheme because they perceive languages like C++ and  
Java to be standards of the software profession.  For broader  
acceptance, Scheme's elegance needs to be exploited to give it an  
obvious advantage over other languages: a genuinely portable standard  
that includes macro and library systems.  The conformist languages  
have proven to be so cumbersome in the hands of typical programmers  
that scientists and engineers have gradually chosen to write much of  
their own software, leading to legacy programs that lack the wisdom  
that computer scientists could have provided.  Scheme is an ideal  
language for the laboratory because novices could use it for concrete  
tasks like managing experimental data, yet experienced computer  
scientists could research more abstract problems such as creating  
programming environments for long term experiments.  R6RS Scheme will  
enhance the argument that a laboratory that is critically dependent  
on computations can benefit from computer science as much as the  
physical sciences.


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

Affiliation: SAIC, Inc.
I have been using the Scheme language for teaching and small
development 
efforts for over 15 years.  More recently, I have been using Scheme, 
specifically PLT Scheme, to develop larger-scale knowledge-based 
simulation applications.  Elements of this knowledge-based simulation 
capability have been released as open source software for use within 
the wider (PLT) Scheme community.  Currently, in spite of the existence 
of a standard for Scheme and corresponding Scheme Request for 
Implementation (SRFI) packages, this level of production quality code 
is not readily portable across different Scheme implementations.  For 
Scheme to grow into a language that can support production quality 
code across implementations, the Scheme standard itself must address
these 
issues of programming in the large - i.e., how are complex applications 
structured in a portable manner.  This should include mechanisms 
to specify and validate interface characteristics (requirements) 
between application components in a portable manner.  In the past, the 
Scheme standard has focused on programming in the small - i.e. the 
language elements needed to specify the data and algorithms in a 
flexible manner.  While necessary, these are not sufficient to allow 
Scheme to grow into a production quality language.


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/
I am a professor in the astronomy department of a research
university. I use Scheme almost daily in my research and teaching.
However, pure R5RS Scheme is inadequate for many problems, both large
and small, especially in my research. For example, it is difficult for
compilers to generate efficient code for inexact arithmetic since they
cannot rely on the bindings of the arithmetic procedures, there are no
means to access binary data in files or in memory, and I cannot write
the name of my university as a string, as ASCII has no accents. I end up
either using extensions to the R5RS or writing chunks of code in C and
accessing them as foreign procedures. Neither of these approaches are
portable and the second is extremely unpleasant. I would like to see
Scheme develop in a way that makes it easier for me to use it for 
solving a greater range of problems without losing the ability to write 
quick hacks. I am not saying that I want Fortran or Java with a REPL and
first-class continuations, but I would like the next Scheme standard to
allow me to write less C and more standard Scheme.



Name: Brian Jaress
Location: Honolulu, HI, USA

Web: http://brian-jaress.livejournal.com
I'm a programmer who's fairly new to Scheme.

To me, the most important proposed changes in R6RS are the standard
module system and the standard libraries.  The core language in R5RS is
great, but the decision to use it always seems to create extra work
because of missing libraries.  There are extensions for most of the
basic things that usually come with a language (sorting, hash tables,
modules, etc.) but the fact that they are nonstandard creates extra work
of its own as far as compatibility and portability.

I haven't looked at every detail of the module system and libraries, but
they look a lot better than nothing.

One thing I'm not enthusiastic about in the current draft is the fact
that the built-in procedures are still not polymorphic.  For example,
having a single procedure called 'sort' that checks the type of the
argument to be sorted is perfectly possible.  It might be a little
faster to have a separate 'list-sort' and 'vector-sort,' but I don't
think it's worth it.  I also think there's no real benefit to explicitly
stating the type when you sort it.  When you're creating or using it,
maybe, but not when you're sorting it.


Name: Eli Barzilay
Location: Cambridge, MA, USA

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

I have been using Scheme for about 15 years.  After going through
several programming languages, Scheme was the one that immediately
caught my eye in its aesthetics -- both of code, and of its design.  I
have been a TA in various SICP-based courses (in Ben-Gurion University
in Israel, in Cornell University in New York, and also in a startup
company), and most of my hacking has been in Scheme.

My first well-known Scheme project was Swindle -- developed for
Cornell's CS212 course (previously used a buggy Dylan implementation).
The project started as a practical implementation of the Common Lisp
Object System (based on Tiny CLOS from Xerox), and grew to provide
more Common-Lisp-like functionality.  It was used in CS212 for several
years.  Throughout the years I hacked together a number of projects at
various sizes, mostly as a free-time hobby.

After finishing my PhD, I moved to the Boston area, and joined the
Northeastern part of the PLT team.  With that I could finally get to
make my living writing Scheme.  (Something that is not easy to come
by.)

In practically every aspect of my involvement with Scheme it was clear
that as good as it may be, it suffers from major limitations.  Over
and over again I had to justify Scheme in class, convince people that
Scheme is a practical solution.  IMO, the Scheme world suffers from
the reputation of being a (mostly pedagogical) toy -- a language whose
proponents take pride in an extremely short definition, even when it
is painfully clear that this makes real-world code impractical.  The
result is a fragmented community with different factions relying on
practical features found in different implementations, and too much of
wasted efforts by good programmers.  "Scheme" as a language suffered
loss after loss to many inferior languages (shell scripts,
miscellaneous extension languages, TCL, Perl, JavaScript, Python, and
many more).  A few projects that have been using Scheme would suffer
the same problems, some died (SCWM), some switched their focus away
from Scheme (Gimp).

All of this pushes "Scheme" to being an abstract concept -- a
generic name for a family of similar implementation-defined languages.
I see the R6RS effort as a step in the right direction.  A more
practical definition and a module system would allow more practical
code to be written and shared, making Scheme stronger.



Name: Kyle Cronin
Location: Bangor, ME, USA
I started programming in BASIC in sixth grade. In high school I
moved on to C++ and Java, but I found the limitations and seemingly
arbitrary restrictions frustrating. Senior year I found Paul Graham's
essays and immediately became enraptured by the tantalizing promise of
the simplicity and flexibility of the Lisp language, so I set out to
learn what it was all about. I took a copy of SICP out from the
library and began reading it. Initially I was turned off by the prefix
notation and the seeming lack of iteration built into the language,
but I quickly realized the power behind the simplicity of the
language. Freshmen year I was delighted to discover that my
introductory course was taught in Scheme, and while various classes
since then have required other programming languages for assignments,
my own work is always done in Scheme. I'm very interested in being
involved in the future of the language, and I hope that R6RS should
pave the way to greater Scheme adoption and interoperability.


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

Affiliation: Seton Hall University
I am a Schemer! Ein ich Schemer! Yo soy un Schemer! Programming
languages that have a standard tend to be successful. A standard
allows for code developed using standard features on different
implementation platforms to be executed on all the platforms.
Furthermore, it allows reserachers to develop new tools without having
to worry about many platform-specific nuances. Finally, it allows
educators to teach knowing that the standard features employed will be
found by students in the implementation of their choice. As a
researcher in the implementation of functional languages and as an
educator that uses Scheme at all levels of the undergraduate
curriculum, I feel that it is important for Scheme to have a
definition that all its user communities can refer to and can use as a
basis for its evolution. A standard provides a context through which
we can all communicate and move forward.


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
As an Assistant Professor in Computer Science, my interest in the Scheme
  programming language originates from both teaching and research.  First, I
  am in charge of lectures of functional programming for undergraduate and
  graduate students.  In the first case---for undergraduate students---the
  lecture aims to introduce scientific students to a programming close to
  Mathematics, and I wrote a coursebook in French about this approach.  In the
  second case---for graduate students---I aim to illustrate advanced features
  of functional programming such as delayed evaluation, continuations, macros.
  Scheme is the support language of these two lectures.  Second, I am
  developing a bibliography processor that aims to replace BibTeX, the
  bibliography processor usually associated with the LaTeX word processor.
  This program, MlBibTeX for `MultiLingual BibTeX', is written using Scheme,
  it is R5RS-compliant and uses some definitions given by SRFIs.  After some
  confidential diffusion whose result is encouraging, MlBibTeX is about to be
  publicly available.  So I am interested in the future of Scheme in order to
  be fully able to improve this program for future versions.


Name: Jacob Jozef Anthonius Koot
Location: Spain Barcelona Mataro

Web: http://www.telefonica.net/web2/koot/
I am interested in a widely accepted Scheme standard for several reasons:
   1: Scheme is a very good tutorial language for:
      1a: learning programming:
            simple syntax,
            no unexpected or hard to swallow semantical restrictions,
            not prone to bugs,
            a mathematically sound number system,
            good tools for data abstraction,
            avoids the beginning student from thinking in terms of machine 
representations,
            many Scheme implementations provide very good syntactical analysis 
and debugging facilities.
      1b: learning about programming techniques, paradigmas and so on (there is 
an abundance of good text books using scheme for this purpose)
   2: Scheme is a very good and flexible language for fast prototyping of:
      2a: algorithms.
      2b: languages and language extensions.
      2c: for trying and comparing different approaches of language features
         (for example my individual interest in the comparison of different 
treatments of side effects in lazy interpreters)
   3: Some languages feel like a set of restrictions rather than a comprehensive 
tool, especially when it is clear that an implementation employs constructs that 
at the same time seem to be denied to the user of the language. Scheme makes me 
feel that I am given the full power of all tools used by the implementors 
themselves.


Name: Sven Hartrumpf
Location: Hagen, Germany
I have been using Scheme for more than 10 years and around 100,000 lines
   of code. I always tried
   to ensure portability by running my code in around 10 different
   Scheme implementations. Unfortunately, this was not always easy.
   But I never regretted not to rely on non-portable extensions of
   one of the major implementations. A second issue important for
   my applications is efficiency. So, I expect better support for
   efficiency and portability from R6RS. For efficiency purposes,
   the standard should not require any behavior which puts a large
   difference in runtime between say C and Scheme. For portability, I
   hope that the standard libraries will help real-world programmers
   a little more than R5RS did. And finally, it is important to have
   R6RS and the most important (and most popular) SRFIs to live together,
   maybe after some phase of adaptation. The authors of these SRFIs
   should be encouraged to adapt their SRFIs to R6Rs. Even with more
   standardized features, the community efforts like the SRFI process
   and some portable package collections like SNOW are not to be
   neglected. My main concern with R6RS is that it could further
   split the community instead of helping to create synergies of the
   major subcommunities like Bigloo, Chicken, Gambit, Gauche, and PLT.


Name: Jonathan Rees
Location: Cambridge, MA, USA

Affiliation: Creative Commons Corp.
Mail: jar297@mumble.net
Web: http://mumble.net/~jar/
I like to write programs in Scheme, to the extent that I have
   implemented Scheme several times to make it easier for me to do so
   (T, Pseudoscheme, Scheme 48).  I have helped with previous
   agreement-building efforts (R2RS, R3RS) because I like for other
   people to use Scheme, so that I can use and learn from their work
   and so that they can appreciate mine.  I use Scheme daily in my
   work and have invested a significant part of my career in helping
   it to succeed.

   As a Perlisian 'ball of mud' Scheme lends itself to extension and
   experimentation.  Scheme's boundaries have always been aggressively
   sloppy.  Scheme's emphasis on programming for communication, as
   opposed to execution, is almost unique and has had, I think, a
   positive effect on its culture.  Although Scheme has been used as
   an engineering tool, engineering goals such as portability,
   security, and efficiency have on principle never been embraced in
   the past.  They factor into the design, and they influence
   implementations, but they have always played second fiddle to ease
   of reading, writing, and remembering.

   Although successive Scheme reports have made the language
   increasingly complicated and have included many decisions that are
   not to my taste, I have embraced the reports in order to help
   develop a community around the language.  Compromises are always
   necessary in standardization efforts.  I would just like to make
   sure that Scheme's message to the world, that what we somewhat
   misleadingly call 'programming' can be considered an intellectual
   endeavor that can carry the best of scientific and criticial
   thought, can be retained as it grows.  To relegate Scheme to the
   service of transient engineering concerns and accidents of current
   software practice would be tragic, as its unusual philosophy is
   what distinguishes it from its many imitators.


Name: Adrien Pierard
Location: Paris, France
I have encountered the Scheme language twice in my life. First as an
undergraduate student, and then as a graduate student. I am now involved in
doing some research dealing with languages semantics and I highly rely on
Scheme to experiment new concepts.

I think that Scheme's semantics and standard are not perfect yet, and that
it deserves major involvement for gurus as well as newcomers, in order to
improve the whole language. I reckon that well defined semantics as well as
eager for comments about the language are necessary to attract new
researchers and programmers. Moreover, the simple yet powerful design of
Scheme makes it a tool of choice for research, provided all implementations
agree on well defined foundations. As a user of one (or two) specific
implementations, I think that I have a personnal idea of Scheme that
deserves being shared with others and compared for the best of all of us.

As a now daily (and most of the time happy) user of Scheme, I feel the urge
to get involved in the evolution of the Scheme language.

Long live Scheme !


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

Affiliation: Grinnell College
Mail: stone@cs.grinnell.edu
Web: http://www.cs.grinnell.edu/~stone/
        I teach courses in computer science at a small liberal-arts
college.  We use Scheme in our introductory course because its simplicity
and expressiveness enable our students to understand some of the key ideas
of computer science -- notably recursion, procedural abstraction, and
data abstraction -- quickly and accurately, without the encumbrances of 
fragile syntax and quirky semantics.  We also use Scheme in more advanced
courses (such as our courses on programming languages, algorithms, automata
theory, and computational linguistics), particularly for small, 
specialized examples and demonstrations.  My interest in the R6RS standard
is to keep the core language small, simple, expressive, and accessible to
novice programmers, while accommodating, through the development of
libraries, the vast increase in the effective range and usability of Scheme
during the fifteen years since the publication of R5RS.

        I am also working on a small textbook on algorithms in which the
code examples are presented in a purely functional subset of Scheme.  This
work gives me an additional interest in R6RS:  I'd like to be able to use
standard library mechanisms to control the subset explicitly.


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

Affiliation: Northeastern PLT
Mail: samth@ccs.neu.edu
Web: http://www.ccs.neu.edu/~samth/
I am interested in Scheme for three primary reasons. First, as a programmer
   Scheme is the primary language I use to create programs both large and
   small.  Therefore, the advancement of Scheme and the greater portability
   offered by improvements to the Scheme standard are of great use to me.
   Second, as a programming language researcher, Scheme represents an
   important tradition in the design of programming languages, and one the
   should be continued, with innovations in the relevant areas such as
   continuations, macros and module systems.  Finally, I am the designer of
   Typed Scheme, a statically typed dialect of Scheme.  I am therefore
interested
   in the continued success of Scheme as a substrate for Typed Scheme, and as
   a complementary language, since Typed Scheme allows for the integration
   between statically typed and dynamically typed Scheme code.  Typed Scheme
   also utilizes advanced module and macro system features to function as a
   layer on top of Scheme, some of which are under consideration for R6RS.


Name: Ryan Culpepper
Location: Boston, MA, USA

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


I am a graduate student, and the focus of my research is the Scheme
macro system. My goal is to make it easier for programmers to
understand Scheme's hygienic macro system and to write clear, robust
macros. To the first end, I have created a stepping debugger for
Scheme macros as a tool that runs within DrScheme, a popular Scheme
programming environment. To the second, I am investigating alternative
notations for defining macros.

To me, the defining characteristic of Scheme is its powerful hygienic
macro systems. Other languages may be lightweight implementations of
"the lambda calculus plus useful features." Scheme is unsurpassed,
however, in its support for extending the language with new syntactic
forms with a minimum of fuss. Particular Scheme implementations have
pushed macros far beyond the capabilities described in R5RS. The
Scheme standard should not fall too far behind the state of the art in
this area.




Name: Ogechi Nnadi
Location: Atlanta, GA, USA

Affiliation: Georgia Tech, as at 2007
Scheme is a functional language with a simple syntax and with all
the features one could want in a functional programming language. It
was the first functional programming language I ever learnt and I
enjoy coding in it a lot. If the standardization that will gradually
begin to occur by publishing R6RS will produce the uniformity that C,
Java, and Haskell have, then I am all in favor of it.

The simplicity of Scheme makes it very suitable for teaching. I am
interested in one day teaching Computer Science and so I would like
for the language not to stagnate, but to continuously improve and
become an even better teaching and programming language.

Finally, my aesthetic preferences lie with simplicity. In agreement
with the quote in the voter registration ticket, I must say, Scheme
does efficiently do what many other languages achieve via horrid
syntax and complicated semantics. If Scheme were to die off (by way of
first stagnating), the whole world--and I in particular--would lose a
beautiful beautiful language.


Name: Konstantin Matveev
Location: Moscow, Russian Federation
I want useful language. All features of Scheme language help it to be
useful. Small is one side of been useful. Programmable is another side.
Expressive is yet another side.
  But something is still missing. Core language makes an impression that it
is useful only for logical puzzles and math tasks.
  Scheme is small language, but it should be useful for writing large
programs. Scheme too much interpretation-oriented, it should grow to allow
independent development, compilation and packaging.
  I like Scheme not for blind minimalism, but for orthogonal approach to
features. Scheme should include features which are orthogonal to existing
features, which are
  found useful by language users, which included in several implementations.
Wheel is basic, and should not be re-invented.
  Scheme minimalism allowes implementors to experiment with new features,
but some of those features are already mature and known to be required by
users.
  We need next standard, so bigger range of programs whould be portable
accross implementations.


Name: Dominique Boucher
Location: Montreal, QC, Canada

Affiliation: Nu Echo Inc.
Web: http://www.iro.umontreal.ca/~boucherd
I have been a Scheme programmer for the past 15 years now, and for
the past 6 years as a professional programmer. My PhD thesis was about the 
optimization of multi-module Scheme programs. I am also the author of some 
popular Scheme libraries and tools, like lalr-scm (a portable parser 
generator) and SchemeScript (a Scheme environment for the Eclipse platform), 
and I blog regularly about Scheme (theschemeway.blogspot.com). Finally, I am 
the main organizer of the Montreal Scheme/Lisp User Group since 2003 and I 
push hard for the use of Scheme in the industry.

I strongly believe that Scheme has an important role to play both in 
academia and the industry. It has influenced many other programming 
languages in the past and will certainly continue to do so in the future. It 
also has an important role to play in the Computer Science curriculum.

I am very much interested in results of the R6RS ratification process
as this will definitely impact my daily use of Scheme in industrial 
settings.


Name: Arjun Guha
Location: Providence, RI, USA

Affiliation: Brown University
As a student of programming languages and a Scheme user for the  
last five years, I often use Scheme for both research and  
programming.  That last statement is a bit too generous, for I’ve  
used PLT Scheme exclusively.  R5RS was a great little language for  
exploring algorithms and simple syntactic forms.  But, it was far too  
little to be useful in any way.  I could keep up my past trend of  
ignoring the Scheme standard, but I’ve noticed that R6RS is taking  
steps to address many of the inadequacies of R5RS that affected me.   
It is in my interest as a programmer and a researcher for there to be  
a Scheme standard that allows me to write large-scale programs, and I  
feel that R6RS is taking steps in this direction.  Therefore, I have  
a stake in ratifying (or not ratifying) R6RS, as it will affect  
Scheme implementations of the future, including those that I use on  
an everyday basis.


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

Affiliation: University of Massachusetts/Boston
Web: http://www.cs.umb.edu/~offner
I am a part-time instructor at UMass/Boston (with the working
title of Industry Professor of Computer Science).  One course I
teach frequently is cs450, which is mainly based on the
Abelson-Sussman-Sussman SICP book.  Partly as a result of
teaching this course, and partly as a result of my own work in CS
research and compiler design, I am impressed and interested in
styles of functional programming and in Scheme in particular.
Scheme seems to me to be distinguished from other functional
languages in its fundamentally bare-bones approach.  The language
contains a relatively small set of powerful primitives that can
be used to model features found in different languages, and
different styles of programming.  This makes Scheme a wonderful
choice for an undergraduate course in what would be called
comparative linguistics in the humanities departments.  I hope to
see this aspect of Scheme preserved; it has been very useful to
me and to my students.


Name: Bob Burger
Location: Indianapolis, IN, USA

Affiliation: Beckman Coulter, Inc.
I am interested in R6RS because at Beckman Coulter we have used
Scheme for the past decade and hope to continue doing so for another
decade. We have used Scheme for product development, testing, and
research. We love the flexibility that Scheme gives us to try out new
ideas. Scheme itself is very simple and doesn't change very often,
which helps us become very proficient using it. Because it provides
good procedural and syntactic abstraction, we can tailor our code to
the task at hand. Its handling of tail calls and continuations are a
breath of fresh air compared to the fixed-size, single-segment stack
model popular today.

I was introduced to Scheme while a student at Rose-Hulman Institute of
Technology, but I did not come to understand its utility until I went
to Indiana University for graduate school. Kent Dybvig, Dan Friedman,
and others taught me how Scheme is well suited as a meta programming
language for experimenting with lots of different ideas ranging from
digital hardware design to high-level programming language constructs.

In 1997 I started working for Beckman Instruments, now Beckman
Coulter. My first task was to design a new scheduler for automating
assays used in drug discovery laboratories. Customers use our SAMI(R)
software to describe the experiments they would like to run using a
graphical flow chart language. Our software then schedules and
coordinates the operations of the robot, pipettors, readers, and other
devices to perform the experiments efficiently.

The previous scheduler was written in C++ and had a few bugs that
customers had encountered. Even though my manager was unfamiliar with
Scheme, he allowed me to write the new scheduler in Scheme. He was
very pleased that I developed a prototype quickly, thanks in large
part to Scheme's automatic storage management system, continuation
support, and extensible syntax facility. These language features help
me build powerful abstractions that are impedance matched with the
problem.

In 1998 we released SAMI 2.0 with 15,553 lines of Chez Scheme code.
Customers were pleased with the product, and it proved to be very
stable. Subsequently we developed a COM interface to Chez Scheme and
have used it over the years to provide an easy way to interoperate
with other programming languages.

In 2002 we undertook an ambitious project to rewrite SAMI to provide
greater flexibility for systems with multiple robots. In October 2004
we released SAMI 4.0 with 103,614 lines of Chez Scheme code and
214,208 lines of C# code. The Scheme code employs multi-paradigm
programming. It uses continuations to perform non-blind backtracking,
the macro system to emulate a simplified version of C#'s object
system, and one-shot continuations to provide Erlang-style message
passing among light-weight processes for robust asynchronous
communication with the various devices.

A colleague of mine used Chez Scheme to develop an instant messaging
server using message-passing style that has been extremely robust for
the approximately 130 users across Beckman Coulter's internal network.

We plan to use Scheme in future products.  A project to develop a new
molecular diagnostic device and another pproject to develop a data
manager for hospital laboratories will both likely use Scheme because
of its flexibility and robustness in multi-paradigm programming.


Name: Danny Yoo
Location: Worcester, MA, USA

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


Scheme is a leading representative of a clean language for algorithms.
I have an interest in Scheme as used in education and practice.  The
upcoming standard will strongly establish Scheme as a preeminent
language for both teaching and practical programming.

One of the deficiencies in the current standard, the lack of a
specified module standard, is crucial for programming in-the-large.
It is important enough that each substantial implementation of Scheme
has reimplemented their own system for linking modules together.  This
reinvention unnecessarily splinters the community.  Other additional
features specified in R6RS, such as records/structures are features
that every realistic program uses.  A substantial Scheme program
should be portable, but as it stands now, most substantial Scheme
programs are tailored toward a specific implementation.

I would like to see Scheme more widely accepted in the larger
programming community, and I see the new standard as a step toward
wider acceptance and adoption.




Name: Matthias Felleisen
Location: Boston, MA, USA

Affiliation: PLT
Web: http://www.ccs.neu.edu/home/matthias/
(1) I am the founder of PLT, and co-inspire  
its direction with Matthew Flatt and Robby Findler. (2) I am an  
author of three Scheme-based books, two of which use a subset of  
standard Scheme. (3) Finally, I am a programming language researcher  
who has published a large number of papers inspired by and based on  
Scheme. (4) A such, I would love for the Scheme report to set the bar  
as high as possible for academic languages so that researchers and  
authors can cite an exemplary chain of evolution of language  
definitions. -- I must say I find it embarrassing that we do not use  
web forms, powered by a Scheme server, for this process. -- Alan  
Bawden has politely and in a scripted manner asked me to supply  
additional words to satisfy the 150 word limit and additional  
evidence. For the former, see the end of this write-up; for the  
latter, take a look at    the papers at "http://www.ccs.neu.edu/ scheme/pubs/", most of which I authored or co-authored.


Name: Herman Ehrenburg
Location: Delft, Netherlands
Scheme is important to me because I think it is the best programming
language. It comes close to the programming language which I would like to
use for all my programming. What I like about Scheme are its regularity,
flexibility, and safety. What I do not like are things like the
abbreviations, legacy names, double pairs of parentheses, permissiveness,
etc. Fortunately the language is so flexible that most of it can easily be
adapted. So I made my own version of Scheme on top of Scheme. Consequently,
my interest in the Scheme standard is that I depend on it for my own
version. If Scheme improves then that makes it easier for me to use,
maintain, and improve my own version. What I like in particular about the
new proposed standard is that it makes the language more complete and that
it becomes really easy to rename and exclude things.


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

Affiliation: Retired
Mail: mzscheme@gmail.com
Web: http://www.schemekeys.net
Even having gone through a masters program in computer science in  
the early 1990's, I had never used Scheme until retirement from  
medicine.  I was doing a survey of the new languages of the time, and  
had the great fortune of coming across TPSL 3rd ed.  I ended up  
selecting DrScheme as my implementation of choice, and have been  
increasingly more active in the Scheme community ever since.  Scheme  
is a very personnel subject for me, as I have no commercial interest  
tied to it, and yet I spend the great majority of my day writing  
Scheme code, and publishing blog articles on the subject of Scheme.   
I derive a great deal of enjoyment and edification out of being a  
member of such an intellectually stimulating group of people as are  
those that make up the active Scheme community.  In addition, beyond  
what Scheme means for me personally, the language itself provides,  
for those who would choose to study it, a mechanism of expression and  
extensibility that makes it particularly well suited for use as a  
mechanism for discourse about languages in general.  Scheme has been  
the birth place of many of the most intriguing notions of what a  
language can provide, beyond simply being Turing complete in its  
expressive power.  I would hate to think that I could not pass on to  
my child what I have learned from Scheme, because, for lack of a  
standard, it had faded from use in the academic and commercial  
communities.

The R6RS process is of great interest to me because my belief is that  
the current state of affairs, in which each vendor is coming up with  
their own mechanism for packaging code into a reusable, in some cases  
dynamically linkable, module is fracturing the Scheme community  
needlessly by a person's choice of implementation.  While I think  
there is room for healthy competition and innovation among vendors, I  
strongly believe that it would be a win-win situation for all vendors  
to share a common method of packaging code for reuse.  From what I  
have read in the draft, I believe that the committee has produced a  
model that should be easy enough for all vendors to adopt, that the  
module system proposed by the draft will gain wide spread support,  
and the Scheme community will finally have, what most successful  
languages of our time have, a common format for distributing code.   
On the other hand, if we fail to come to consensus on such a  
mechanism, I fear that there are a far too many languages vying for  
adoption, and in many cases emulating the features of Scheme that  
make is so great, that we risk loosing the language, only to have it  
replaced by the likes of f#, developed by monolithic corporations  
that will not bother to hold a vote on what the language should or  
should not become.  I view R6RS as one of the great turning points  
for Scheme, whose failure of adoption may lead to the loss of a truly  
beautiful language.


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

Mail: r6rs@speechcode.com
Web: http://speechcode.com/
I've been an avid fan of Scheme since 1984, when I first used it as
part of the 6.001 Structure and Interpretation of Computer Programs
course at MIT.  It has been my favorite programming language since
then, and while I rarely use it at work, I use it for all my
programming projects at home.  While I was an undergraduate, a staff
member, and a graduate student at MIT, I spent many years working on
MIT Scheme, including its interpreter, compiler, runtime system,
debugger, and editor, and I continue to make small contributions in my
spare time.  I've also spent a lot of time working on my own
unfinished implementation of Scheme.  I followed the R4RS and R5RS
standardization processes closely, participated some in the IEEE
Scheme standardization process, and have participated quite a bit by
email in the R6RS process.  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.


Name: Ivan Raikov
Location: Okinawa, Japan
I'm a user and contributor of Chicken Scheme. I have extensively
used Standard ML and Scheme to construct domain-specific languages and
code generators for numerical simulation of neuron models. I ended up
settling on Scheme as my primary programming environment for creating
and controlling numerical simulation experiments, because there were
so many competing high-quality compilers and interpreters for Scheme,
unlike other high-level languages used in scientific modeling, and
because Chicken Scheme already had many convenient libraries
available.

Something that is said often is that one of the reasons that we have
so many good compilers for Scheme is the minimal design of the
language. This makes it easy to write compilers and to experiment with
language features without spending much effort figuring out how to
incorporate each feature in a massive design. For example, the author
of Chicken Scheme recently created a mini-compiler for a restricted
subset of Scheme that generates static C++ code, which is extremely
useful for many problems in numerical simulation design, where garbage
collection is undesirable, and performance is of utmost
importance. And thanks to the minimal design of Scheme, Chicken also
provides an excellent and very flexible foreign-function interface.

The combination of this foreign-function interface and the static
mini-compiler has allowed me to design a simulation system,
implemented entirely in Chicken Scheme, that incorporates
high-performance modules, written in the restricted static subset of
the language, that are controlled by a flexible high-level language
and a scripting interpreter on top of that, and this is a sort of the
holy grail of high-performance scientific computing.

So it is this minimalism and freedom to tinker and experiment with the
low-level machinery of the language that is particularly important to
me. There is also another dimension to this: nowadays, scientific
computing utilizes various kinds of exotic hardware, such as FPGAs,
GPUs, embedded processors and DSPs. A large and complicated language
design would make it very difficult to write code generators for such
special-purpose hardware, whereas Scheme seems to be ideally suited
for such experimental work.

R6RS seems to attempt to push Scheme in the direction of widely-used
interpreted languages such as Python and Perl, and to provide an
all-encompassing standard.  I do believe that Scheme currently has a
unique and important role, and should not attempt to become another
Python or Perl. While it is true that the current standard suffers
from a lack of portability across implementations, I think it is very
important to maintain and nurture the vast ecosystem of Scheme
implementations, and not make it difficult to have multiple competing
compilers and interpreters. 


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/
The niche Scheme currently dominates is: language so simple its
 basics can be learned in an hour and an interpreter written in a page
 or two, but so powerful it is the lingua-franca of programming
 language theory.  In other words, the minimal features that need to
 be added to an eager lambda calculus with side effects to allow
 convenient creation of data structures and of fun.  Dominating this
 niche means Scheme is great for teaching, and for prototyping new
 language features and implementation technologies.  I have been using
 Scheme for these purposes for quite some time: I developed a course
 at UNM/CS which taught Scheme at a sophomore level, and in my own
 research I use Scheme as a testbed for new language technologies,
 e.g., object systems with first-class classes (Oaklisp, some time
 ago) and more recently first-class automatic differentiation
 operators.  To protect Scheme's dominance of these niches, I believe
 that we should preserve a small language optimized for elegance and
 simplicity and rapid teaching and rapid implementation.  And I
 believe we should be wary of premature optimization and of piling
 feature upon feature to address perceived deficiencies.


Name: Dan Muresan
Location: Bucharest, Romania

Web: http://alumnus.caltech.edu/~muresan/

Scheme is my favorite programming language, and I consider it as 
near-perfect. Due to the conciseness of R5RS, Scheme interpreters and 
compilers have sprung up for a variety of environments: today we are 
fortunate enough to be able to use Scheme to create executable 
applications, Java applications (including web applications running on 
top of J2EE), to script OCaml programs, and even to write AJAX 
applications via Javascript translation. Moreover, we are able use more 
or less the same code across these various Schemes, as R5RS compliance 
is common and various extensions to the language and libraries have been 
standardized into SRFI's.

Due to the arrival of this golden era in Scheme's evolution (and more 
generally the history of programming languages), I've been able to use 
Scheme for most of my endeavors, from web applications to file systems 
to shell scripting to numerical applications. It's been an extremely 
pleasant experience, and I've been able to build a Scheme code base that 
I can reuse in new projects with little effort and extraordinary 
productivity gains.

My interest in R6RS standardization is to make sure that Scheme's 
advantages are not lost, and new and useful features are added to the 
language conservatively. In other 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.



Name: Harold Ancell
Location: Joplin, MO, USA

Mail: R6RS-vote@ancell-ent.com
Web: http://ancell-ent.com/
Computer Science: My sole interest is in languages, the paradigms they
enable, encourage or discourage (e.g. functional programming), and
since reading the "lambda: the ultimate ..." papers in 1980-1 Scheme
has been my vehicle for that.

Education: The above interest extends to education: I've watched the
evolution of SICP from draft form, and am now watching the evisceration
*in this area* of the MIT CS required curriculum with horror.

Recreation: By temperament I'm a scientist (chemist), and while
programming and software engineering are fascinating, developing
software was mostly a means to an end.  Circumstances and aptitude
forced my career to be in software development, so when I program for
myself, 'for fun', I want it to BE fun.  That means LISP and most
especially Scheme.

Projects: I am now essentially retired, and I plan on spending a fair
amount of time doing useful FOSS work.  That which is not forced to be
in C I will do in Scheme.

A good R6RS standard will further all of my above interests and goals.


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

Mail: aaron.hsu@sacrificumdeo.net
Web: http://www.aaronhsu.com
I am a designer and programmer that works in both the academic and
business fields. I utilize scheme almost entirely for the majority of my
work, and it is my intention to continue to use Scheme in these
capacities. Up until now Scheme has been missing a few nice features
which prevent the easy dissemination of nice and portable works, and
when teaching, the support of multiple Scheme implementations is
somewhat annoying when they are largely different. However, as a
business programmer, I also have to be able to provide for special cases
and unique processes, so the manner in which various problems in the
Scheme language are rectified is of concern to me. I hope to be able to
weigh in on a decision that will likely result in a significant impact
on the Scheme community as a whole. I also have money invested in Scheme
implementations, and I desire to Scheme move in a productive and
principled manner.


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

Affiliation: MIT
Web: http://people.csail.mit.edu/newton
Scheme is the language I've been programming in since the fifth grade
(1991).  I am substantially invested in a number of ways, including a
large existing codebase.  I continue to use Scheme for my functional
programming rather than Haskell or ML because of three major benefits
I derive from it: syntactic extension, ease of manipulating code as
data, and the conciseness of data represented in S-expression form.
That said, the single bigest failure of Scheme in my view is the
balkanization of implementations.  Writing significant applications
portably is nearly impossible, and the community has failed to build a
large collection of shared libraries.  I think the minimality of the
R5RS standard is largely to blame.  R6RS will provide a more
complete and usable language standard.  Thus I believe it is
critical that R6RS be ratified and subsequently adopted by
several of the major implementations.  I see this as such an
overwhelming imperative that I believe it dwarfs the importance of the
actual design particulars that tend to inspire bickering.


Name: Scott Bell
Location: Calgary, AB, CA

Affiliation: IBM
Mail: sebell@gmail.com

I am a single developer within the Network Services division of IBM. I
currently  use the  Scheme  programming language  to develop  internal
solutions, mainly for tasks that were previously addressed with Perl.

The language choice  of Scheme is primarily due  to its simplicity and
powerful  means  of combination.  Programming  in  a functional  style
promotes  reusability  while   reducing  the  complexity  of  language
constructs, especially  when compared with  mainstream object-oriented
languages.  When used in this way, Scheme programs can be written in a
very declarative fashion, which  increases productivity and allows for
highly readable programs.

I am interested in the outcome  of a new standard for Scheme primarily
because  I enjoy writing  Scheme programs,  which would  influence the
capacity  in   which  I  use   it  professionally.   I  feel   that  a
community-involved, active, light-weight  standardization process is a
great asset to the Scheme community,  and I wish to participate in the
ratification process.



Name: John Nowak
Location: Sunnyside, NY, USA

Mail: john@johnnowak.com
Web: http://johnnowak.com
Scheme is one of the few programming languages that I've come to  
actually enjoy using. I value it, above all else, for its simplicity.  
At Parsons School of Design, I've introduced fellow students to  
programming via Scheme and the tremendously well-written book, "How  
to Design Programs". The combination of a simple language, great  
texts, and implementations that consider the beginner (namely PLT)  
make for a great combination. In my own work, I've used Scheme to  
implement prototypes for two programming languages. I've also used it  
for music composition via Rohan Drape's excellent Supercollider  
client, "rsc". When one is producing music programatically, a  
language that works with the programmer and doesn't irritate is more  
critical than ever given the detrimental effects that distraction has  
on the process. My interest in the standard is to do what I can, in  
my limited capacity, to ensure that my programming language of choice  
will continue to be optimally useful for teaching, language design,  
and my artistic pursuits.


Name: David Frese
Location: Eningen unter Achalm, BW, Germany
From the first day of my experiences with scheme, I liked the
elegance which comes out of it's simplicity. This first contact with
scheme took place in Mike Sperber's introductory courses at Tübingen
University, where we used DrScheme to learn how to solve the first
problems with computer programs. Actually, the work with DrScheme was
so simple, that many of my colleagues already stamped scheme as a
toying language, with which no serious work could be done. But the
other ones, including me, later had the chance to do various
interesting stuff with Scheme 48 and Scsh. Personally, I participated
in implementing an X window manager, a generational garbage collector,
and as my diploma thesis, a transparent way to utilize multiple
processors with a Scheme 48 program. Now that I work in the industry,
I see big chances for scheme as an embedded extension and
customization language for bigger software systems. Schemes
flexibility could help in reusing code written in existing
customization languages, and it's simplicity imposes a small learning
barrier for it's users. Therefore, I'm interested in the future
development of the language scheme, and would like to take part in
the ratification of the R6RS.


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

Mail: bitwize@gmail.com
I am a developer who has been working with and enjoying Scheme for a few
years. I feel that Scheme occupies an important niche in the
programming-language ecosystem, that is, as a language in which it
is easy to program and just as easy to think about programming. This
simplicity comes from a compact, orthogonal core of ideas upon which
more complex constructs can be built.

There have emerged a number of languages, such as Tcl, Perl, Python,
and Ruby, whose evolution is shaped by local pragmatics and whose
semantics are frequently standardized by a single
implementation. Scheme does not exist in the same part of the
programming-language spectrum with these languages, nor should it; it
is a core abstraction, a starting point for programmers and language
implementors to explore and experiment. My interest in the Scheme
standardization process is therefore in helping to preserve Scheme's
place as a clean language to think in and build on, as well as a
practical tool to program with.


Name: Robby Findler
Location: Chicago, IL, USA

Affiliation: University of Chicago
Web: http://www.cs.uchicago.edu/~robby/
I am interested in Scheme as programmer and as a researcher.
As a programmer, I maintain DrScheme, PLT Redex, and some other
PLT-based software. I expect DrScheme to support future revisions
of Scheme, including R6RS, and I expect the others to be written
in standards-conformant Scheme. So, I'm interested to see what language
I will be programming in and supporting.

I also write research papers that are based on (models of) Scheme.
Such models should follow the spirit of Scheme and the RnRS series
is the definitive source of that spirit. So, I'm interested in the latest
RnRS to see how such models might have to change, in order to capture
the essence of Scheme.

Finally, I am interested in the discussion surrounding
the ratification of the draft of R6RS. The face of the Scheme
community is emerging and I find that fascinating. So, the actual
vote will help me to understand which group is the vocal minority
and which group actually captures the spirit of the community,
at least wrt the draft R6RS.


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

Affiliation: None
Mail: cowan@ccil.org
Web: http://www.ccil.org/~cowan
While I am neither a Scheme implementor nor a heavy Scheme user,
I have followed the development of the Lisp family of languages since
1972 with great interest, and have implemented a Lisp or two, mostly
for the challenge of it.  My particular interest in the R6RS process
is in bringing Scheme up-to-date with Unicode, and I have been a major
contributor of R6RS comments on that subject.  R6RS is certainly not
perfect, but it is the first Scheme standard that shows serious concern
for portability.  Although it is possible under earlier standards to
implement everything oneself in a small core dialect, the result is a
proliferation of pointlessly incompatible implementations of the same
concepts under the same or slightly different names.  R6RS in combination
with existing and novel SRFIs goes a long way to alleviate that issue.
I am now also a participant in the Chicken Scheme community (specifically,
I am the chief Cygwin tester for Chicken), which as a whole tends to
be rather anti-R6RS, and I hope to do something to help change that,
partly by helping to make R6RS the best standard possible.


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
I am the sole author of Stalin (a high-performance implementation of R4RS)
   and Stalingrad (a high-performance implementation of a functional, numeric
   subset of R4RS that adds first-class automatic differentiation). I conduct
   research in both programming languages & compilers and AI (including
   computer vision, computational linguistics, robotics, machine learning, and
   cognitive science). All of my publications since 1981 are supported by
   substantive implementations, all of which are in Lisp or Scheme. All of this
   code has been publicly released and some of it is widely used. Every
   course that I have ever taught (including AI, computer vision, computational
   linguistics, and programming languages since 1993) has been based solely on
   Lisp or Scheme. I currently teach AI every semester in a course whose
   material I have solely prepared and which is based solely on Scheme. I have
   shared the material that I have prepared for the courses I teach with other
   teachers, including the course software that I have prepared, all of
   which is written in Lisp or Scheme. Overall, several hundred students have
   taken my courses.


Name: Guillaume Germain
Location: Montreal, Quebec, Canada

Mail: guillaume.germain@gmail.com
Web: http://toute.ca
For the last 5 years I've been using Scheme extensively.  I have done
my Master's on adapting Scheme to concurrent programming, and I've
used it for other research.  I've also had the chance to use it to
teach practical aspects of programming languages.  I have worked both
as an employee and as a paid consultant to develop and maintain Scheme
programs.  I also plan to use Scheme in future projects.

The strength of Scheme lies in its simplicity and its dynamism.  It is
why Scheme in its current form is a good teaching, research and
development programming language.  It is good for teaching because it
is simple.  It is an effective research vehicle because of its
flexibility: it is easy to to adapt to any situation, either at the
language level or at the implementation level.  Its dynamism provide
powerful support for developing and maintaining applications.

I want to vote in order to express my opinion on whether the current
proposal for R6RS preserve those aspects of the language and respect
the spirit of Scheme.


Name: Bakul Shah
Location: Los Altos, CA, USA
I have been a long time user of Scheme as well as an
implementer of a couple of experimental Scheme interpreters
(never released publicly).  I have used Scheme for personal
and paid work, things like code for a network processor,
testing code for ASICs, for generating code as well as for
prototyping programs & modelling algorithms.  And, of course,
as a swiss-army tool for all sorts of tasks including systems
programming.

As an implementer I am concerned about ease of
implementation, size of the language, completeness and
orthogonality,  etc.  As a user I am concerned about ease of
use, efficiency, portability across implementations and so
on.  If the standard is not embraced by authors of the
implementations I routinely use, I would be forced to use a
subset they implement.  As an experimenter I am concerned
about the size and simplicity of the language as a complex
implementation is harder to experiment with.

I have been following the srfi-* mailing lists and the r6rs list.
I tend not to argue much in public forums or send "me too" messages
but I have been following the progress of r6rs with avid interest.


Name: David Fisher
Location: Boston, MA, USA

Affiliation: Notheastern University
Mail: dfisher@ccs.neu.edu
Web: http://www.cs.gatech.edu/~dfisher/
I am a doctoral student in language theory.  Scheme is the
language I program in most often.  I have been programming in
Scheme for years, and, in addition, I have worked on implementing
the Scheme system Scsh.  I have worked with Scsh, Scheme 48, and
MzScheme; all three are R5RS-compliant, yet there are significant
differences between them that make it essentially impossible to
write portable programs.  My thesis work includes a compiler that
I intend to someday extend to a standards-compliant Scheme
implementation.

 My thesis work involves language implementation via hygenic
macros, similar to those found in Scheme. Language extension via
macro is an enormously power feature, and has the potential to be
extremely compelling to a wide audience; Scheme is adaptable to a
surprising variety of problem domains, thanks to this one
easily-used feature.  However, in order for this feature to be
seen by a wider audience, the community must show progress, which
at this point means a new (and hopefully more complete)
standard.


Name: Alexey Radul
Location: Boston, MA, USA

Affiliation: Massachusetts Institute of Technology
Web: http://web.mit.edu/~axch/www
Scheme puts me in an ironic but not-too-uncommon predicament.  The
language itself is by far the best programming language I know.
Unfortunately, the periphery around the language --- libraries,
documentation, tutorials, a sense of united community --- leaves a
great deal to be desired.  So I am stuck: Do I use and endorse an
inferior language with fuller libraries and more clearly organized
documentation, or do I use and endorse a superior language in which I
must write every other library function I wish for because it either
isn't there or I can't find it?  The Scheme evolution process gives me
a way out: if, after perhaps some years of work, Scheme gains the
preiphery I wish for, I will be satisfied, and perhaps the world will
be a little better off.

Lest I be misunderstood, I will raise the dichotomoy between Scheme
itself and "Scheme Implementation X".  I have not studied all the
implementations as carefully as perhaps I should have, and it is quite
possible that some individual implementations of Scheme are rich in
libraries, well documented, and have united communities.  The larger
Scheme community, however, has not, to my knowledge, picked one of
those as the unequivocal winner.  Scheme as a whole remains,
therefore, divided, ill supplied with libraries, and open to
improvement.  That being said, it is my opionion that the multitude of
Scheme implementations can be a source of great strength for Scheme,
which is why I am interested in the Scheme standardization process
rather than in merely seeking out or creating that one ideal
implementation.


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

Mail: erich@snafu.de
Web: http://www.peppermind.com
Scheme is a very advanced and flexible programming language that  
I use whenever possible. It is clean and can be used by the  
programmer to develop the programming language he needs while writing  
the code he needs. This aspect of extending the language itself on  
the fly enhances re-usability without introducing unnecessary clutter  
known from languages that force the programmer to treat everything as  
an object. Scheme takes another approach: Instead of treating  
everything as an object, so you can pass it to a function, it allows  
you to pass anything you like to a function. However, Scheme also has  
some disadvantages: First, code is de facto very hard to understand,  
if it is not well-documented. As a remedy, documentation tools have  
been developed and are freely available. Schemers should use them  
more often. Second, it is mainly used in academic environments.  
Unless there will be substantially more final and widely implemented  
SRFIs, this will not change. However, I do believe that the more  
SRFIs become final and supported by Scheme implementations, the more  
popular Scheme will invariably become outside academia. Third, R5RS  
Scheme has lacked a number of features such as a common library  
structure and Unicode support that are essential for a language  
nowadays. To change this situation, the R6RS efforts are in my  
opinion a step in the right direction. There is still some essential  
features missing. The most important one is in my opinion some  
reasonably complete standards for writing graphical user interfaces  
and for accessing platform-dependent features, which can be  
implemented optionally. It is my hope that in the near future such  
standard specifications will be available as  SRFIs and will be  
provided by various implementations that already provide graphical  
user interface libraries and foreign function interfaces. Apart from  
this, Scheme is already a rather complete language. And if something  
is missing, you just add it.


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

Affiliation: The Transterpreter Project
Web: http://www.transterpreter.org/
The Transterpreter is a portable virtual machine for supporting the
exploration of CSP-based languages in small and large contexts, using
instruction set of the Transputer (and the programming language occam)
as a starting point and implementation target for our explorations. In
developing tools surrounding the virtual machine (eg. a new linker,
compiler wrapper, and FFI support tools), we chose to use Scheme,
largely due to the open, portable, and robust nature of the PLT Scheme
implementation. In a perfect world, we would not be tied to any one
implementation, but without things like a common 'module' or 'library'
construct, we cannot easily decompose our software in safe and
sensible ways. As the primary maintainer of the Scheme portions of the
Transterpreter's toolchain, I am interested in seeing progress made
towards a day where the Scheme I write can (easily) run on any RnRS
compliant implementation without having to sacrifice
reasonable/practical language constructs.


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

Mail: riastradh@gmail.com
Web: http://mumble.net/~campbell/
Scheme, from its inception, has been an exercise in condensing
complex ideas to a simple set of primitives in terms of whose
abstraction and combination the complex ideas can be straightforwardly
expressed.  The ideas of the core of Scheme could fit in a few pages
of description, and suffice as the basis to express a broad range of
sophisticated ideas; because of this I have been attracted to Scheme
for as long as I have been aware of it.
    Scheme has been an invaluable pedagogical vehicle, because of its
economy and flexibility of underlying concepts, allowing ideas to be
expressed easily by novices without the barrier of a mountain of
syntax to memorize.  I have exploited these properties of Scheme to
teach several courses using Scheme to high school students, and I have
personally tutored innumerably many other people from a wider range of
backgrounds than I can remember.
    I have contributed substantially to two major Scheme
implementations, Scheme48 and MIT Scheme.  I have been an active
participant in the development of a number of Scheme Requests for
Implementation, and have authored several of them as well.  And nearly
all of my programming work in the past few years has been in Scheme: I
have an interest in it.


Name: Dave Gurnell
Location: Birmingham, UK

Affiliation: Untyped Ltd
Web: http://www.untyped.com/about/dave
I am a director of Untyped Ltd, a UK based  
consulting and software development company. Much of our recent work  
has involved web development in PLT Scheme. We find Scheme to be an  
exceptional language for this purpose: features such as first class  
procedures, continuations, macros, and s-expressions provide power  
and elegance that cannot be reproduced in many mainstream web  
programming languages. The principle disadvantage of Scheme as a  
language for commercial development is its relatively small,  
fragmented community. At Untyped, we have had to write substantial  
amounts of code that we would have been able to get as third party  
libraries had we been using Python or Java, simply because those  
libraries weren't available as part of PLT. It is my belief that a  
wider Scheme standard, with a standard module system and standard  
libraries, will increase the mutual compatibility of Scheme  
distributions and help bring the community together. A larger  
community means more development, more development means more  
developer support, and more support makes Scheme a more compelling  
choice for commercial development.


Name: David Haguenauer
Location: Montreal, QC, Canada

Mail: ml@kurokatta.org
Web: http://www.kurokatta.org/
Even before I considered studying programming languages formally,
    I remember having been impressed by the elegance of Scheme and by
    the longevity of the family of languages it is a member of.

    Since then, I have become a computer science student in a
    university where the first class used Scheme, which confirmed that
    it was a language suitable for making general concepts of computer
    science accessible to beginners. That experience also let me
    contemplate the apparent universality of a simple language that
    was also used in the Real World.

    My fascination for programming languages led me to become a PhD
    candidate, on a subject involving functional programming. Even
    though I have also been attracted by statically-typed languages,
    Scheme remains an extraordinarily prominent part of the functional
    programming scene: its fate will no doubt affect all people
    working in that field, including me.

    The R6RS ratification process is certainly an important one; it
    will turn Scheme, with its currently minimalist feature set, into
    a language where modern, higher-level features will be available
    portably; making the language useful to more people. It seems to
    me that having all users and implementors agree on a standard
    definition is necessary to ensure that the language will be more
    easily adopted by developers and implementors alike.


Name: Shiro Kawai
Location: Honolulu, HI, USA

Affiliation: Scheme Arts, L.L.C.
Mail: shiro@acm.org
Web: http://practical-scheme.net/
I'm running a small business of writing software, and I use Scheme.
Choice of programming language is one of the most important 
factor that affect productivity of small development farms like mine.
Scheme's clean design and extensibility is indispensable for me 
to keep up with the business demand, since I can transform the
language info an ideal form to solve the given problem, while I
can trust such modification won't break because of Scheme's solid
foundation.  Few other languages, even much richer in features,
give that kind of assurance and eventually show their limitation
that drag the development.  For small farms like mine, anything that
drags the development can be deadly.

Although R5RS plus SRFIs have been serving well for the purpose, 
there are yet some warts in the Report (mainly I concern some
ambiguities and underspecifications, rather than the lack of 
features).  So I welcome the new revision.

At this moment I have a mixed feeling on the R6RS draft; it does
fix problems I saw in R5RS, but also it specifies a lot more,
which I'm not sure is necessary.  Yet I appreciate all the efforts
the editors put into the draft, and of steering committee and
participants in the discussion list.  Whatever outcome we get
by this voting, I believe those efforts won't be wasted, and
can be the basis of better languages and implementations in future.


Name: Gerald Jay Sussman
Location: Cambridge, MA, USA

Affiliation: MIT
Web: http://swiss.csail.mit.edu/users/gjs/gjs.html
As one of the original developers of Scheme, participant in earlier Revised
Reports, and the author of two textbooks that use Scheme, one to
communicate concepts of programming and another to communicate concepts of
classical mechanics, I think that my interest in this matter is pretty
obvious.

In addition, I am a heavy user of Scheme.  I use Scheme to build software
used in classes I teach.  I use Scheme in research on AI, Programming
Languages, and in Physics.  I have used Scheme in the design of hardware,
such as the Digital Orrery and the Supercomputer Toolkit.  I have used
Scheme in the development of software for professional astronomical
observatories: the mirror-support system for the Hiltner telescope on Kitt
Peak and the guider-probe controllers for the Magellan telescopes on Las
Campanas in Chile.


Name: Michael Greenberg
Location: Boston, MA, USA

Web: http://www.weaselhat.com/
Scheme having been my first formally taught programming language,
it remains my language of choice for most tasks.  Not only is Scheme
an elegant language with an academic history and a sound theoretical
basis, but it is a practical language, with many implementations.  This
latter part, 'many implementations', is both a blessing and a curse.
The changes in R6RS will help close the gap between compliant
implementations: the addition of Unicode support and a standard library
are absolutely necessary for Scheme to keep up with the times.  Other
vital additions include the exception/condition system, standardization
of record types, and hashtables.  These are all core structures in
programming, and I need them to do my work.

This has not yet answered the question why I would have an interest in
the standardization of Scheme.  PLT Scheme, for example, has support
for all of these things.  My interest is very much in portability.
Last year, I wrote a program for elliptical-curve factorization.  With
its ease of abstraction and numeric tower, writing the program was an
afternoon's work.  When it ran slowly in PLT Scheme, however, I was
frustrated.  None of the optimizing Scheme compilers would accept my
code, since it was littered with convenience functions and macros
(case-lambda and records, for example).  The conversion process was not
trivial.  With a standard library, this wouldn't have been a problem.
R6RS will let me continue to write in Scheme with a guarantee that more
programs will run in more implementations.


Name: Andreas Bernauer
Location: Tuebingen, Germany

Affiliation: University of Tuebingen
Mail: r6rs at lysium remove-this dot de
Web: http://www.lysium.de
I've been using Scheme since I started my university career eight years
ago.  I programmed the server side scripting in the SUnet webserver where I
tried to stick to the Scheme paradigm: using a small number of function to
express web page delivery.  I also tried to use Scheme for administrative
tasks by writing small scripts in scsh.  However, I failed most of the time
due to various restrictions and impossibilities in Scheme (or scsh, for
that matter). In particular, the current Scheme standard is not aware of
any character encoding, which makes it hard to 'talk' to other programs,
for example via XML files.  Another problem was that although there is a
single Scheme standard, I could not easily use other Scheme languages, as
some of the things real-world programs use (such as hash-tables) were
implemented in a library which was only available to my Scheme
implementation.  So, I would like to see the new Scheme standard to allow
more real-world programs which can be (more) easily be ported between
various Scheme implementations.


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

Affiliation: Computer Science Department, Brown University
Mail: jay.mccarthy@gmail.com
Web: http://jay.teammccarthy.org/
I am interested in the outcome of the process for three
reasons. First, I intend to be a lifetime user of Scheme, and
desire the standard to the best it can be for the selfish motive
of having code written for me by others. Second, as an aspiring
teacher and advocate, I have an interest in the standard being
sensible to beginners and potential converts. For example, the
Common Lisp standard is incomprehensible to almost everyone, and
that outcome would reflect very poorly on Scheme. Third, I am a
member of the PLT Scheme development group and the standard of
the language will have an impact on my work. In particular, I
manage the PLT Scheme web-server, which intends to offer a
version of Scheme with web application capabilities. If the
standard makes crazy decisions, then it will be difficult to
recreate the Scheme semantics in this web-language and/or
leverage the Scheme brand name.


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

Affiliation: Northeastern University
Web: http://www.ccs.neu.edu/home/will/
Although I wrote my PhD thesis on the actor model
of concurrent computation, which was the original
inspiration for Scheme, I did not become involved
with Scheme itself until Professor Dan Friedman
taught me how to teach programming languages.
Instead of building the course around Scheme
interpreters written in Lisp, I suggested we use
interpreters written in Scheme itself.

To make those interpreters executable, I wrote
Scheme 311 on top of Franz Lisp.  I then built
a much better byte code interpreter that became
MacScheme.  It acquired a native code compiler
and grew into MacScheme+Toolsmith.  During the
early 1990s I wrote the Twobit compiler and
supervised Lars Hansen's construction of Larceny.
The Larceny family of implementations now has
four back ends that generate machine code for
Sparc and x86 processors, C code for most other
processors, or CIL code for Microsoft's Common
Language Runtime.

I prepared an agenda for the 1984 workshop at
Brandeis, edited the Revised Revised Report, and
have contributed to every report since.  I have
written at least a dozen other papers related to
Scheme.  I am currently maintaining over 50,000
lines of portable Scheme code that run in several
different implementations of Scheme.


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

Mail: kent-r6rs@nhplace.com
Web: http://www.nhplace.com/kent/
I have participated in the design Yale Scheme (T), have been
  publicly and privately involved in conversations with members of the
  Scheme community about the design of specific Scheme-related issues
  (control features, error system, etc), have used Scheme
  professionally in the past (and might again in the future), and have
  invested personal time and energy as a member of the committee
  previously entrusted with the design of Scheme.  All of these things
  illustrate my connection to and commitment to the Scheme language in
  specific.  More generally, I have participated in the use, design,
  implementation, documentation, standardization of (and public
  speaking and published written commentary about) various symbolic
  and functional programming languages (various dialects of Lisp,
  Scheme, ML/Haskell) professionally for almost 30 years, I have a
  demonstrated interest in seeing symbolic and functional programming
  technology of this general kind succeed technically, socially, and
  commercially in order to assure its acceptance as a manner of
  expression in a variety of circumstances.  Such circumstances might
  include, but are not limited to, encoding and exchanging knowledge
  for both academia and historical records, codifying data and
  processes in a form useful for commerce, exploring and visualizing
  concepts and methodologies in research, and general expression of
  less materially purposeful forms, such poetry and literature.  I am
  sometimes critical of the Scheme language, and often prefer
  programming in Common Lisp, but I do not seek to make Scheme into
  Common Lisp--I think it serves a different user base.  Moreover, I
  do not think a community is ill-served by constructive criticism.  I
  find myself enriched by the study of all things, and I take it as
  given that unconditional allegiance is not the price of admission to
  this group.


Name: chris koehnen
Location: st.paul, mn, usa
I'm interested in the Structure and Interpretation of Computer Programs,
Essentials of Programming Languages, the Little Schemer books, Lisp in
Small Pieces, Programming Languages: Application and Interpretation, and
the http://library.readscheme.org gold mine - totaling well over 150 words
of interest.  When I program for fun, scheme is my first choice.  When I
program at the day job, scheme is my prototyping language of choice (to the
annoyance of my parenaphobic coworkers).  R^5 is complete enough for my
uses, though I would like to use scheme for more.  Individual
implementations have addressed the r^5's shortcomings but those solutions
are not portable across implementations.  One of the most intriguing
aspects of scheme is the language's malleability, not just with the program
design space but within the implementation space.  There are scheme
implementations designed as embedded languages, application languages, and
scripting languages.  I like being able to use one core language in each of
these spaces but r^5 is a bit small for a core.  Sometimes I really want to
catch an exception and being able to write a library for one implementation
and using it in another would be really, really nice.  I've read the early
drafts and lurked in the review lists, waiting patiently for the final
draft.  Perhaps I should have been more involved earlier.  Peter Norvig
advises programmers to get involved in a language standardization effort as
a way of mastering programming (http://norvig.com/21-days.html).  He also
advises 'Have the good sense to get off the language standardization effort
as quickly as possible.' I'm afraid I'm following his advice in reverse.
When are you kicking off r^7?


Name: David Rush
Location: Dublin, Ireland

Affiliation: Heureka Software Systems, Limited
Web: http://cyber-rush.org/drr/scheme
I have spent a lot of time and effort in the past developing software
in Scheme, as a public advocate for it's use both in cyber-space and
in the corporations that have employed me, as well as participating in
the SRFI editorial process. The primary attraction to me of the
language has always been its minimal semantic footprint, which makes
it an excellent platform for long-term software development projects -
especially those which are underfunded. Currently, I am the Principal
Engineer of a startup company and we will be sing Scheme very heavily
in the development of our products, and it is important to me that the
Scheme learning curve remains very short, so that we can bring in new
staff who, while not experienced in Scheme (or functional programming
even!) can become productive very quickly.


Name: Chris Hanson
Location: Cambridge, MA, USA

Affiliation: MIT
Web: http://swiss.csail.mit.edu/users/cph/
As a participant in all the previous RNRS documents, an editor of the
IEEE Scheme standard, the maintainer of MIT/GNU Scheme, and a prolific
Scheme programmer, I have an obvious stake in this process, and I take
it very seriously.  As I've made clear to the steering committee and
numerous others, the success of this process depends on the engagement
of the community, which in turn depends on the process being
responsive to the community's input.  Consequently it would be pretty
hypocritical if I _didn't_ participate in ratification.

Several recent public discussions have raised issues with the current
state of the standard, and contained suggestions that ratification is
or might be a possible mechanism for recovery.  I view this as a
positive sign, that members of the community recognize they have the
power to affect the process.  This is exactly what I had hoped for,
although I would rather see the document repaired rather than
rejected.


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

Affiliation: Universidade Federal de Ouro Preto
Web: http://www.decom.ufop.br/prof/romildo/
I had my first contact with the Scheme programming language when I
was still atending my undergraduate course on Computer Engeneering. The
conciseness of the language amazed me. At that time I used Scheme to
implement several academic projects, such as a small compiler. In my
graduation course I have used Scheme to implement a Computer Algebra
System as part of my thesis. My current interests are on Programming
Languages, in particular Functional Programming Languages. One thing I
would love to see is the possibility of easily writing Scheme programs
that are portable among most of the available Scheme implementarions, so
I am following the evolution of the language with interest. Most of the
time when choosing a programming language I take performance issues into
account. So we need more efficient implementations of Scheme. For that
reason I have been working with the Bigloo compiler, although it goes
away from the standard in several aspects. I plan to contribute to the
Bigloo development in order to make it more conformat to the standard.


Name: Abdulaziz Ghuloum
Location: Bloomington, IN, USA

Affiliation: Indiana University
I'm interested in the outcome of the R6RS standardization
process because of three main aspects of my work.  First, I'm
a Scheme user.  As a user of the Scheme language, it is of
paramount interest to me that the standard document does not
deviate from the spirit of Scheme that attracted me from the
language from the first place (e.g. its simplicity, elegance,
and power).  Second, I'm a Scheme implementor.  My [soon to be
released] implementation, Ikarus, is an optimizing,
incremental compiler for Scheme that already implements the
majority of the requirements of the current draft (5.97)
including the library system, syntax-case, unicode, records,
numeric tower, r6rs IO ports, among other parts of R6RS.   As
my implementation is scheduled to implement R6RS by the time
R6RS is ratified, the outcome of the standardization process
would greatly affect how Ikarus will be released and,
consequently, how it will be perceived by the Scheme
community.  Third, I'm a Scheme graduate student.  My thesis,
my publications, and the courses I teach (or assist in
teaching) use Scheme as the main vehicle of expression and the
outcome of the ratification and potentially the future of
Scheme would greatly affect my future work.


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
Ever since I was introduced to Scheme  
during my graduate career, I've found that most of programming 'just  
flows'.
It provides powerful abstractions and an efficient compiler interface  
to support program development as an organic, transformational  
process focusing on the essential features of the problem.
For my dissertation, I used Scheme to model aspect-oriented  
programming languages, and continue to do so in my research work today.
Scheme seems to offer the fundamental 'stuff' to do Martin Hyland's  
'impossible' things.

The largest deficiency I encounter with Scheme is in teaching: some  
fundamental idioms are not standardized; specifically records,  
modules, and functors.
But I believe that many of these are well-enough understood now to be  
standardized for general and instructional use.
For pedagogic purposes, the existence of a standardized set of these  
constructs will help my students as they learn to program.
Examples will continue to work between implementations and versions.


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

Mail: onlyafly@gmail.com
Web: http://kevin.alteu.com/
Scheme in particular (and Lisp in general) provides us with a
uniquely powerful way to write programs.  The methods of abstraction
Scheme provides through macros and the list-based syntax have given me
and many other programmers the tools to create powerful programs with
quick turn-around times.  The innovations that Scheme has brought to
programming and computer science is evident from the many languages
that have borrowed features from Scheme up until now.  Hopefully, this
updated standard for the language will serve as a continuing force for
innovation in both programming and programming language design.  As
both a professional and hobby programmer, Scheme has opened me up to
new ways of thinking about how to write software.  I have used it to
create end-user applications, scripting-style task automation, and
websites.  With an updated specification for the language, I believe
Scheme implementations will have a more unified core to program
against, maximizing the ease of developing applications that work
across implementations.


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/
Scheme is by far my most important tool and indispensable for my daily
work.  This includes:

(1) I have been using Scheme in the computer science courses I am
    teaching (concurrent programming, web programming, introductory
    course) at the university of Tuebingen.  I believe that these
    courses benefited from the concise syntax, simplicity, and
    expressiveness of Scheme.

(2) Basically, all scripts related to system administration that I
    wrote in the last ten years are written for scsh.  This involves
    scripts that keep the configuration of computer labs in sync,
    automatically backup servers and databases, mirror file
    repositories with ftp, detect network intrusions, and generate
    various statistics and reports.

(3) Scheme is subject of my research.  I am working on a dissertation
    in the field of static analyses.  The analysis is written in
    Scheme (Scheme 48) and for Scheme.

(4) I wrote several applications and libraries in Scheme, such as a
    graphical front-end for scsh (Commander S), a compiler from Emacs
    Lisp to Scheme, and contributed code to the Scheme 48 project,
    scsh, and SUnet (Scheme Untergrund network package).

Even though Scheme is my favorite tool, very often I find myself very
disappointed with this language.  With the current language
specification and "standard library" it is almost impossible to write
code that may be shared among different implementations (of which
there are certainly too many).  The result is: lots of useful
libraries remain inaccessible and very often I find myself rewriting
or porting code instead of simply reusing it.  I consider the lack of
a comprehensive set of easy accessible libraries for Scheme to be a
very serious if not existential problem.  In my opinion, R6RS
addresses many of the portability issues and also adds some features
(such as Unicode support) that are essential these days.


Name: Marcus Crestani
Location: Tuebingen, Germany
I learned Scheme in my introductory computer
science course at University of Tuebingen a couple of years ago.
Since then I used it a lot during other classes, term projects and
open source projects: For example, I wrote a dynamic name server
resolver for SUnet (The Scheme Underground Network Package).  Today I
am a PhD student at University of Tuebingen and work as a research
assistant at the Department of Computer Science, with research
interests in functional programming languages.  Now, I use Scheme on a
daily basis: teaching, research, and, thanks to the Scheme Shell,
automating all kinds of tasks by writing Scheme scripts.  Scheme also
plays the main part in my PhD thesis.  Scheme and where Scheme is
going is really important for my work.  That is why I want to be part
of the ratification process: Scheme is the best language out there, it
is concise and elegant.  I want it to stay that way!  And I have the
knowledge and the experience needed to judge the draft.


Name: Kjetil Svalastog Matheussen
Location: Oslo, Norway

Affiliation: Programmer
Scheme is the programming language I currently use the most, and have been using the most for about 4 years.
   Mostly, I have been using scheme to develop and use the sound editor called "SND"[1], where I have implemented
   among other things: SND-RT a realtime music programming language with scheme syntax [2], a software synthesizer called SAN-DYSTH[3],
   and the clickless playback version used in the SND dialect called SND-LS[4], and lastly an extension for the realtime graphical sound programming
   environment PD[5] to use SND as a realtime safe scripting and signal processing extension language[6]. All of this is done using the Guile
   scheme implementation plus SND-RT.

   I'm also a composer, and I'm using scheme as my main language for composing. [7][8]

   Currently, I'm working on a special kind of sound mixer, which is going to be used by school children in the music education in Norway.[9]
   This is made as a java applet, where the user interface is written using the SISC scheme implementation.

   My position as a music program programmer using scheme as the main language puts me in a situation where my vote should be counted.

   [1] http://ccrma.stanford.edu/software/snd/
   [2] http://www.notam02.no/arkiv/doc/snd-rt/
   [3] http://www.notam02.no/~kjetism/sandysth/
   [4] http://www.notam02.no/arkiv/src/snd-ls/
   [5] http://puredata.info/
   [6] http://ccrma.stanford.edu/software/snd/snd/grfsnd.html#sndwithpd
   [7] http://www.notam02.no/~kjetism/mp3/
   [8] http://www.notam02.no/~kjetism/notamkonsert2006/
   [9] http://www.musikkverksted.no/


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

Affiliation: Heyman Software, Inc.
Mail: bill@heymansoftware.com
Web: http://heymansoftware.com/
The current trend in dynamic language features (in Ruby, Python and
   others) is toward the elements already available in Scheme (including
   closures, dynamic evaluation, and lambdas). So, why use and promote a
   "me, too" language when you can have the real enchilada? The R6RS
   standard addresses fundamental improvements to Scheme to allow it to
   be used in more practical situations--bytevectors, improved port I/O
   functions and binary input, and standardized exception handling, among
   many other features. My interest in Scheme is relatively new, but, in
   my short time using the language, I've found many situations where
   Scheme is much better suited to solve the problem than existing languages
   in my programming toolset, specifically with its simple syntax, Scheme
   has allowed me to quickly develop a dynamic mathematical expression evaluator
   and continuation-based "green" threaded multitasker, both of which
   would have taken me much more time using other tools and languages.
   For the mainstream non-Scheme programmer, there definitely a paradigm
   shift in how software is designed and developed, but learning Scheme will
   certainly make a person a better software developer. I'm committed
to work to
   promote the Scheme language to the rest of the development community.


Name: Thomas Lord
Location: Berkeley, CA, USA

Mail: lord@emf.net
I am interested in Scheme in general, R6RS in particular,
because I am sometimes a Scheme implementor and sometimes a
Scheme user.   I helped to create GNU Guile, writing most of the
code that first turned SCM into Guile.  I had one false start
on a new implementation with the Pika Scheme project.  I am
currently making a second attempt at a from-scratch implementation.
I use Scheme when I can but am frequently frustrated by the
functionality of the available implementations and libraries.
I believe that R6RS can be an important milestone for the
Scheme community but I also believe that the current draft is
simply wrong-headed in a number of ways.

I have a very simple-minded but, I believe, useful view of
what Scheme is and what The Report should say about it:

Scheme is a design pattern for programming languages.  The
pattern applies in a context where we just assume, a priori,
that we have a lisp-style run time system (a tracing GC, cons
pairs, symbols, well thought-out numeric types, etc.).  The
design problem is to implement, on that run-time system,
with as little effort as possible, as powerful a lisp as we
can -- and -- the same language we implement should also
be ammenable to static analysis in support of highly optimizing
compilation.  

You can describe the Scheme-pattern's nature in lots of different ways:
it's a three-register machine (code, environment, dynamic context);
it's reducible to a minimalist applicative-order-evaluation lambda
calculus; it's a more or less direct translation of an idealized
fixpoint semantics for algol-class language; it's, amazingly enough,
more or less the exact some EVAL code as an Actor language that was
arrived at via a completely different thought process; ....  It is
simultaneously, and *simply*, all of these things at once.

And that's why Scheme is important in history.   In isolation,
it might have just been a way to simplify the code in a compiler
(the rabbit thesis) or a hack for making tiny-yet-powerful
interpreters (e.g., SIOD).   But it was quickly recognized that
the same insights, the same code, reflected some of the (still)
best thinking in programming language semantics, and was being
independently invented for very different reasons (Actors).
Not only was the design problem solution effective: it seemed
(and arguably seems) to be some a priori aspect of Nature.
The Scheme solution exists independently of its multiple re-inventors
who each arrived at the same thing but from such different
directions.

Closures as the be-all-end-all of data structures;  continuations,
lambda, and application as the be-all-end-all of control; and
a unified approach to syntactic abstraction:   Scheme is not
a programming langauge but a foundation on which programming langauges
may be built.   It is a reframing of the programming language
problem that says brand doesn't matter: the liberty of continuations,
lambda and apply, and syntactic abstraction are all that matter.
Given those freedoms, anyone may have and use whatever language
they like.  (c.f. Lewis' Humpty Dumpty).  

R6RS, in my view, has a simple job.  It needs to relax constraints
on syntax and extend the reach of syntactic abstraction so that
implementors may compete and discuss various ways to permit
Unicode text or homogenous array constants in source.   It needs
to adopt a tighter, more aesthetic, more liberal definition of
some basic data types (characters first and foremost) so that
implementors may compete and discuss various ways to map Unicode
into implementations etc..   It needs to introduce *just enough* new
mechanism to support separately compilable yet interpretively
useful modules.   It needs to give a mechanism for adding new
disjoint types.  And then it needs to stop.  Just there.  That's
*all* it needs to do.

R6RS does *not* need to be split into two parts, vastly extended
in length, and to try to usurp all future research and competition
to create a standard library.   Scheme's role is market maker,
not king.


Name: Grant Rettke
Location: Milwaukee, WI, USA
My job is to write software to solve problems for which no other
solution exists, in other words, I am an IT software consultant

I want to see more "general purpose programming language features"
(GPPLF) added to Scheme. Two simple features that by name seem so
small but in implementation are so huge are modules and exceptions.
These features are so, so critical to real world programming.
Standardization here critical important to allow me to use the
distribution best suited to the task at hand; for example developing
in DrScheme and deploying on Chez.

Any good language eventually becomes a general purpose programming
language for a very simple reason; *people use it*. The additions in
R6RS are about natural growth (simple as possible but no simpler). The
addition of an object system, for example, would have been outrageous.

My stake in the outcome of this process is to see a Scheme standard
that better reflects the needs of the on the job programmer who needs
to solve problems using GPPLFs because it will make it easier for me
to sell folks on Scheme but more importantly it will make it easier
for me to do my job.



Name: Thien-Thi Nguyen
Location: planet earth (surface)

Web: http://www.gnuvola.org/software/


i like to write (and sometimes read) scheme programs.
in the process, i learn about the pet implementation that
i maintain (a fork of Guile 1.4.x), about scheme, about
programming, about the problem domains (see web-page-url)
and about my shortfalls as an amateur practicing philosopher.

i'm interested in voting on r6rs since it will affect the
future of the pet guile as well as how i continue my coding
ruminations.  if i am to support myself and my family with
scheme, it is better to know than to not know its direction.

according to M-x tex-count-words, i'm nowhere near the 150
word requirement, so this message is likely not to get me
voting privs.  but you will have read it anyway and so will
know who you will be excluding.  who knows, you might even
remember the non-valid responses and think about them later.
like scheme, people like to promise but sometimes never force.




Name: Pinku Surana
Location: Jersey City, NJ, USA
I've written three Scheme compilers, based my dissertation on
Scheme, and am now writing commercial software in one of my Scheme
variants. For me Scheme is the ideal language with which to explore a
problem. The key features that make Scheme a useful prototyping
language are dynamic typing, an excellent interpreter, and macros.
However, Scheme has not been able to build a vibrant community on par
with Python and Perl because, in part, it has lacked a common module
system. This is absolutely esential for Scheme to grow beyond its
primary audience of captive CS101 students. Along with a module system
Scheme needs facilities for library writers to communicate with each
other. This is primarily through the exception handling mechanism and
common record system. Together this should make it much easier to pool
our collective efforts to build a code library comparable to more
popular languages. Without these features the Scheme community will
remain fragmented between not-quite-compatible implementations. Scheme
remains, even today, the most productive language for me to think in.
Please don't make me use Python. 


Name: Andre van Tonder
Location: Plettenbergbaai, South Africa
I have used Scheme for research on Quantum Computation.  See, for example,
the paper: A lambda calculus for quantum computation, SIAM J.Comput. 33 (2004) 
1109-1135, which develops a linear lambda calculus for expressing
quantum algorithms.  Important in exploring the ideas and checking
the correctness of the paper was a simulator for this calculus, written in
Scheme and available at 
http://www.het.brown.edu/people/andre/qlambda/index.html.  I was the author of
SRFI-45: Primitives for Expressing Iterative Lazy Algorithms, SRFI-57: 
Records, and SRFI-72: Hygienic macros, and I have taken an active interest
in contributing to the discussion of several other SRFIs.
I am the author of one of the reference implementations of r6rs draft 
syntax-case  macros and r6rs libraries, available at 
http://www.het.brown.edu/people/andre/macros/index.html. 
I find Scheme attractive because of its simplicity and minimalism, and
would like the language to retain some of this flavour even as it
is extended to become more powerful.  I therefore intend to exercise
my vote to help ensure that the document addresses the r6rs mandate,
does not contain inconsistencies or ambiguities, and does not
exceed its mandate with unnecessary additions or unnecessarily complex
APIs.


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
I'm a long-term Scheme user for both academic and free-time projects. 
  The Scheme standard interests me because it defines the language I'll be 
  working with in the future. Voting on the draft ratification is an 
  important matter which because it defines not only the language I'll be 
  using but also the amount of effort I'll have to put into my work if I 
  want to make my code portable between implementations. Although Scheme 
  should, in my opinion, be designed to be a small language it should contain 
  all the basic modern features required by current modern programming 
  languages in order to provide implementation developers and users with 
  a powerful, expressive, and easily portable programming language. The 
  definition of a poor standard will hinder my development, my work, Schemes 
  progress as a programming language and its world wide usage. The 
  standard defined the language. I want to be part of its draft ratification.


Name: Noel Welsh
Location: Birmingham, UK

Affiliation: Untyped Ltd
Web: http://www.untyped.com/
I am a founder and Director of Untyped Ltd, a company that provides custom
web application development services.  To date all our projects have used
Scheme and we have developed a significant code base (over 40'000 lines) of
pure Scheme code.  Compared to our prior web application development
experience using other languages, primarily Java and PHP, we maintain we
gain a significant advantage by developing in Scheme.  The use of
continuations is the best known example in the community, but many other
features, such as macros and s-expressions, also play a crucial role in our
framework.  Of course we pay a significant cost for developing in Scheme,
that cost being the necessity to develop many of our own libraries, or to
fix bugs in existing libraries that have not been tested under the load our
applications experience.  A better standard Scheme would be a very
significant boon to us.  More developers means more libraries, and better
tested libraries, reducing the cost we pay for using Scheme over more
popular alternatives.  This will make our business more viable, which in
turn will allow us to drive forward the commercial adoption of Scheme.


Name: Wayne Richards
Location: Houston, TX, USA

Web: http://www.taxupdate.com
I publish several commercial applications which embed scheme interpreters.  These uses would
only benefit mildly from your efforts, because embedding an interpreter means you're married to
it regardless.  
However, I also use scheme for scripting and support applications. Unfortunately, these internal
applications end up being tied to the implementation because of incompatabilities. Specifically
for me, the issues are hashtables (or 'hash-tables' in some systems), modules, the error function
(bigloo REQUIRES 3 args while PLT accepts 1-3), structs, and non-heigenic extensions to syntax-case.
There'd be more, I'm sure, but I'm relunctant to investigate implementation extensions just because
of this lock-in factor.
I use PLT, Bigloo, and scsh for internal apps, and embed using libscheme, tinyscheme, CLRScheme,
PLT and Bigloo. Please don't hold me to the 150 words--I feel like I'm rambling already.


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

Affiliation: Brandeis University
Mail: dvanhorn@cs.brandeis.edu
Web: http://www.cs.brandeis.edu/~dvanhorn/
My interest in the Scheme standard stems from my early exposure to
Scheme as an undergraduate writing evaluators and compilers for
programming languages.  Struck by the simplicity and expressiveness of
the language, I felt I had finally found something worthy of study in
the field of computer science.  I have since used Scheme to teach the
very undergraduate courses that made me want to become a computer
scientist.  I have also used Scheme for the prototyping of the
research ideas and software development.  I provide feedback and
patches to several Scheme implementations.  Since 2004, I have acted
as an editor in the SRFI process and I've been involved as a member of
the Scheme community in the public portions of the R6RS review
process.

My hope is that Scheme stays true that simplicity and elegance that
first struck me and my involvement has been motivated in large part by
this desire.


Name: Marc Feeley
Location: Montreal, QC, Canada

Affiliation: Universite de Montreal
Mail: feeley at iro.umontreal.ca
Web: http://www.iro.umontreal.ca/~feeley
As a student I was attracted to Scheme by its simplicity,  
dynamism and
expressiveness.  My Master's and PhD theses focused on the efficient
implementation of Scheme.  Since then I have been involved in
programming language research, and Scheme has been my language of
choice for exploring the design and implementation of functional
programming languages.  I have written several papers related to
Scheme and have taught Computer Science to many students using Scheme.
I am the author of a few implementations of Scheme including Gambit,
which is well known for its performance, portability and conformance
to the Scheme standard (indeed the only fully conformant Scheme to C
compiler).  I am a founder of the Workshop on Scheme and Functional
Programming and a member of its steering committee.  I served on the
Scheme standard's editor's committee as editor-in-chief.  Scheme has
been an integral part of my daily activities over the last 20 years.


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

Affiliation: DeinProgramm
Web: http://www.deinprogramm.de/sperber/
I am a commercial user and implementor of Scheme.  As a user,
I would like to use Scheme in more commercial projects.  However, the
absence of a standard for Scheme that encourages and facilitates
distributing and porting code is a powerful detriment to the usage of
Scheme in such environments.  Moreover, I use several Scheme
implementations, and sharing code among them is at best tedious and at
worst impossible - a more substantial standard supported by several
implementations would alleviate this problem.  As an implementor of
Scheme 48, I would like Scheme 48 to be a more viable platform for
running Scheme code.  Right now, it only runs code writting in pure R5RS
Scheme (which is scarce) or code written specifically for Scheme 48.
A more substantial standard would increase the amount of portable
code, and thus increase the amount of code that runs on Scheme 48.
I am also the project editor of the standard, and thus some aspects
of my reputation and self-esteem depend on a successful standard.