Steering Committee Electors

Voter registration for the election to choose a new Steering Committee is now closed. The following is a listing of the electorate:



Name: Aaron W. Hsu
Location: Bloomington, IN

Mail: arcfide@sacrideo.us
Web: http://www.sacrideo.us
I currently use Scheme in all my major projects, and most of the little
ones as well.  This work includes research in Computer Science, but also
includes commercial products and Business Applications.  As such, the
direction of Scheme has a strong bearing on my future development
direcitons.  I use multiple scheme implementations, and generally
provide casual support to new users of Scheme.  I also teach, and use
Scheme whenever possible in these contexts.  Scheme ought to be
generally useful both in the research field and in the classroom and in
the business world.


Name: Abdulaziz Ghuloum
Location: Kuwait

Mail: aghuloum@gmail.com
My involvement with Scheme is in many aspects.  First, my
Scheme implementation, Ikarus, was the first to support a
major part of the R6RS standard.  Second, all of my academic
work (teaching, published papers, etc.) are based on Scheme.
Third, I use Scheme on daily basis for many projects.  The
outcome of the R7RS process and how Scheme is shaped in the
future directly affect all aspects of my work and thus I would
like to participate in the elections for the Scheme steering
committee.


Name: Adrien Piérard
Location: Sendai, Japan
I started using Scheme as a freshman thanks to Prof. Christian
Queinnec who did a great job in teaching us during our whole studies
the art of designing languages.
I went from Scheme to OCaml, Haskell, Erlang and Common Lisp, and
found many things that needed to be improved in each language as well
as others without which I can hardly live.
I still use all of them depending on the problem I have to solve. Yet,
the language where I'm involved the most is Scheme (mostly through
Gambit-C). I do like the simple design of Scheme and its expressivity,
but there are many points that irritate me, as I didn't go through the
whole design process since it's been created.
I do have a point of view which is more practical that what most
maintainers whom I've met seemed to have, and I do believe that Scheme
must be "split" for it's sake. Keep a small kernel à la R4RS, and have
a standard lib next to it, that evolves at its own pace. Keep what's
necessary, define it from A to Z (no more "undefined behaviour",
please!), then add everything else into the standard extension (hash,
filesystem interactions, SRFI-1, threads, some useful macros...) and
bundle the whole as Scheme. No more sparse and uneven SRFIs that
aren't implemented with the same API anyway.
In short, I do believe that Scheme has to remain minimal (kernel),
while allowing people to run useful code on any implementation that
follows the new standard (kernel+stdlib). There is also nothing wrong
about enforcing some design decisions and not being backward
compatible, provided one lets the language evolve more often that once
every decade...
In that sense, I consider participating in the election of the next
steering committee by voting, hoping it will hear my voice and that
Scheme will not be anymore a generic name for a class of programming
languages implemented without any interoperability by various academic
labs...


Name: Alan Watson
Location: Mexico City, Mexico

Affiliation: Universidad Nacional Autónoma de México
I am a professor of astronomy at the principal Mexican research
university. I use Scheme almost daily in my research and teaching. I
use it for numerical astrophysics, including a large code to model the
structure and spectra of protoplanetary disks around young stars. I
use it for teaching, to calculate exemplary models of stellar
atmospheres. I use it for instrumentation, to control detectors,
filter wheels, and an adaptive optics test bench, both in the
laboratory and at the telescope. I use it for publishing, to script
the graphics in all of my papers.


Name: Alaric Blagrave Snell-Pym
Location: Gloucestershire, England

Affiliation: Independent
Web: http://www.snell-pym.org.uk/
I use Scheme to get real jobs done. Sadly, I have yet to wrangle myself a
job where I get paid to do this, so for now, I can only use it for my own
projects (such as Ugarit, a backup/archival system written in Chicken
Scheme: http://www.kitten-technologies.co.uk/project.php?project=ugarit)
. But I'd *like* to be able to convince people to pay me to work in Scheme,
as I believe it is the most productive development language around right
now.

But, I think R6RS has jeapordised that a bit. I won't get into a rant
about it here, but I feel R6RS has started to take Scheme away from
being a small, elegant, core upon which standards like the SRFIs and
each implementation can build. I want a minimal core Scheme, upon
which higher levels can build facilities like object orientation; R7RS
does need things like a standard way for code to declare that it
requires a particular extension to it. I don't think it needs things
like records - how to extend the type system to cover disjoint record
types might be worth standardising, or it might be worth leaving to
the implementations to reconcile with their data model implementation.

I believe that such a simple Scheme core allows a variety of
implementations, while the SRFIs provide a forum for implementations
to be compatible where they can; yet allowing them to be different if
they want to. This allows innovation - Scheme has an unprecedented
number of implementations, and although code compatibility between
them is currently rather poor, I think the SRFI process is helping
there in ways that the core language itself shouldn't; but the core
language can help the SRFIs do their work, by staying minimal while
recognising the existence of extensions. The wide variety of
implementations promotes innovation into low-level implementation
techniques such as Chicken's use of the CheneyMTA system, and
specialised implementations for embedded systems and the like!

And, so, I'd like to vote for the future development of Scheme, to
keep it a great fast-moving language, with a simple core that's easy
to implement, yet onto which SRFI reference implementations can easily
be ported to bring up a fully-fledged powerful development environment!


Name: Alex Sandro Queiroz e Silva
Location: Sao Paulo, SP, Brazil

Mail: asandroq@gmail.com
Web: http://www.ventonegro.org/
I have been using Scheme for almost four years now. I use it mostly
for studying programming languages and programming in general,
prototyping and testing new ideas, but I have also developed and sold
applications written in Scheme to customers. I believe Scheme is
nowadays a maximum in the design space of programming languages and is
the language of choice of some of the best hackers of the world. I
thus deeply wish that Scheme gets getter with each new standard
revision.


Name: Alex Shinn
Location: Ikoma-shi, Nara-ken, Japan

Affiliation: NAIST
Web: http://synthcode.com/
I've been programming in Scheme for over 8 years, have
contributed significant amounts of code to the Gauche and
Chicken Scheme implementations, and authored the (withdrawn)
SRFI-56.  I've also written many popular portable libraries,
including a fully R5RS-portable pattern matching library,
the only Lisp regular expression library with a DFA
conversion, and a streamable HTML tree-parser.  New ideas
I've introduced include a flexible loop syntax which has
gained a second implementation named "foof-loop," as well as
an extremely extensive combinator-based formatting library.
I use Scheme for all my personal projects, for my current
research and MSc thesis, and use my own Scheme-implemented
HTTP and SMTP servers.


Name: Alexey Radul
Location: Boston, MA, USA

Affiliation: Massachusetts Institute of Technology
Web: http://web.mit.edu/~axch/www
My interest in Scheme standardization remains what it was the last
time the Steering Committee asked for it:

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: Andreas Bernauer
Location: Tübingen, Germany

Affiliation: University of Tübingen
Web: http://www.lysium.de
I've been using Scheme since eight years.  One of the major programs
I wrote in Scheme is the server side scripting in the SUnet
webserver. I also tried to use Scheme for administrative tasks by
writing small scripts in scsh.  However, I usually failed to use
Scheme for adminstrative tasks due to various restrictions and
impossibilities in Scheme. R5RS was not aware of character encoding,
and the current standard R6RS has no or does not endorse standard
routines for looping through text files or processing XML files, and
it misses standard data structures beyond lists and vectors such as
hash-tables, to name a few shortcomings.  So, I would like to see
the Scheme standard to evolve in a way to allow more real-world
programs which can be (more) easily be ported between various Scheme
implementations.


Name: Andrew Reilly
Location: Sydney, NSW, Australia
I have been using scheme for a couple of years, both at work
and on home, hobby projects.  I started using it both because I
wanted to learn something new about programming languages and
because I was finding the Python code that I had been working on
at the time both too slow and too ugly.  Pleasingly, I believe
that I have found what I was looking for on both counts.  My
main scheme-using project involves reading graph descriptions
in XML (produced by a different program) and then performing
a variety of manipulations.  It is, perhaps, something of a
compiler.  This is quite a different style of program than I
have created for most of my career, which has chiefly involved
numerical analysis and embedded systems.  I would not want to
write this sort of thing in my usual C, assembler or Java (I
avoid C++.)  I would like to see scheme evolve in directions
(or even just implementations) that can support both of the
latter fields as competently as any other language, and it seems
to me that the scheme mantra of providing power by removing
limitations should permit it, even if that doesn't seem to be
a particular focus of the scheme implementations that I am
familiar with (not many).


Name: Andy Wingo
Location: Barcelona, Catalunya, Spain

Web: http://wingolog.org/
I've been hacking on and on top of Guile for about 6 years now. I wrote
much of the compiler that will be in the next version of Guile. I am
interested in doing the vast majority of my future hacking in Scheme,
and for that reason am interested in the process of language
standardization. I would also like to publish my existing libraries for
other Schemers to use (not just Guilers), and to use libraries of
others. Besides that, as far as language "flavor" goes, I am
particularly interested in Scheme as a flexible, dynamic programming
environment.


Name: Anton van Straaten
Location: New York metro area, USA

Affiliation: AppSolutions LLC
Mail: anton@appsolutions.com
Web: http://www.appsolutions.com/anton/
Scheme is my favorite untyped language.  I have delivered commercial
applications in PLT Scheme, Gambit, and SISC, depending on requirements,
but I've also had occasion to use many other implementations.  I
implemented an executable version of the denotational semantics for
R5RS, in pure R5RS Scheme.  I host the Community Scheme Wiki
(community.schemewiki.org), which runs on Gauche Scheme, and the Scheme
Cookbook (schemecookbook.org), which relies on a Gambit Scheme server
for highlighting Scheme code snippets.  I served on the Scheme Editors'
Committee responsible for developing the R6RS.  I have also foolishly
accepted a nomination from some unknown sadist, as a candidate in this
election.  My use of multiple implementations gives me an added
motivation to be interested in Scheme standardization: I want to be able
to write code that's reasonably portable between Scheme implementations,
without too much trouble.  The R6RS has made large strides in that
direction, but there is more work to be done, and I intend to contribute
to that process.


Name: Arthur A. Gleckler
Location: Sunnyvale, CA

Mail: scheme@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 personal
programming projects.

I TA-ed 6.001 several times under Profs. Abelson and Sussman.  That
taught me the great value of Scheme as a teaching language.

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.  I
continue to make small contributions to MIT Scheme 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 in the IEEE Scheme standardization process in person, and
participated by email in the R6RS process.

While I was disappointed by the final R6RS draft, I voted in favor of
it to try to make Scheme a language more suitable for practical
projects.  Now it's time to swing the pendulum back a bit and make the
next standard a better compromise between the diamond-like jewel
Scheme was before R6RS and the practical, everyday programming
language that many of us have always wanted Scheme to be.


Name: Arthur Nunes-Harwitt
Location: Rochester, NY

Affiliation: RIT
Mail: anh@cs.rit.edu
Web: http://www.cs.rit.edu/~anh/
I have long been a Scheme programmer, and have found Scheme quite useful
for programming language experimentation.  However, recently (with the
release of R6RS) I have become concerned about the direction that Scheme
is going.  In particular, I was disappointed with the structure
specification, and I found it peculiar that the definition of program
structure seems to depend on the dynamic behavior of the expression.  I
anticipate that the right nominee will be able to get Scheme back on
track, and perhaps even fix some of these problems.


Name: Arthur Smyles
Location: New York, New York, USA
I currently develop and maintain an implementation of R6RS built on top of
Gambit Scheme (http://smyles.com/projects/r6gambit/). I've commented on the
R6RS standard while it was being developed. I have been developing
applications in Common Lisp and Scheme for the past 3 years. The reason I'm
interested in participating is to help establish a fair process whereby the
evolution of scheme can continue. I would like to see a process that
reduces unnecessary controversy. There are lessons to be learned from the
last round and I will be voting for people that have learned them and can
be fair and impartial on the result of the next round of standardization.


Name: Aubrey Jaffer
Location: Bedford, MA, USA

Affiliation: ClearMethods Inc.
Mail: agj@alum.mit.edu
Web: http://people.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 a wide variety of
applications.

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 4.0, Guile, JScheme,
MacScheme, MITScheme, PLT Scheme (DrScheme and MzScheme), Pocket
Scheme, RScheme, scheme->C, Scheme48, SCM, SCM Mac, scsh, SISC, 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.

Scheme-Requests-for-Implementation I wrote:
  SRFI 47: Array
  SRFI 58: Array Notation
  SRFI 59: Vicinity
  SRFI 60: Integers as Bits
  SRFI 63: Homogeneous and Heterogeneous Arrays
  SRFI 70: Numbers
  SRFI 94: Type-Restricted Numerical Functions
  SRFI 95: Sorting and Merging
  SRFI 96: SLIB Prerequisites

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.

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: 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
but I have been following the progress of r6rs with avid
interest.


Name: Ben Simon
Location: Arlington, VA, USA

Affiliation: Ideas2Executables
Mail: contact.ben.simon@gmail.com
Web: http://benjisimon.blogspot.com/
My interest in the Scheme Standardization Process is two fold.

First, I'm a professional programmer who depends on using Scheme in
production projects.  A better Scheme standardization process, means a
better Scheme Standard, which in turn means more consistent and
hopefully higher quality Scheme implementations.  This will only serve
to make the lives of industry programmers better.

Secondly, I was both excited and ultimately disappointed at the
outcome of the R6RS standardization process.  When the R6RS process
began, I felt like it was an opportunity to make a leap forward in the
Scheme language.  Instead, the result seemed to be a fractured
community and a bittersweet victory for some, and outright
disappointment for others.

But, the exciting part is that there's an R7RS ahead of us.  I'd love
to help us learn from our mistakes, and help to produce a better
process, and thereby language, in any way I can.


Name: Blot Sven
Location: Stockholm, Sweden

Affiliation: Temple at Uppsala
Had I registered to vote last time I might have stated:

 " I have been using Scheme, the best Lisp in history, for about 15 years.

   To me, the defining characteristic of Scheme is minimalism and elegance.

   I have sympathy for those who want scheme to become a viable alternative
   for building not only research prototypes but also commercial applications.

   But, 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.

   We only need to agree on adding a few missing but commonly implemented
   features. Records, low level macros, a condition system etc. "

Now we also need a rescue plan.


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

Affiliation: Purdue University
Web: http://www.math.purdue.edu/~lucier
I'm interested in relatively high-performance Scheme implementations that
can be used for sophisticated (read: somewhat large and complicated)
algorithms in Scientific Computing.  These problems include Monte Carlo
simulations, numerical partial differential equations, computational number
theory, the computable reals, stochastic differential equations, etc.

So I'm interested in various aspects of the Scheme programming language
that affect this goal: Macro systems, module systems, object systems,
floating-point arithmetic and arithmetic in general, the parts
of the language that make it easy (or not) to generate valid C
code from Scheme (since I mainly use the Gambit Scheme->C compiler),
etc.  I also act as an implementer, having built the bignum system
for Gambit.  (This was not a totally useless endeavor, as it uses
some algorithms not in gmp, at least one of which will be adopted
by gmp in the next major release.)

Obviously, languages standards influence these activities.


Name: Brent Benson
Location: Burlington, MA, USA

Affiliation: Oracle
I have been a part of the Scheme community for over 20 years.  I am the
author of the libscheme Scheme implementation that became the starting
point for the popular MzScheme system (although I don't believe any of
my original code lives on in that implementation).

I am interested in the development of a Scheme standard that describes a
language that is suitable for building large, real-world applications
without resorting to implementation-specific features, while also
staying true to Scheme's goal of beauty and simplicity.


Name: Brian Harvey
Location: Berkeley, CA, USA

Affiliation: University of California, Berkeley
Mail: bh@cs.berkeley.edu
Web: http://www.cs.berkeley.edu/~bh
I teach SICP (should I have spelled that out to pad the word count?) as our
first course for CS majors here at Berkeley.  I am also co-author, with one
of my (then) students, of _Simply Scheme_, a SICP "prequel" used in our
zeroth course for people with no prior programming background.

Although not a Scheme implementor, I've dipped my toes in the water of using
Scheme as the basis for software development.  Most significantly, a team of
students under my supervision developed a Scheme interface to the Google
mapreduce software (actually the Hadoop free version).  Mapreduce's roots
are in functional programming, but as actually designed at Google, mapreduce
uses an ugly iterator-based interface.  We wrapped a functional interface
around the Hadoop code, so our students can say

	(mapreduce (lambda (key-value-pair)
		     (map (lambda (wrd) (make-kv-pair wrd 1))
			  (kv-value key-value-pair)))
		   +
		   0
		   "/gutenberg/shakespeare")

and get back a SICP stream of (word . count) pairs indicating how often each
word is used in Shakespeare's plays.  The arguments are a mapping function
to be applied to each key-value pair (representing one line of text), a
reducing function, a base case value for the latter, and the name of a file
or directory in the distributed filesystem.  See

	http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-34.html

But my interest in the RnRS process is as an educator, not as a software
developer.  As an educator, I find two crucial excellences in Scheme:
(1) it has an interactive REPL, so that students can jump into using it
without hassling with an IDE; and (2) it is small, simple, elegant, easy to
implement if you're not worried about efficiency, and, as a result, a striking
piece of evidence for the importance of a coherent fundamental design in a
programming language.  Recent developments have threatened both of these,
turning Scheme into something much more like a single-namespace Common Lisp,
making it a redundant part of the universe of programming languages.
It is my deepest hope to slow down, or perhaps even reverse, this change.


Name: Brian Hayes
Location: Durham, NC, USA

Affiliation: American Scientist magazine
Mail: brian@bit-player.org
Web: http://bit-player.org
Like many others, I fell in love with Scheme under the spell of SICP, and
also the Little Schemer series. Twenty years ago I wrote a tutorial that
became part of the documentation for the TI Scheme implementation, and I
have written about Scheme many times since then in my work as a
math-and-science journalist. I am a user of Scheme systems rather than a
producer of them, and I see the language more as a medium for exploration
rather than as a tool for software development.  This is a constituency
that was once at the center of the Scheme community, and it's an aspect of
the language's heritage that I would not want to see forgotten.


Name: Carl Eastlund
Location: Boston, MA, USA

Affiliation: Northeastern University
Mail: '( cce @ ccs neu edu )
Web: http://www.ccs.neu.edu/~cce/
I am a graduate student at Northeastern University, an advisee of
Matthias Felleisen, and a member of the PLT research group.  I have
contributed to the Scheme community through software, original
research, and teaching.  I have written code for both the PLT and
Larceny distributions of Scheme.  I have attended two prior Scheme
Workshops.  My research software is written in Scheme, using features
that I believe are unique to Scheme, and I have a vested interest in
the future of the language.


Name: Catherine Gaudron
Location: Montreal, Qc, Canada

Mail: gaudronc@iro.umontreal.ca
My interest in Scheme come from its simplicity and ease of use. My
first contact with Scheme came in a compilation class where I wrote a
small Scheme to JavaScript compiler. I have since used the language
for most of my application writing needs, from small scripts to bigger
applications such as games and compilers, because it is simple to use
and allows me to write elegant code in an efficient manner. Lately I
have been mostly interested in using Scheme to develop web
applications.


Name: Chongkai Zhu
Location: Salt Lake City, UT, USA

Affiliation: University of Utah (PLT)
Web: http://www.cs.utah.edu/~czhu
I have been a Schemer siner 2002. I have translated the book
`How to Design Programs' (a introduction of programming book
in Scheme) into Chinese. I have using Scheme in various
places, including homework, programming tasks (aka job). I
have taught Scheme to several friends. Currently I'm working
at Utah PLT on macros. In my opinion Scheme should be easy
to learn, good at rapid proto-typing, well suited for pro-
gramming language researches and have a clear semantics.
For me R6RS failed to achieve these (even worse than R5RS).


Name: Chris Hanson
Location: Palo Alto CA, USA

Affiliation: Google Inc.
Mail: cph@chris-hanson.org
Web: http://chris-hanson.org/
I've participated in Scheme standardization since its inception, and
also maintain the MIT/GNU Scheme implementation, so consequently I
have a deep understanding of the issues involved.  While I am not too
interested in the details of standardization, I am very interested in
the process of standardization.

My dissatisfaction with the previous round of standardization, other
than in the outcome, is that there were a number of process failures
that were hastily patched when it became clear that there were
problems.  The patches helped, but didn't completely compensate for
better planning.  I'm not sure any of us could have done a better job
at that time, but I do think there are lessons to bring forward into
the next round.  Since the steering committee is responsible for
process, it should be composed of those who can effectively apply
these lessons.


Name: Christian Jaeger
Location: Montreal, Canada

Mail: christian@pflanze.mine.nu
My interest is that the community around Scheme will be continuing to
cooperate and share ideas and implementation parts positively. I think
the committee should be leaders of the communication process; they could
develop and distill ideas on their own effort, but also just help
collect and support ongoing existing ones. And community interaction
should be simple--no more words or steps than necessary to convey an
information. And transparent. Any need to say more?


Name: Christian Lynbech
Location: Aarhus, Denmark
Although not directly involved in Scheme programming at the moment, I
have had the great pleasure of basing first my thesis work on Scheme and
later had the great fortune to convince my employer to base a new
network management framework on Scheme. As part of that, I was even
registered with FSF to allow us to send code back for development of
Guile Scheme, our scheme of choice. I have for many years been an avid
proponent of the greater Lisp family and is most interested in
furthering its place in the world.


Name: Christian Queinnec
Location: Paris, France

Affiliation: Université Pierre et Marie Curie
Mail: christian.queinnec@lip6.fr
Web: http://lip6.fr/Christian.Queinnec/
I have been working in the Lisp/Scheme domain for more than 30 years.
I have written some papers and books on these programming languages.
I also had convened the ISO Lisp working group for some years. Therefore
I'm considering myself as qualified to participate to this vote.

Even if I did not want to be a candidate for the steering committee,
I am still willing to participate. I'm interested in Scheme future,
I'm unhappy with the current state of Scheme and I wish it could
change.


Name: Christian Sloma
Location: Dresden, Sachsen, Germany
I have been using Scheme to expand my horizon in what is possible in
programming languages since about 2003. Since then I converted to using
Scheme as my primary programming language for personal/recreational
programming. Lately I also somewhat jumped into the territory of library
programming by porting the Tiny CLOS library to r6rs.

My interest in the standardization process of scheme is twofold:

1. For personal programming I want scheme to maintain the characteristics
   which make it so dynamic and perfectly usable to throw together and
   experiment with different concepts.

2. For my professional carrier I would of course like to (someday) be able
   to actually programming in a big company using scheme and make a lot of
   money out of it ;)


Name: Christopher Diggins
Location: Montreal, QC. Canada

Affiliation: None
Mail: cdiggins@gmail.com
Web: http://www.cdiggins.com
I have been writing compilers and interpreters for several years for various
languages. My current compiler project uses a dialect of Scheme as an
intermediate representation that unfortunately does not respect the
standard. I am also writing interpreters that are designed to run on severly
resource constrained devices, and I would like to use a version of Scheme
internally. Instead I have found that my best option is to use Lua. It is my
opinion that it is not possible to conform the current Scheme standard and
address the needs of interpreters embedded in small application and running
Scheme on embedded devices. I think that Scheme would benefit greatly from
the introduction of formally defined profiles, such as for embedded devices,
application scripting interpreters, and for distributed computing.


Name: Daniel Villeneuve
Location: Montréal, Québec, Canada

Affiliation: AD OPT, a Kronos Division
I am one of the software architects behind the GENCOL mathematical
optimizer, which solves combinatorial problems by branch-and-price.  I
currently work as a Software Architect specialized in Operations Research
at AD OPT, a Kronos Division, where I contribute to the development of crew
planning, management, and optimization solutions for the airline industry.

Over the years, we've had three main motivations to use a flexible interpreter:
- to efficiently develop multiple variants of heuristics and control flow
  algorithms on top of our low-level core libraries (e.g., network
  algorithms, mixed integer linear programming libraries);
- to define a domain-specific language (DSL) for expressing dynamic
  programming rules;
- to manipulate problem data using a functional reactive paradigm.

So far, we've used R5RS Scheme as the specifications for our interpreter
because of the following capabilities:
- we could "easily" write our own implementation on top of the
  infrastructure library used for our solvers;
- we can provide access to solvers' data structures and functions as Scheme
  custom types and procedures, seamlessly sharing memory management
  primitives and exception handling mechanisms;
- functional programming paradigm (formalism, abstraction);
- sound macros (DSL, abstraction);
- clear semantics and small runtime library.

My interests in Scheme standardization derive from my use of the Scheme
language both as a developer and an implementor and include:
- to focus on the "core" Scheme language and its semantics;
- to make it easy to write scripts and evaluate Scheme code dynamically;
- to favor alignment with ISO C when it is both rational and possible.


Name: David Haguenauer
Location: Montreal, QC, Canada

Affiliation: Université de Montréal
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, me included.

Getting a new, standard version of Scheme is important to me; it
will hopefully 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: David Rush
Location: Dunlavin, Co. Wicklow, Ireland

Affiliation: SS&C Technologies
Mail: kumoyuki@gmail.com
Web: http://cyber-rush.org/drr/scheme
I am concerned about most matters touching on the Scheme language and
have previously been involved in the SRFI & R6RS processes. I also use
Scheme commercially for my own web-projects as well as for internal
data analysis at various employers. While my public advocacy has
declined somewhat in recent years, I am still a heavy user and am
currently participating in the process of designing a Scheme-family
language with a focus on high performance numerical computing. My
specific concerns with the Steering Committee membership are in it's
ability to adjudicate the standardization process - this is more
important than it appears and is a vital part of ensuring the quality
and relevance of the standard into the future.


Name: David St-Hilaire
Location: Montreal, Qc, Canada
As an everyday Scheme programmer, I believe that the new
standardization of our language is critical for the Scheme
community. Indeed, the last standard really divided even more the
community members, and this is *really not* what we need. I would like
to participate in this vote to ensure that the comitee of the next
standard will create a standard that will bring forward good/new ideas
to the language, but such that it will make the different
implementation specific communities closer one to another, and not
farther. We would *greatly* benefit if a good standardization would
enable us to easily share code between the different implementations
of Scheme.


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

Affiliation: Northeastern University
Mail: (at dvanhorn (dot ccs neu edu))
Web: http://www.ccs.neu.edu/home/dvanhorn/
Scheme is a beautiful language.  It was the first beautiful thing I
encountered while studying computer science.  The addiction has been
raging unabated ever since.  I declare a stake in the standardization
process as a teacher, implementor, user, and researcher.  I have taught
Scheme-based courses at Brandeis and Northeastern.  I have contributed
to several Scheme implementations.  I have, on multiple occasions, heard
every one of Olin Shivers' jokes.  I brandish weapons of mass control.
I have acted as an editor in the SRFI process since 2004, and as an
author since 2008.  I have published at the Scheme workshop and
currently serve on the program committee.  In other words, I am a member
of the community.  As a free variable, I take pride in the words 'Ich
bin ein Schemer!'


Name: Derick Eddington
Location: Ventura, CA, USA
I have known and used Scheme for 2 years.  3 years ago, I read about
Lisp ideas and was significantly influenced by them, but it wasn't until
I learned more about Scheme that I was hooked.  Scheme is by far my
favorite language and I want it to continue to advance.  Scheme has so
many merits that cause me to believe its future can be very bright.

My first year with Scheme I spent reading about it and programming many
experiments to become familiar with its various aspects.  This last
year, I have written a collection of R6RS software that explores and
utilizes features of R6RS and I have ported others' software to R6RS.
This has given me direct experience using R6RS and with its flaws and
benefits.

Because of these things, I have an interest in the future of Scheme and
I believe I am qualified to vote on it.


Name: Dirk Hüsken
Location: Tübingen, Germany
I have become interested in functional programming languages by
introduction through a university course in compiler construction. I
learned of Scheme shortly after and it has since been the language I
have been interested in the most.

Improvement of a Scheme compiler was the topic of my diploma thesis at
university. I have used Scheme as my main programming language in
several courses and for personal programming activity.

The Scheme language, by means of its small and concise, yet useful
core makes it enjoyable to experiment and work with. By casting my
vote for the members of the next steering committee, I hope to be able
to contribute to making sure the language will continue to evolve into
a direction that serves the needs of practical programmers and
educators alike.


Name: Dominique Boucher
Location: Montreal, Canada

Affiliation: Nu Echo Inc.
Mail: 460 Ste-Catherine Ouest, suite 424, Montreal (QC) Canada H3B 1A7
Web: http://schemeway.dyndns.org
I have been a Scheme programmer for more than 15 years now and a strong
supporter of Scheme in the industry. I was the first organizer of the
Montreal Scheme/Lisp User Group between 2004 and 2007.

I am also the author of a popular Scheme development environment for the
Eclipse platform, called SchemeScript. As such, not having a Scheme
standard supported by all major implementations makes it hard to provide
powerful tools usable by a large proportion of the user community. Being an
open-source project, I cannot spend all the time required to support all
implementations. And I don't want to bind my tools to a single
implementation.

I am thus very interested in the standardization process as a good Scheme
standard will allow us, tool developers, to provide more useful tools to
Scheme developers on a variety of platforms.


Name: Eli Barzilay
Location: Boston, MA, USA

Affiliation: PLT Scheme
Mail: eli@barzilay.org
Web: http://barzilay.org/
I have been using Scheme for about 16 years, I have been part of the
PLT Scheme group for more than 5 years.  I have been involved in
teaching using Scheme for most of this period (in various universities
and in a commercial setting); I wrote large amounts of code in
standalone projects, PLT libraries, and various tools that use Scheme;
and I implemented many Scheme-like languages on top Scheme.  It is
important to me to see Scheme becoming more successful.


Name: Eric Knauel
Location: Tübingen, Germany
Scheme is one of my most important tools and indispensable for my daily
work.  I'm using scheme mainly to produce prototypes of a large
commercial software application and as tool for generating test data.
More and more often, I wish that I had access to same rich set of
libraries Java or Perl users have access to.  I hope that the Scheme
standard will develop into a direction that enables sharing libraries
across Scheme implementations.


Name: Erick Gallesio
Location: Nice -- Sophia Antipolis, France

Affiliation: Université de Nice
Mail: eg@unice.fr
Web: http://www.stklos.net/~eg
I'm interested in Scheme and its implementation for nearly two
decades.  I like the original spirit of the language, its
conciseness and expressiveness. It is my language of choice for
all my programs, as well as for my text documents. As an
implementer, I'm particularly interested in the standardization
process of the language and I hope that the language will
continue to evolve. As some other Scheme implementers I was
disappointed with the last incarnation of the standard and I feel
that we need to start as soon as possible a new round of
standardization process to unify the (too small) Scheme
community which was somewhat divided by R6RS.


Name: Etienne Bergeron
Location: Montreal, Quebec, Canada

Affiliation: Octasic
Mail: etienne.bergeron@octasic.com
Web: http://www.iro.umontreal.ca/~bergeret
I'm using Scheme for more than 10 years to write many kind of application.
Scheme was the language I used to develop JIT Compiler on FPGA.  I made a
lot of compiler prototype to study the implementation of modern programming
language.  Because DATA and CODE use the same syntax, I often use it to
describe/process DSL that describe compiler phases/optimisations.
Basicaly, Scheme is my little Swiss Army Knife.

My interest on Scheme standard is to try to keep the spirit of Scheme
which let me do efficiently "my job".


Name: Felix S Klock II
Location: Boston, MA, USA

Affiliation: PRL CCIS Northeastern University
Mail: pnkfelix@ccs.neu.edu
Web: http://www.ccs.neu.edu/home/pnkfelix/
I have used Scheme for 12 years: I learned to program with MIT Scheme, then
shifted between Kawa, Scheme48, and arrived at PLT Scheme and Larceny as my
preferred development environments; thus I appreciate past Scheme
standardization efforts and understand the need for further improvements to
the standard.  During the last four years I have contributed to the Larceny
runtime system and its Twobit compiler; thus I appreciate the concerns of
both users and implementors.

That's 75 words; I am tempted to stop there (and am curious to know
whether the above would be a "sufficient" statement of interest).  I
will just add that I was interested in the R6RS development process
and was active on the r6rs-discuss mailing list.  After seeing the
community's response to the R6RS, I thought it important to register
to vote on the membership of the Scheme steering commitee.


Name: François Pinard
Location: Montréal, Qc, Canada

Affiliation: Nu Echo Inc.
Mail: pinard@iro.umontreal.ca
Web: http://pinard.progiciels-bpi.ca
I've been interested in Scheme for a long time, and before it existed,
in Lisp for even longer (I'm older than average programmers!).  I
worked at several Lisp interpreters, now obsoleted together with their
supporting machines.  For Scheme, I worked at some implementation and
packaging aspects of C-Gambit, many years ago.  Quite involved in the
GNU project at the time, I've been implicated in Guile politics before
it existed, trying hard (but unsuccessfully) to get Richard Stallman to
better respect Scheme standards.  I used Scheme in my previous company
for massive (and sophisticated) text handling duties.  Nu Echo, my
current employer, is using Kawa in production works.

As a long time Scheme lover, I've always had special interest in
the preservation of Scheme's clarity and purity, since this is what
originally attracted me in this language.


Name: Fred LeMaster
Location: Los Angeles, CA

Affiliation: Rhythm & Hues Studios
I'm interested in the future of scheme for a number of reasons. In my
spare time I develop computer games written in scheme and am working
on an image synthesizer as well. The current state of scheme
implementations ties this work strongly to a single implementation
because it requires a number of facilities that are common to many
implementations but all implemented with different interfaces. This
makes it difficult to share code or reuse code written by others
across implementation user bases.

I would like to see standard methods for libraries or modules of code
that could be reasonably portable, but I feel like scheme has strayed
very far from its core values in the r6rs spec. There must be a way to
get back to the minimal set of features mentioned in the first page of
the original report while still providing a solid foundation for
developers.


Name: George Bronnikov
Location: Moscow, Russia

Affiliation: Data X Florin
I have been familiar with Scheme from about 1995, and have been using in
professionally since about 2001.  (Systems I've used are SCM, mzscheme,
Gambit, but most extensively Bigloo.)  I am the author of the Russian
translation of SICP.  I feel that it is very important for Scheme to remain
a language with a clearly defined and well thought out core, especially for
the purposes of education. On the other hand, portability of libraries
between implementations keeps the community from fracturing, and lets
everyone benefit from each other's work.  Considerations of mainstream
acceptance are of secondary importance for me.


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

Affiliation: MIT
Mail: gjs@mit.edu
Web: http://groups.csail.mit.edu/mac/users/gjs/
As one of the inventors of Scheme, and as a heavy user of Scheme I
feel that I have a clear interest in this matter.  I use Scheme in
teaching and in research.  I used Scheme in the development of the
introductory computer science class "Structure and Interpretation
of Computer Programs," which we taught at MIT from 1980 to 2007.  I
use Scheme in "Classical Mechanics, a Computational Approach," that
I have been teaching with Jack Wisdom every fall term since 1994,
and I use Scheme in "Adventures in Advanced Symbolic Programming,"
that I have been teaching in the spring term for the last 3 years.

I am concerned that Scheme remain simple and elegant, as well as
powerful.  I was not happy with the R6RS process, because I felt
that by trying to accommodate some real concerns it lost some of
the simplicity of the earlier versions, so I I will try to take the
next step more serioiusly.


Name: Graham Fawcett
Location: Windsor, Ontario, Canada

Affiliation: University of Windsor, Centre for Teaching & Learning
Mail: fawcett@uwindsor.ca
I am an application developer at a mid-sized university. Scheme is one
of many languages I use. Several of my Scheme Web applications are in
production use on campus, probably a few hundred-thousand LOC, which
served at their peak about 1e6 requests/day. I believe that (some
definition of) Scheme hits a sweet-spot as an application-development
language, and have been very happy with the performance and
maintainability of my Scheme code.

I look forward to a day when I can declare that my next application
will be written in Scheme, and not have my colleagues look at me as if
I had two heads, or were stuck in some paleolithic reverie. R6RS may
have set the foundation for that future, but it fragmented the
community in the process. Perhaps this was a necessary growing-pain,
but my hope is that the R[789]RS processes will recover common ground
among diverse Scheme communities.


Name: Grant Rettke
Location: Milwaukee, WI, USA

Affiliation: none
Mail: grettke@acm.org
Web: http://www.wisdomandwonder.com/
Scheme has not only met, but has far exceeded its goals for academia.
With the latitude of problems faced by industrial developers today;
now is the time to let Scheme's light shine in the industry. As a
software designer and developer, my interest in this process is that
its outcome reflects the needs of "The Working Scheme Programmer".
Ultimately, though, the standardization committee must serve both
communities in R7RS.

Until now, the essence of Scheme, "Programming languages should be
designed not by piling feature on top of feature...", has served
academia well, but not the industry. Consequently, the community has
moved forward independently from the standard. While this is not a
problem in and of itself (the SRFIs, for example, have served the
community well); incompatible changes have been made between
distributions resulting in frustrating incompatibilities. Solutions to
standard problems like modules ought not to require any effort to be
made portable across different implementations.

The efforts of R6RS, the first step at addressing the needs of both
communities, were largely marred by the dissatisfaction with its
result. The community simply felt that the report did not hold true to
the spirit of Scheme.  It is that spirit which will be so important
not only to the community, but to the steering committee itself, in
moving forward with R7RS.

At one moment in time, Scheme itself was an experiment. Scheme
encourages experimentation. Sometimes experiments fail, though, and
when they do, it is up to the scientist to learn from the mistake and
keep moving forward. The outcome of R6RS can either be used as an
excuse for the community to disband, or as a lesson on how to move
forward.  I choose the latter.

The new steering committee needs to focus on the processes and
procedures that allow for both communities to be served in the manner
that best realizes the spirit of Scheme; doing so in a manner that
honors Scheme's past, listens to the voice of its community today, and
steers diligently towards the future.


Name: Gregory Marton
Location: Cambridge, Massachusetts, USA

Affiliation: MIT
Mail: gremio@acm.org
Web: http://csail.mit.edu/~gremio
GNU/Guile is essential to my PhD work, which assigns programmatic meanings
to words and phrases of English, so that the meanings of the words in a
phrase may combine via function application and composition to form a
meaning representation for the phrase as a whole.  I am working most
closely with time expression semantics, with a view towards understanding a
phrase like "just before last Thursday's morning hearing" as a probability
distribution over a timeline.  This project exercises Scheme especially,
because I use aspects of genetic programming, automatically generating
S-expressions as meanings for words.  This entails generating edge cases
and code that a human might only produce by mistake, and employs the beauty
and simplicity of the language in expressing complex semantic interactions.


Name: Guillaume Cartier
Location: Montreal, Quebec, Canada

Web: http://www.jazzscheme.org
I discovered Scheme 20 years ago as a student through reading the
Little Lisper and it was love! The last 20 years have been a constant
effort to build the necessary tools to be able to do all my
programming needs using this wonderful language that is Scheme. As
such, I implemented many Scheme implementations over the years. I also
coached Scheme to new programmers in a company that at one point had
more than 50 programmers working full time in Scheme. Recently, in the
interest of code sharing, community, ..., I spent the last 2 years
open-sourcing and rewriting my own Scheme implementation that was
implemented in C++ as a macro on top of other Scheme implementations.
As such, my interest in the evolution of Scheme is now even greater
than it was and it was always great! Thank you all for the wonderful
work on standardizing Scheme over the years.


Name: Hal Abelson
Location: Latitude: 42.3369444 Longitude: -71.2097222

Affiliation: MIT
Mail: hal@mit.edu
Web: http://people.csail.mit.edu/hal

The voter indicated that he would like to submit the first chapter of Structure and Interpretation of Computer Programs as his statement. The Steering Committee agrees that this does fulfill the requirement, given that the voter did write it, and it is more that 75 words long. Unfortunately we don't have the space to reproduce it here, but it can be found online at http://mitpress.mit.edu/sicp/.



Name: Harold Ancell
Location: Joplin, MO, USA

Affiliation: none
Mail: 2009-scheme-steering-committee-vote@ancell-ent.com
Computer Science: My major interest is in languages, the paradigms
they enable, encourage or discourage (e.g. functional programming,
multiple cores, etc.), 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 watched 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 scheme standardization effort will further all of my above
interests and goals.


Name: Ivan Raikov
Location: Okinawa, Japan

Affiliation: Okinawa Institute of Science and Technology
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 a
vast number of very flexible compilers and interpreters for Scheme,
unlike other high-level languages used in scientific modeling, and
because Chicken Scheme already had many convenient libraries
available.

I strongly believe that one of the reasons why there are so many
good compilers for pre-R6RS 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. I believe
that this simplicity makes pre-R6RS Scheme the best environment
for building special-purpose languages and code generators, which
is a very unique and important role.

I think the greatest strength of Scheme is diversity, and therefore
future revisions of the Scheme standard must strive to maintain and
nurture the vast ecosystem of Scheme implementations, even at the cost
of reduced portability, rather than attempting to force changes that
disregard the needs of small Scheme communities.


Name: James Copus
Location: Colorado Springs, CO, USA

Affiliation: Hardsoft, LLC.
I do a large amount of commerical and non-commerical development. I'm
interested in portability of code, performance, and flexibility. My
company and I are currently writing games/gaming libraries, business
programs, and advanced math libraries that may or may not be
implementation independent, depending on standards. I'm also
interested in guidelines for mathematical representation, port
behavior, and non-scheme code integration. I'm looking to use scheme
as the exclusive language for most of my (and my company's) programs
and highly value and enjoy my coding time and effort.


Name: Jay McCarthy
Location: Provo, UT, USA

Affiliation: Brigham Young University
Mail: jay.mccarthy@gmail.com
Web: http://www.teammccarthy.org/jay
As an avid user of Scheme, both personally and in my research, I am
intensely interested in the outcome of any standardization processes.
Furthermore, as a member of the PLT Scheme implementation group, the
standardization has a real impact on me. (In particular, I manage the
PLT Web Server, so aspects of the Scheme standard that are conducive
towards Web-oriented programming are very relevant to me.) I'm a true
believer in Scheme, so I care that the standard is well-suited to the
goal of extending its domination across the computing landscape.


Name: Jean-Michel Hufflen
Location: Besançon, France

Affiliation: LIFC; University of Franche-Comté
Web: http://lifc.univ-fcomte.fr/home/~jmhufflen
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
particular, I point out that the functional programming allows a precise
approach suitable for developing large programs. 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 have developed 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. I am presently making it R6RS-compliant. Some people from the
TeX-Live team have used it, and result is encouraging, but there are some
improvements to do. It is my intention to maintain it, so I am interested
in the future of Scheme.


Name: Jeff Bezanson
Location: Boston, MA, USA

Affiliation: Interactive Supercomputing, Inc.
Mail: bezanson@post.harvard.edu
Scheme is probably my favorite programming language. The world needs a
small, elegant, and standard Lisp dialect, because such a language provides
the most convenient notation for communicating programs and data. Scheme is
well-positioned to fill this role.

I have done a few Scheme/Lisp implementations; two were instructional toys
(I was a teaching assistant for a course in Scheme for several semesters),
one is half serious, and one is just very small
(http://code.google.com/p/femtolisp/source/browse/trunk/femtolisp/tiny/lisp.c).
I have also been through what Steele and Gabriel describe as the "rite of
passage" of designing my own Lisp dialect and syntax and ultimately
concluding that we're better off with s-expressions.

I want to see Scheme remain (or revert to being...) concisely implementable
and comprehensible, lest the human species collapse under the weight of too
many lines of code we can't understand or execute. I've found that there's
no better way to understand a programming language than to implement it, so
if we want programmers to know what they're doing implementability could be
more important than people might think.

Scheme should be small enough that its core can be slipped unnoticed into a
larger software package, making it easier for us to deploy our secret
weapon.  I also believe Scheme should bow more to "modern conveniences" to
help build popularity as a scripting language (for example, an external
representation of hash tables, or more generic operators).


Name: Jeffrey T. Read
Location: Medford, MA, USA
I have come to deeply admire Scheme's design. It is fire from
Prometheus, an emanation directly from the realm of platonic ideals. A
small, simple language core gives us the ability to talk about
procedural, functional, and object-oriented programming in their own
terms and to build complex, powerful linguistic constructs out of the
simple ones the language supplies. It's one of the few multiparadigm
languages that address many different programming modalities through a
single model, rather than being forged in one paradigm and having the
others added on as "bags on the side" (e.g., C++).

So why hasn't it caught on? Applications. Most software is not
theoretical, but is rather written by people who have a real-world,
specific need to fill. Scheme serves well as a proving ground for new
language concepts, but hasn't adapted well to the application realm on
its own. Rather, a variety of implementations have proliferated, each
with their own set of ideas of how to extend the language to do real
work on common computer platforms. I am interested in a process that
bridges the gap between theoretical neatness and a common ground with
which to address practical software issues. I would be a staunch
advocate if such a process yielded a small, neat, orthogonal language
core and a set of optional, but strongly encouraged, satellite
standards for library functionality. R5RS+SRFI was a step in the right
direction, but with R6RS the process took a turn towards putting too
much in the language core.


Name: Jens Axel Søgaard
Location: Skjern, Denmark

Web: http://www.scheme.dk/blog/
Ever since I was introduced to Scheme I have been enamored
by the combination of clear semantics and macros. The
combination makes it a great tool for the curious programmer,
who likes to experiment with either new language constructs,
or self-written implementation of known constructs.

As a teacher I am greatful for the energy the Scheme community
has put into books and tools for students to learn programming.

The innovations of the latest standard revision R6RS were
important in order for the Scheme language to evolve. The long
period of time between R5RS and R6RS was unfortunate, so I
hope to see new revisions with regular time intervals between.


Name: Jeremie Lasalle Ratelle
Location: Montréal, Canada

Affiliation: Université de Montréal
I have been using scheme for 4 years both in my academic work and in
industry projects. I am currently a Master's student under the supervision
of Marc Feeley working on implementing multi-processing and distributed
computing constructs in the Gambit-C compiler. I have also worked on
Guillaume Cartier's Jazzscheme project which is a full an open source
programming language based on Scheme including a full featured
cross-platform framework and a sophisticated programmable IDE. I
implemented the cairo backend and ported the language to
Linux/X11. Finally, I worked on several contracts for Metascoop inc., a
Montreal based company that use Jazzscheme exclusively.


Name: Jeremy J. Sydik
Location: Lincoln, NE, USA

Mail: jsydik@gmail.com
Web: http://jeremy.sydik.com
While I have interest in someday implementing a scheme (for the somewhat
mythical value of someday guided by graduate programs and children), my
primary involvement is as a user of the language.  My reasons for using
scheme professionally are focused on developing applications to enable
research in cognitive and educational psychology as well as to provide
software solutions to students.  Further, as a doctoral student in
educational psychology, I am interested in the research relating to scheme
both as a tool for developing tools for education and as a proven language
to use as basis for teaching notions of computation to learners.  I've used
the PLT, Guile, and Chicken dialects as well as dabbled with Gambit and the
non-scheme CL (of course) and Clojure lisp dialects.  My interests in the
product produced by this process are to see defense of the minimalist
tradition of RNRS for the core language (though I am certainly open to
seeing an accompanying "standard library" document, preferably based on
existing SRFIs and the SRFI process as a matter of furthering portability
between implementations)


Name: John Clements
Location: San Luis Obispo, CA

Affiliation: Cal Poly State University
Being a Scheme advocate is both thrilling and tooth-gnashing.  On the
one hand, Scheme represents a magnificent "blank slate" for new
features and discoveries, but on the other hand is "passed over" TIME
AND TIME AGAIN in the "trendy-language-of-the-year" competition.  I
suppose some find that a virtue: it means that Scheme is relatively
unencumbered by legions of users who kick and scream every time the
language changes in even minor ways, and who write great enormous
masses of truly horrible code (cf. JavaScript).  On the other hand,
it's frustrating to have discussion after discussion with colleagues
who refuse to consider Scheme as a realistic pedagogic choice simply
because dice.com shows fewer than 150 hits for "Scheme", and those
results include (on the first page, no less) an advertisement for
Northrop Grumman for an Antenna Engineer--clearly, an accidental use
of the word "scheme".


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

Affiliation: None
Mail: cowan@ccil.org
Web: http://ccil.org/~cowan
> Lorem ipsum dolor sit amet, consectetur adipiscing elit.  Nunc placerat,

(I'm tempted to write this in dog-Latin, but I will refrain.)

While fundamentally content with the results of the R6RS process,
it is not, nor should it be, the final word on Scheme.  Furthermore,
if Scheme is to survive the current generation of Schemers (of which
I am neither the oldest nor the youngest), it must be handed down.
We need new bloooooooooo -- excuse me, new blood.  Though I have
not implemented Scheme nor used it as extensively as many community
members, I still do not want to see it perish, as it surely will if it
does not come up to date, discarding the non-essential while preserving
the essential elements of the tao of Scheme.


Name: John David Stone
Location: Grinnell, IA, 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 -- 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 examples and
demonstrations.  My interest in the standardization process is to keep the
core language small, simple, expressive, and accessible to novice
programmers.


Name: John Fremlin
Location: Tokyo, Japan

Affiliation: MSI (www.msi.co.jp)
Mail: john@fremlin.org
Web: http://john.freml.in
I have been programming in Common Lisp for a few years. I should like to
have a reasonable alternative that does not enshrine years of bitrot
into the language standard. Several Scheme implementations are very
promising but it is hard in practice to write portable programs. Having
multiple (more or less) compatible implementations is one of the key
benefits of Common Lisp and it is very unfortunate that there is no
strong competitor in Scheme.

I am concerned about the direction that Scheme took with R6RS and hope
that the addition of my small voice to the clamouring crowd will result
in a better Scheme.

In terms of the politics, my position is that the Scheme committee
should opt for a much smaller core language standard and a much larger
set of standard libraries.


Name: Jonathan A Rees
Location: Arlington, MA, USA

Affiliation: Science Commons
Web: http://mumble.net/~jar/
I am interested for a few reasons. First, I write programs in Scheme and
want the community to develop better languages, systems, and libraries for
me to use. Second, I am interested in programming languages and see Scheme
as a place where interesting design work and outreach might happen.  Third,
I have been in the Scheme community for a long time (1978) and care about
it out of habit and affection. Lastly, I have been nominated to the
Steering Committee and registering will give me an opportunity to influence
the choice of co-members, in the event I should be elected.


Name: Jonathan A. Smith
Location: Evanston IL

Affiliation: Northwestern University
Web: http://airenaissance.wordpress.com/
I have been using Sceheme since the 1980s both for classwork (graduate
school at NYU) and for experimental projects. I have always
appreciated both the minimalism and expressiveness of the language.
I plan to use scheme Scheme as part of the core core of an informal
education project that will get working programmers involved in AI
programing. I also continue to to use Scheme as my main language for
exploratory work. I would like to see the language become even more
usable by programmers who are new to the language but want to use it
for substantial software development projects.


Name: Jose Antonio Ortega Ruiz
Location: Barcelona, Spain

Affiliation: Oblong Industries
Mail: jaortega@gmail.com
Web: http://hacks-galore.org/jao
I've been using scheme for around 10 years, with contributions to some
implementations (Guile, and the now defunct Pika). My GNU MDK program (a
development environment for Knuth's MIX) uses scheme as its extension
language. At work, scheme will be one of the languages to which we'll
provide bindings in distributed computing and next-generation UI
frameworks during the following months (see http://oblong.com). How
scheme evolves in terms of standardisation and interoperability is thus
very important to us.


Name: José Romildo Malaquias
Location: Ouro Preto, MG, Brazil

Affiliation: Universidade Federal de Ouro Preto
Mail: romildo@iceb.ufop.br
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 amazes 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 conformant to the standard.


Name: Jude Arnout "Biep" Durieux
Location: Bamako, Mali

Web: http://www.biep.org
In addition to what I wrote to register for the R6RS vote, the following: I
think it is imperative to steer Scheme back onto the correct course before
it is too late.  Undoing a standards decision is already not easy, and the
longer the standard has been in use, the harder it becomes.

With R6RS we have lost the implementation of an ideal, and I want it
back.

Maybe in the end it will turn out to have been a good thing,
because once one accepts to revert some things, why not others that we
now recognise as suboptimal.


Name: Jules Altfas
Location: Portland, OR, USA

Affiliation: BMedCTR
Computers, and crafting software, are essential elements in my working
life.  For >25 years, I've developed and maintained crucial software
(sometimes even hardware) necessary to running a business.  Practice, as
opposed to theory, predominates our attention. Primarily, activity has been
in the domain of database applications, from backend to frontend.  I've
used a variety of tools/languages, including C, C++, Java, Tcl/Tk, Scheme,
et.al.  We've experimented with a wide range of programming styles, e.g.,
creating our own object-oriented systems in several languages, thus have
hard-won experience and deep interest in "real-world" aspects of computer
use and application.

The role of Scheme in our work has recently grown.  We needed to extend
database interfaces using the Internet/WWW, meaning web servers in
particular.  In our hands Scheme has proven uniquely suited to the task: a
natural fit, its "expressiveness" making it a joy to apply, and enabling
far greater productivity than anticipated.

Interest in standardization processes derives from a strong desire to see a
really useful tool remain useful.  We are well aware that attempts to
"improve" computer languages often seem to increase complexity and hinder
usability.  Java is an example, rather simple early on, but growing to an
enormous, unwieldy mass of specified APIs, interfaces, classes,
innerclasses that many wish to avoid.

The controversies evoked by R6RS seem to echo similar concerns, that it is
overly rigid, too detailed, and inihibits flexibility more than necessary
or desirable.  Portability is a worthy goal, very important to software
creation.  Scheme implementations inevitably offer differing sets of tools.
Programmers will likely need to use one Scheme or another to solve
particular problems, e.g., cross-platform utilization and obviously it's
beneficial to be able to use the same code-base unmodified.

At the same time, implementations will always have their quirks.  After
all, not even C compilers are completely consistent in implementing
language features, code output and so on.  There must be room for
differences.  Standards exist to assure there isn't intolerable divergence
among them.

Therefore we have a stake in assuring community input to the process of
refining standards for Scheme.  A pragmatic, inclusive ethic will be most
likely to produce results we can all support.  Voting is the best way to
participate to make sure that happens.


Name: Julia Lawall
Location: Copenhagen, Denmark
I have used Scheme in my research work, and a number of my students use
Scheme in their projects.  Furthermore, the Scheme language has been the
host for a number of significant programming language research advances,
such as in the understanding of macros, continuations, and partial
evaluation.  Therefore, it is important to me to ensure that the language
continues to evolve in a direction that will make it both a practical tool
and a setting for further development and understanding of programming
languages concepts.


Name: Karoline Malmkjær
Location: Århus, Denmark

Affiliation: Tieto
I was first introduced to Scheme during my Master's studies and used it
extensively in my Master's Thesis (on computational reflection) and in my
PhD dissertation (on partial evaluation).  In at one of the companies
that I have worked for since my graduation, Scheme was used commercially.
Although I currently work in C for our deliverables, I still follow the
evolution of Scheme with interest, since I prefer and encourage the use
of more expressive and reliable languages, such as Scheme, for our
internally controlled processes such as test generation or regression
testing.


Name: Ken Dickey [Kenneth Alan Dickey]
Location: a clearing in a forrest on an island off the west coast of North America [Freeland, WA, USA]

Affiliation: random/unaffiliated
Mail: Ken [dot] Dickey [at] whidbey [dot] com
I have had a long time interest in programming languages. My
introduction to Scheme was an interpreter named iLisp which ran on my
z80/64k computer in 1980.  When SC&P came out I wrote a simple Scheme
compiler in Franz Lisp.  Since then I have written a number of object
systems and random code on a large number of Scheme implementations.
I wrote a Smalltalk to R5RS Scheme translator (98% in Scheme) which
passed the test suite. I attended all the R4RS & IEEE Scheme standards
meetings.  Since R6RS came out I have been writing code which works
across Larceny, Ikarus, PLT and Ypsilon implementation.  Yadda Yadda.
I am still writing Scheme code, so I guess I am still interested.  Are
my 75 words up yet?


Name: Kon Lovett
Location: Mill Valley, CA, USA
I maintain, not exclusively, the Chicken Scheme implementation, in addition
to authoring extension libraries. My interest in the Scheme standards
process is implicit.

I do not wish to rehash the many objections to R6RS, except that, in the
words of a ratification vote comment, and the spirit of many others: the
resulting language is "Neither fish nor fowl."

While I attempt to not be egregiously Chicken specific, performance issues,
both programmer and machine, make this difficult. A robust, rigorous, and
small, core language and the SRFI process makes this easier. Sadly, R6RS
made this harder.

I hope the new committee will seek, and achieve, a balance for R7RS that
the previous report lacked.


Name: Laurent Bloch
Location: Paris, France

Affiliation: Université Paris Dauphine
Mail: Laurent.Bloch@dauphine.fr
Web: http://www.laurentbloch.org/
I am teaching programming for Bioinformatics for 14 years, and the
main programming language used for that is Scheme. In order to give
the course, I wrote a textbook for Scheme programming initiation :

http://www.editionstechnip.com/F/bloch_initiation_programmation_avec_1004.asp

and I opened a site :

http://www.laurentbloch.org/spip.php?rubrique4

So, the evolution of the language is of great interest for me, as
far as I need some features in the language, I like (and my students
like) some others, and some I don't like. For these reasons, I think
I am sufficiently involved in the process of defining the Scheme
language to be admitted to the vote. Cheers.


Name: Lenny Frank
Location: St. Louis, MO, USA

Affiliation: Chicken
Scheme is my programming language of choice, and has been for around ten years.
I am one of the core maintainers of Chicken Scheme.  I have been active on
the R6RS discussion list whenever I have had network access; additionally,
I was initially involved with the ERR5RS formation.  My interest in a good,
clean, useful, and elegant standard for Scheme should be fairly apparent.
What more are you looking for?  Seventy-five words is a bit long to express
the basic idea of "I'm involved with the community in both a theoretical and
practical sense and have been for some time".


Name: Llewellyn Pritchard aka leppie
Location: Cape Town, South Africa

Affiliation: IronScheme
Web: http://www.codeplex.com/IronScheme
As the author of IronScheme, a R6RS Scheme for the .NET CLR, I have a
vested interested in future developments of the language.  As a relative
newcomer to the Scheme community, I do not have much input, but would like
to be part of this process.  I have in the past contributed to the R6RS
mailing, and identification of errors in the R6RS specifiactions.  I am
also active in the comp.lang.scheme newsgroup.


Name: Louis-David Perron
Location: Laval, QC, Canada
I'm a Scheme user since 2005. I mostly use Scheme as a programmer. I'm not
a power user, I don't know the specific internals of the Scheme compilers
or interpreters and I'm not interested in compilers development. But I do
believe that my opinion or vote, as a user is as important as the
developers to make Scheme alive. There are now tons of implementations of
Scheme available, and most of them have their own languages extensions,
which makes some code non-portable, and may confuse a lot of programmers. I
wish that the steering committee find a way to give a new reference
standard that will evolve Scheme language to a step where extensions become
useless.


Name: Luc Charest
Location: Montréal, Canada

Affiliation: Kronos
Mail: LuckyLuc@gmail.com
Web: http://www.luckyluc.ca
I have been a Schemer for not quite long, but have been a quite good
C++ programmer for eons. I find Scheme is as simple as attractive and
yet, so much powerful. Above all, my fear is that it become one day
something like Java, where there is a pile of junks sitting in the
library, while the language is getting uglier with each new versions.
A growth too fast of a standard is a good way of killing a language,
and attempting to cover everything is necessarly not a good thing.
Things takes time and it is normal to stop and think on how to do
things well. I place great hope in some of the nominees I wish to vote
for. Thanks!


Name: Manuel Serrano
Location: Sophia Antipolis, France

Affiliation: Inria
Web: http://www.inria.fr/sophia/members/Manuel.Serrano
Committed to Scheme since many years, I have conducted several
projects based on or dedicated to Scheme. First, since 1993,
I'm developing and maintaining the optimizing Scheme compiler, BIGLOO.
Since 1993, at least two new major versions have been released per
year. Then, I have created a graphical user interface toolkit for
Bigloo named BIGLOOK. Although this software has hardly evolved these
last years, it is still available from the BIGLOO's web site.

In 2005, I have initiated the HOP project. HOP is a new programming
language and a new runtime system dedicated to writing interactive
softwares on the Web. HOP is also a functional programming language
tightly related to Scheme.


Name: Marc Feeley
Location: Montréal, Canada

Affiliation: Université de Montréal
Mail: feeley@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.  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.  I am currently a nominee for the Scheme steering committee.


Name: Marco Benelli
Location: Fabriano, ITALY
I'm a professional programmer with a background in Physics.

I've been using Scheme from several year: i've learned fundamentals of computer
science with it, and i've used it in my researchs over the years, releasing a
pair of little open sourced projects.

As freelancer software developer/consultant I see every day the well-known
impedance for a wider adoption.  I think, like many others, that the main cause
of this impedance is rooted in community fragmentation.

I really like the vitality caused by multitude of implementation, and I hope
that, in order to turn this vitality in a strength, it will be possible to
found the right balance between schemer's aspirations to purity, fun and
pragmatism.


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

Affiliation: Seton Hall University
My interests in Scheme are diverse ranging from research interests, as
a person that works on the implementation of
functional languages, to pedagogical interests, as a person that
actively uses Scheme in the CS courses I teach. After
years in the field of programming languages, I have no doubts that the
Scheme continued standardization process is
beneficial to all its users. The stadardization process provides a
common point of reference for both implementors and users.


Name: Marcus Crestani
Location: Tuebingen, Germany

Affiliation: University of Tuebingen
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.  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
role in my PhD thesis.  Scheme and where Scheme is going is really
important for my work.


Name: Marek Kubica
Location: Munich, Bavaria, Germany

Mail: marek@xivilization.net
Web: http://xivilization.net/
I am a Scheme enthusiast wanting to use Scheme for real world
applications running in portable ways under standard conformant
implementations. Therefore I'd like to see a new version of the Revised
Report that will adress the issues that some implementors had with R6RS
so that there will be a common ground that implementors can agree on
and library writers can rely on. Plus, I'd like to see a standard which
is easy to understand and to learn from as well as to be used as a
reference in a convenient way.


Name: Mario Latendresse
Location: Menlo Park, CA, USA

Affiliation: SRI International
Mail: latendre@ai.sri.com
I have been using Scheme since 1993 in my academic and industrial
projects. My PhD dissertation, on compressed executable code for
virtual machines, used Scheme as a target language. I participated to
the development of a Scheme implementation as well as used several
Scheme implementations for industrial applications. I have published a
few papers on Scheme and related subjects. I have followed the
evolution of Scheme for the last fifteen years and I expect to still
use Scheme in the foreseeable future. I am interested in its evolution
as a simple, efficient and practical programming language.


Name: Mark Shirley
Location: Santa Clara, CA, USA

Affiliation: NASA Ames Research Center
Mail: Mark.H.Shirley@nasa.gov
I'm a long-time lisp and scheme programmer having learned lisp in
'78 and read the lambda papers and Rabbit thesis in '80.  I'm mostly
interested in Scheme standardization from an application
programmer's perspective.  I want scheme to maintain its wonderful
conciseness and flexibility while keeping up with progress in the
rest of the computer world.  Often, I'm forced to choose between
some capability scheme has (e.g., nondeterministic programming via
call/cc) and another capability it doesn't have (e.g., convenient,
standardized production of a modern gui).  Sadly, scheme usually
loses out because it just takes too much time to reproduce what
python and a host of other languages have.  This, of course, has
everything to do with the library system and the robustness of the
community and library creation processes, and little do to with
other features of the language.  But that's where I'm coming from.


Name: Martin Lizee
Location: Montreal, Quebec, Canada

Affiliation: Gamerizon
I co-founded a company that is currently using scheme to produce
entertainment software for a variety of platforms.  Scheme plays a key role
in our production process, as a data language (instead of XML), as a glue
language between applications and for build process, and as a designing and
programming language with the capacity to be adapted to all our target
platforms.

Scheme is not only a great language to program with but mostly a great
language to think in.  Behind its deceitfully simple syntax, lies the most
expressive language I know, and I would like the Scheme standardization
process to preserve these key features, which explains our company wide use
of Scheme.


Name: Matt Jadud
Location: Meadville, PA

Web: http://www.untyped.com/
I teach and use Scheme. Neither my use of Scheme in or out of the
classroom is particularly radical, but the language plays an important
part in both contexts. In the classroom, I use the language to
introduce students to the process of software development through the
use of good process and testing from an early stage in their studies.
In my research and work, I use the language for the back-end of a
compiler and in supporting colleagues who make a living writing
web-based applications in Scheme. For all of these reasons, I am
interested in the future direction of the Scheme programming language.


Name: Matthias Felleisen
Location: Boston, MA, USA

Affiliation: PLT
My interest in the standardization process is purely
  selfish. I wish to ensure that "Scheme" continues to
  be a recognized brand name among academics,
  educators, and programmers.

My interest in the standardization process dates
  back to 1986, when I attended a meeting at MIT on
  post-R3RS work on behalf of my advisor.

Technical Background: I founded PLT. I contribute to
  the PLT Scheme code base, and I have used Scheme for
  educational purposes since 1984.

(The text is in a file on my desktop, called foo.txt,
and wc shows 75 words:

[:~/svn/2HtDP] matthias% wc foo.txt
       12      75     465 foo.txt
)


Name: Michael Lenaghan
Location: Toronto, ON, Canada

Affiliation: Dazzit! Corp.
I have been a professional software developer for more than 15 years.
I have developed a number of commercial software applications; several
of them have had wide distribution. I have used a variety of programming
languages for those applications and I have used an even wider set of
tools and languages in my prototypes.

I am now working (together with a small team) on a high-performance
web-based product. We initially considered a number of different languages
for that product and, through experimentation, narrowed the list to Lisp and
Scheme. We then evaluated a number of Lisp and Scheme implementations
and eventually settled on Chez Scheme.

We originally intended to use Scheme only in our product core (a highly
specialized database). But the performance and reliability of Chez, together
with the expressivness of Scheme, made it the right choice for nearly every
aspect of what we were working on.

We take advantage of much of what Scheme (and Chez) have to offer. We
have several domain-specific languages; we compile some of those languages
to native code at run-time; we load user-defined modules at run-time; we are
fully multi-threaded (and scale well on multi-core machines); we support a
number of different platforms; we support a number of different web servers;
etc.

Given all of that we are highly invested in Scheme--and thus interested in its
future.

Although I appreciate and agree with the broad goals of R6RS I have issues
with the final result. I hope--as unrealistic as the wish may be--that the
primary goal of R7RS is to shrink the R6RS language rather than grow it.


Name: Michael Sperber
Location: Tübingen, Baden-Württemberg, Germany

Affiliation: none
Web: http://www.deinprogramm.de/sperber/
I have come to crucially depend on Scheme for a variety of tasks: As a
free-lance software developer, I mostly earn my living writing software
in Scheme.  As a researcher, I write papers on Scheme.  As an educator,
I use Scheme to teach beginners how to program.  I view Scheme as
superior to other languages for these tasks.  If Scheme were to decline
either in community support or quality, my ability to use it in some or
all of these areas of interest would be negatively affected.  Moreover,
I have spent large amounts of time and money to help the language and
its community make progress: I maintain Scheme 48, an implementation of
Scheme; I was one of the founding editors of the SRFI process (and
continue to serve there); I sat on the PC of two Scheme workshops,
chaired another one; I served as editor-in-chief of R6RS.  Consequently,
I have a large stake in the continued viability and development of the
language.


Name: Neil Jerram
Location: London, UK

Affiliation: Guile (http://www.gnu.org/software/guile)
Mail: neiljerram@googlemail.com
Guile is an implementation of Scheme, and I am one of Guile's (two)
current maintainers.  I also followed large parts of the R6RS draft
discussions, and commented once or twice.

Personally I think that should suffice as a statement; please let me
know if you really need more.  The rest of this paragraph is only here
in order to reach the required minimum of 75 words (although I accept
that it was my omission not to have queried this earlier).


Name: Neil Van Dyke
Location: Cambridge, MA, USA

Affiliation: independent consultant
Web: http://www.neilvandyke.org/
I am an independent consultant on software systems, mostly using
Scheme.  I am currently working on a large system implemented primarily
in PLT Scheme, and deployed for use by numerous organizations.  I have
been developing in Scheme for about 8 years, and am the author of
several open source portable Scheme libraries (e.g., HtmlPrag, csv.scm),
and a few that have to be PLT-specific at this time.  I have commented
on SRFIs.  I am interested in standards that further what is good about
Scheme, while also permitting more of my consulting and open source
library work to be portable.


Name: Nicolas Scott
Location: Montreal, QC, Canada
I am a master degree student in computer science at the university of
Montreal. I had the chance a few years ago to meet Guillaume Cartier
and to contribute for a short time to the Jazz language. Even though
I'm now busy working on other projects, I'm still following the
progress of JazzScheme and hope to be back some day on that great
venture. To fulfill that hope I'm keeping an eye on the future
evolution of Scheme.


Name: Olivier Breuleux
Location: Montréal, Canada

Affiliation: Université de Montréal
I have become familiar with Scheme a few years ago, when I was an
undergrad. It was during a compilation course given by Marc
Feeley at University of Montreal (and then during a summer
internship at his research lab) where the ease of manipulating
Scheme code using the language itself was made useful. This is a
context where I have been able to understand the language's
inherent advantages and utility to programming language research,
as it is both powerful and easy to implement. I also find that
the simplicity and flexibility of Scheme leave a distinctive
impression of freedom: it is a language that is accessible to
anyone yet can be molded to one's liking. For these reasons, I am
interested in following its evolution and I hope it can progress
in new directions while staying true to itself.


Name: Olivier Danvy
Location: Aarhus, Denmark

Affiliation: Department of Computer Science, Aarhus University
Web: http://www.brics.dk/~danvy/
I am still in love with Scheme and with programming in Scheme after all
these years.  When I joined HOSC as co Editor-in-Chief, my very first
editorial act was to have R5RS appear as a special issue.  Today Scheme
is part of my teaching and research toolset.  I teach it to the
first-year students here in Aarhus, and it is at the heart of my work,
eg, on normalization by evaluation and on two-level programming.


Name: Patrick Logan
Location: Portland, OR, USA

Mail: patrickdlogan@gmail.com
Web: http://patricklogan.blogspot.com
I have been programming in Scheme as my primary Lisp dialect since the
mid-1980s with MacScheme. I've used T, DEC Scheme->C, MIT Scheme, SISC
(for the JVM), etc. Gambit has been my Lisp of choice since the very
earliest releases in the early 1990s. The time now is ideal for
dynamic and functional languages to increase in popularity. Scheme as
in R5RS plus more, better libraries will be the key to winning.


Name: Pavel Dudrenov
Location: San Francisco, CA, USA

Web: http://www.dudrenov.com
My live with Scheme started soon after I discovered, almost
incidentally, the "Structure and Interpretation of Computer Programs"
by Abelson and Sussman. The process of reading, and doing every single
exercise took me almost 2 years. Those 2 wonderful years changed my
way of thinking, an my worldview over all. Later I moved to Essentials
of Programming Languages, and other great literature. In the process
of all this I ended up playing with many different implementations of
Scheme. After a while I even started working on my own implementation,
as to be able to experiment with different features, implementation
methods, and most of all to gain better understanding of Scheme.

I am relatively happy with the states of affair of R5RS, but r6rs on
the other hand, even thou much easier to read, striked me as something
that was done based on the latest trends in programming languages as
in "we have this too". The library form for example, I think, is taken
straight from Erlang. I don't mean that in a bad way. But that, a lot
of the things, that r6rs introduces are better suited as libraries or
srfi's.

One of the first thing we learn in Scheme is that we don't need a
special construct to represent iteration, we can easily do this with
recursive function that describes an iterative process. It seems to me
that r6rs does the opposite.

Scheme attracted me because of it's minimalism, and beauty. I'd like
to be given the chance to vote for someone that I think will be able
to keep those concepts alive in Scheme.


Name: Per Bothner
Location: Cupertino, CA, USA

Mail: fper@bothner.com
Web: http://per.bothner.com/
I am the implementor of the Kawa Scheme dialect, which I have
been working on since 1996, when it was one of the first
compilers of a dynamic language to the Java Virtual Machine.
Kawa implements the functionality of R5RS (except for
continuations), with many extensions, and I'm hoping to
remain more-or-less compatible with future Scheme standards,
to the extent that resources and Kawa's goals permit.
I am interesting in combining the benefits of efficient
compilation (helped by a module system) with the traditional
"agility" of Scheme's eval and repl.


Name: Peter Bex
Location: Neer, Limburg, The Netherlands

Web: http://sjamaan.ath.cx
I've been using Scheme for over 4 years now and I think it's a
beautiful language. I intend to try to keep it that way and will try
to vote for editors that will do their best in the interest of the
community.  Hopefully this will cause a less controversial result that
can be accepted by the two camps into which the community split after
R6 got finalized, thereby re-uniting it.  I really hope that this can
be done by having the right people work on R7.


Name: Phil Bewig
Location: Saint Louis, MO, USA
I've been using Scheme for over a decade.  I am the author of SRFI-40
(now deprecated) and SRFI-41 on Streams (lazy lists).  I was a member of
the R6RS electorate, and voted NO.  I currently use Chez Scheme (an R5RS
Scheme) and will continue to use Scheme for my personal programming
projects, as I am attracted to its simplicity, elegance and power.  I
am interested in continuing the Scheme standardization process, and in
particular in correcting some of the errors I find in R6RS.


Name: Prof. Dr. Herbert Klaeren
Location: Tübingen, Germany

Affiliation: University of Tübingen, Germany
Mail: klaeren@acm.org
Web: http://www-pu.informatik.uni-tuebingen.de/users/klaeren
As an instructor in Informatics at a university I have immense
interest in the development of Scheme. We use it in our introductory
computer science courses with great success. Moreover, the research
area of my group is functional programming and efficient
implementation techniques. We participate actively in SRFI
discussions, have contributed to Scsh, the Scheme Underground Network
Package and some other projects. Also, we are doing research on module
systems for Scheme, a transition from Emacs Lisp to Scheme and some
Scheme 48 implementations.


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

Affiliation: Indiana University
I am involved with Scheme as an implementor, researcher, educator, and
user.  I am creator and principal developer of a commerical implementation
of Scheme, creator or contributor to several other Scheme-based software
systems, and author of a published introductory and reference text on
Scheme.  I have been involved in the revised-report process for over 20
years, including most recently as chair of the R6RS editors committee.  I
remain committed to participating in the process of improving Scheme
through future standardization efforts.


Name: Richard Kelsey
Location: Boston MA USA
I have been involved in the Scheme standardization process
for many years.  I stopped being involved, by resigning from
the R6RS editors, when it became clear that the goals for
R6RS were sufficiently different from those of earlier
reports that I had little to contribute to it.

The Scheme process has always meant many different things to
the various participants.  My concern now is that the Scheme
reports continue their tradition of clarity, precision, and
utility, regardless of the goals set for each individual report
and the way in which the language itself evolves.

Vita:
  - co-author of two Scheme implementations, T and Scheme48
  - attended the R4RS and R5RS meetings
  - edited R5RS
  - organized and chaired the post-R5RS meeting which resulted
    in the creation of the SRFI process
  - author or co-author of several SRFIs


Name: Robby Findler
Location: Evanston, IL
I am interested in the Scheme standardization process to the point
that I (along with my student Jacob Matthews) wrote the formal
semantics for the Revised Revised Revised Revised Revised Revised
Report on the Algorithmic Language Scheme.

I am also a contributor to a Scheme implementation, namely PLT Scheme,
where my primary responsibility is the program development
environment DrScheme. Changes to the standard have the potential to
affect my work maintaining the development environment. Fin.


Name: Robert Lizée
Location: Montréal, Québec, Canada

Affiliation: Gamerizon Studios Inc.
Mail: robert@gamerizon.com
I co-founded a company that is currently using Scheme for video game
development.  Our attraction to Scheme comes from its dynamic nature
(REPL), its expressiveness given by the lambda Calculus, its reliance on S-
expressions, and its simplicity making possible to extend in various
directions and making it practical as an embedded language.  Our interest
in the standardization process is for Scheme to keep its simplicity while
being rich enough in key features to facilitate the use the same code base
on more than one implementation.


Name: Ronald Garcia
Location: Houston, TX, USA

Affiliation: Rice 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 pursue 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. R6RS brings a new set of tools to the standard
Scheme language, and it is natural to expect some time to pass before
developers have acquired enough experience with R6RS to be able to help
steer the language as it progresses toward R7RS and beyond.
Standardization has the potential to advance Scheme and my work by
codifying 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: 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 biggest failure of Scheme in my view is the
divergent implementations.  My interest in the R6RS standardization
process, as well as in future standardization efforts, is to minimize
unnecessary diversity, broaden the base of shared functionality, and
enable greater portability.


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

Affiliation: Northeastern University
Mail: samth@ccs.neu.edu
Web: http://www.ccs.neu.edu/~samth/
I use scheme in a wide variety of contexts.

First, Scheme is my programming language of choice for virtually all
projects, from scripts to large programs.

Second, my research is focused on Scheme, in particular, on type
systems that accommodate Scheme idioms.  The Typed Scheme language is
the result of these efforts.

Third, I maintain libraries which are part of PLT Scheme, including
the match.ss pattern matching library.

Fourth, I teach undergraduate classes using several different dialects
of Scheme as part of the HtDP curriculum.


Name: Scott Bell
Location: Calgary, AB, Canada

Affiliation: Skysheet Corp.
I am a full-time Lisp programmer, currently working with Common Lisp,
previously with both CL and Scheme. I feel that the Scheme community
has experienced a very unfortunate rift after the ratification of
R6RS, and that the new Steering Committee will be faced with a
difficult challenge in attempting to repair this rift and grow the
community.

I have been using Scheme personally and professionally for 4 years and
would sincerely appreciate using it in the future. My ability to do so
depends on the future of the Scheme language and community, thus is my
interest in the election process.


Name: Scott N. Walck
Location: Annville, PA, USA

Affiliation: Lebanon Valley College
Web: http://mas.lvc.edu/~walck/
I use scheme in my research and in my teaching.  I've used guile and MIT
scheme most significantly, but also mzscheme and drscheme a bit.  I'm
particularly interested in the use of scheme as an education tool for
physics, as in Sussman and Wisdom's book on classical mechanics.  The
ability of the language to be viable and accessible to undergraduates in
the future is a concern for me, and consequently I believe I have a stake
in the standardizations process.


Name: Shiro Kawai
Location: Honolulu, HI, USA

Affiliation: Scheme Arts, LLC
Mail: shiro@acm.org
Web: http://practical-scheme.net/
I'm running a small business in software consulting, and
Scheme is my indispensable tool, not only because it is
so much pleasure to work in Scheme, but also it gives me
a competitive edge.   Lately I use Scheme in almost all
of my projects, some are running on my servers and others
have been shipped to clients.  Scheme's staying vibrant
and at the  front of modern software development are crucial
for my business to sustain.  Although I'm confident that Scheme
as the current form is flexible enough for me to keep it
fit to the coming needs in future, it is important for
me to see the future Scheme stays to be the most powerful
tool, not only to keep my business alive, but also
to let efforts of all Scheme developers survive and inspire
future developers.


Name: Stefan Monnier
Location: Montréal, QC, Canada

Affiliation: Université de Montréal
While my own research interest is mostly focused on statically typed
languages, the evolution of Scheme is something I care about as a member of
the functional programming community, because it is the prototypical
dynamically typed functional language and it still has a lot to provide to
the larger programming language community, for teaching purposes, for
compilation techniques, and for macro systems (whose relevance goes much
beyond Scheme, as can be seen with Template Haskell, as well as all the
work around mechanising metatheory where manipulation of bindings is key).
Of course, there's also the hope that at some point Emacs's Lisp can be
replaced|merged with Scheme.


Name: Stephane Le Cornec
Location: Saint-Lambert, Qc
I graduated from Sherbrooke U, where lisp was part of the curriculum. I then
spent 10 years developping applications in C++. I joined Metascoop in 2003
and keep on using a bastard child of Scheme to earn a living in the real
world. As one of the main developper of JazzScheme, I have a vested interest
in seeing Scheme evolve in a direction compatible with our needs. I believe
Scheme could not evolve in pure academia, and real-world usage needs to make
its mark on the future of Scheme.


Name: Stevie Strickland
Location: Boston, MA, USA
I am interested in participating in the Scheme standardization for a
variety of reasons.  I have used Scheme since my undergraduate days at
the Georgia Institute of Technology.  Now that I am a PhD student at
at Northeastern University, I also contribute to an existing
implementation of Scheme as a member of the PLT team.  In addition, I
have spent multiple semesters teaching Scheme to the undergraduate
students at Northeastern University via the How to Design Programs
curriculum.


Name: Sven Hartrumpf
Location: Duesseldorf, Germany
I have benn using Scheme for more than 12 years for 90% of
my coding. So, I have written around 200000 lines of
code for applications that need both: the elegance
and rapid-prototype-ability of Scheme and special
efficiency that can come close to C. I am concerned
with the direction from R5RS to R6RS and I hope that
R7RS will be more pragmatic again. Anyway, the next
standard step will be very important for functional
programming as a whole, so that I would like to get
involved.


Name: Thomas Lord
Location: Berkeley, CA USA

Affiliation: unafiliated
Mail: lord@emf.net
Web: http://basiscraft.com
I came to Scheme from Emacs lisp in approximately
1987.   Around the same period of time I became
fascinated by certain problems in the field of
human computer interfaces and the architecture of
extensible programs.   From that background I
came to, in the early 1990s, create the GNU Guile
project along with a less successful project to
create a framework for highly interactive, extensible
programs (using Scheme as an extension language).
Externalities drove me away from that project but
my interest remains high.

I chose Scheme for my projects, then, for a few
reasons.  I believe that what it has in common
with all lisp dialects is in and of itself valuable
in an interactively programmable system (especially
the concentration on a few, familiar, general purpose
data structures;  the use of manifest typing; etc.).
I believe that "lisp-1" dialects are a better idea
than other variants, finding no compelling argument
for counting past "1" in that context.  I believe
that lexical scoping, by default, is essential to
developing large modular programs robustly.  I believe
that closures and (esp. delimited) continuations
are superior abstractions to most of what so-called
"object oriented" languages provide through more
complex mechanisms.   Above all:  I was impressed
that Scheme (at that time) was a language that could
be implemented *easily* either by interpreter or
compiler well enough to produce something useful,
with then a high rate of return in utility for incremental
improvements to the simple-minded implementation.

I am disappointed by dominance displayed on the
evolution of Scheme by a few academically
successful projects.   For example, hygenic macro
systems are a fine, fine invention and yet they
have so dominated the public side of work advancing
the definition of Scheme that I have to now question:

Has Scheme, once an embodiment of the essential
ideas about simplicity found in the original "Lambda: The
Ultimate..." papers (and related materials), now
lately become, primarily, simply a framework for defining
thesis topics around macrology?    I note that with
R6, Scheme is no longer a language which a simple interpreter
can provide well enough to be useful in a "simply works" sense
of "useful".

Of course R6 is more than that.  It's also a framework
for demonstrating a particularly academic (unproved)
theory about the Unicode Consortium's sovereignty over the most
desirable semantics for characters and strings.  And the
standards process has become a place to wrestle over
the latest theories about the best means by which to
express a formal semantics (whereas I regard the original
denotational semantics as simply a hat tip to the ancestors
and contemporaries of the original Scheme - a way of saying
"Hey, look, the simplicity and elegant power of this
thing resonates when projected against the work of
Strachey and Scott and this in itself suggests an
advance is possible over the Algol report.")

In short, though it was nobody's intent, the R6
process seems to have emerged as farce: it produced
a standard and a language which is mainly "about"
the politically and financially awkward process
that created it.  It appears, especially with the
passage of time, to have no other relevance.

I'd like to remain in the conversation through the
formal venue of the formation of a new steering
committee.     I would like to see a substantial
re-chartering of the committee, or its dissolution.
I'd like to see some debate and proposal making
around the general topic of "What is Scheme, and
a Scheme standard *for*, anyway?"

And what is a steering committee for?

If this new steering committee is to be blessed and
granted legitimacy by this public process, what will
it do to serve its constituency?  What will it do
so that someone who votes this new group in can say
to a potential patron or employer "I have this Scheme
project I'd like to work on...." and, in saying so,
then point in the new committee's direction for
better evidence than R6 that there isn't something
fundamentally flawed and irrelevant about Scheme in
general?   Will the new committee simply "operate"
an R7 process, likely to be as farcical as R6?
Or will it step up to become a source of merit-based
leadership and community organizing?

-t


Name: Tom Gordon
Location: Berlin, Germany

Affiliation: Fraunhofer Gesellschaft
I am a senior research scientist at the Fraunhofer Gesellschaft in Germany.
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.
Scheme has been my preferred language for building research prototypes,
starting with my work on OBLOG in 1986-87. Most recently I have used Scheme
to develop a set of Open Source R6RS Scheme libraries, for rule-based
systems, case-based reasoning and argumentation support tools, called
Carneades <http://carneades.berlios.de>.  As part of this effort my
colleagues and I have helped to port a number of Scheme libraries to the
R6RS standard.


Name: Vincent St-Amour
Location: Montreal, Qc, Canada

Affiliation: Universite de Montreal
Mail: stamourv@iro.umontreal.ca
Web: http://www-etud.iro.umontreal.ca/~stamourv/index-en.html
I have been a Scheme user for a couple of years now, and it always
impressed me both by its simplicity, and by the elegance of its
design.

I have been working with Scheme in embedded systems, and I could not
have done half of what I did with another language. Its amazing
simplicity meant that, even in severely limited environments, it's
still possible to have all the high-level features we know and
love. I plan to keep working with Scheme, so it's in my best interest
that the best candidates steer Scheme towards a bright future.


Name: Vitaly Magerya
Location: Novomoskovsk, Dnipropetrovsk region, Ukraine

Mail: vmagerya@gmail.com
My encounter with Scheme happened about 5 years ago when I got a copy of R5RS.
I was quite fascinated by how powerful and yet simple a language can be.
Needless to say, Scheme is now the language of choice for all of my own
projects.

I've been following R6RS development, and leaving aside technical issues
with the report, from what I've seen there where problems with the process
itself that the new Steering Committee must address. Namely, neither the goals
nor the scope of the new standard where explicitly discussed, or widely agreed
upon. And we've all seen both the good and the bad consequences of that.

Frankly, I'd like to see a cleaner report. I'd also like it to gain wide
support from implementors, and users (otherwise it's useless). And do I dare
to dream about seeing innovation, not just standardization, at least in the
design field?

My hope for these elections is simple: I want the new Steering Committee to
help Scheme community fixing that is broken.


Name: Will Meierjurgen Farr
Location: Cambridge, MA

Affiliation: MIT
Mail: farr@mit.edu
Web: http://web.mit.edu/farr/www/
My interest in the Scheme standardization process is that of a
professional user of Scheme.  I am an astrophysicist and use Scheme
for my research and teaching.  I appreciate the power and flexibility
of Scheme; my work places extreme, conflicting demands---for clarity,
for algorithmic power, for performance---on the programming languages
I use.  Scheme meets my demands for a programming language in many
cases, primarily due to its elegant and flexible design.  I think I
represent an unusual corner of the Scheme community, and I think my
vote for members of the steering committee with the interests of this
corner in mind will help improve the power and flexibility of Scheme.


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

Affiliation: Northeastern University
Web: http://www.ccs.neu.edu/home/will/
I have been using, implementing, and writing about
Scheme since 1982.  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 Larceny, Petit
Larceny, and Common Larceny, which are among the
world's foremost implementations of Scheme as defined
by the IEEE, ANSI, R5RS, ERR5RS and R6RS standards.


Name: Wolfgang Hukriede
Location: Kiel, Germany

Mail: whukriede@game-alumni.org
I think we should strive for a very high degree of consent, certainly
more than the last time round. A believe in a small kernel and
portability, so we should be able to swap implementations for speed.
Interactive use and separate compilation should not be ruled out.
I've written my first lispy interpreters and used them extensively in
the days of the Atari. Scheme I've been using since about ten years,
not only for recreation and exploration, but also to some degree
successfully for commercial purposes.


Name: Yannick Gingras
Location: Montreal, Qc, Canada

Mail: ygingras@ygingras.net
Web: http://ygingras.net
I am a software developer currently working on payment processing
solutions.  During my career, I had the opportunity to develop complex
software solutions with various programming languages, from the very
static C++ to the all dynamic Python.  I also used Common Lisp to
implement bioformatics softwares ranging from processing intensive
classifiers to high level web interfaces.

I currently use Python most of the time, mainly because of the very
good support for practical deployment that it offers.  However, this
language is slow and lacks many static checks that prevents one from
finding simple bugs until execution time.  I would prefer to use a
Lisp dialect but I can't currently find one that offers both fast
compilers and practical packaging and deployment systems.  I am
interested in the Scheme standards process because I have faith that
Scheme can become the language that I am looking for.