Steering Committee Nominees

The following people have accepted a nomination to serve on the next Scheme Language Steering Committee. Nominations are now closed.



Name: Jonathan A Rees
Location: Arlington, MA

Affiliation: Science Commons
Web: http://mumble.net/~jar/
I think the 'steering' experience I have could be of some use here.
In addition to my work on Scheme reports (in particular as editor of
R3RS), I've been involved in other efforts to get groups to agree,
most recently in bioinformatics and web standards. Good
process is a big help in standards efforts, and putting some thought
into process design can pay off.

The hardest thing is figuring out what we want to accomplish.
Without agreed goals it's hard to get anywhere. Scheme has become
narrow and serious. We need to figure out how to balance
the essential fun and idealism of the adventure with the unglamorous
goals of performance and portability. I wonder if this might be
helped by process innovations.


Name: Marc Feeley
Location: Montréal, Canada

Affiliation: Université de Montréal
Mail: feeley@iro.umontreal.ca
Web: http://www.iro.umontreal.ca/~feeley/
When Steele and Sussman invented Scheme they could not foresee that it
would become a prominent language with adamant followers, and several
implementations and applications.  Scheme can flourish even more if
the community unites to offer the world a superior environment for
software development (compatible tools, libraries, fellow programmers,
etc.)

With many people I share the opinion that the R6RS is failing to reach
that objective and has not significantly improved the sharing of code.
Community polarization and fragmentation has increased.  I believe
that in the recent frenzy to evolve Scheme into a practical language
we have lost sight of the ideals that make it great.  Scheme is known
for being an exceptionally simple, small, dynamic and powerful
language.  This is no longer true with R6RS.

My vision is a language spec whose size and elegance is similar to the
R4RS/R5RS and which conveys the core features of Scheme.  The need for
features that simplify practical programming is best addressed by
libraries outside the language spec which evolve at their own pace.
Instead of having libraries imposed by the spec, a set of competing
libraries will survive based on their inherent merits.  The SRFI
process or something similar should suffice.

The steering committee must play an active role in the elaboration of
the new spec by giving direction to the design process and ensuring it
lives up to the Scheme ideals.  If I am elected you can count on me to
represent this vision of Scheme on the steering committee.


Name: Anton van Straaten
Location: New York metro area, United States

Affiliation: AppSolutions LLC
Mail: anton@appsolutions.com
Web: http://scheming.org/anton/
The decision-making process between R5RS and R6RS underwent a radical 
change: from unanimous consent of a larger self-selected group, to a 
majority vote of five appointed editors.  This was a reaction to the 
R5RS process having reached its limits, and an attempt to remove 
barriers to the development of a new Report.

Although the new process had its justifications, it also introduced some
significant drawbacks.  Now that the R6RS has relieved the pressure that
apparently existed to produce a new Report, the new Steering Committee 
should step back, re-evaluate the situation, and develop a middle way 
between the two previous process extremes.  This should be done in close 
collaboration with implementors and the community.

Some possibilities worth considering include:

* Develop more specific goals and requirements.  Develop a 
"constitution" to help protect the integrity of the language.  Process 
improvements are only part of the equation.

* Involve Scheme implementors and the community more closely in the 
process. In some manageable form, extend issue voting power beyond the 
Editors' Committee, particularly to other implementors.

* Improve the issue voting process, e.g. via preferential voting instead 
of simple majority vote.

* Encourage greater use of expert volunteers, e.g. via specialized
subcommittees or non-voting authors.

My experience on the Editors' Committee, and as a user of various Scheme
implementations, has helped me to better understand the requirements and
challenges facing Scheme standardization, and the shortcomings of the 
current process.  If elected, I will work towards a new beginning for 
standard Scheme.


Name: Christopher P. 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.

As a member of the steering committee, my focus would be on engaging
the community in the process, and making sure that the resulting
standards have significant buy-in from implementers.  I believe that
this is best achieved by policies that encourage broad community
influence of the standards, and that the steering committee is
responsible for defining these policies.  While the editors are
responsible for the content of the standards, they must be accountable
to the community and their decisions must be reasonably transparent.
It is up to the steering committee to ensure that accountability and
transparency are preserved.


Name: Dr Richard Anthony O'Keefe
Location: city=Dunedin, region=Otago, country=New Zealand

Affiliation: Department of Computer Science, The University of Otago.
Mail: ok@cs.otago.ac.nz
Web: http://www.cs.otago.ac.nz/department/staff/richard.html
Web: http://www.cs.otago.ac.nz/staffpriv/ok/index.html
Steering isn't driving: the language belongs to the Scheme
community, not the Committee, and the needs of that diverse
community are the driving force.  Scheme should keep a
simple and powerful core.  R6RS makes it possible to serve
practical ends by providing modules that don't compromise
that core.  Some changes (notably concurrency) must affect
the core.  You'll want someone on the Committee with a wide
knowledge of programming languages and a love and respect
for Scheme.  That's me.


Name: Ray Samuel Dillinger (but better known as "Bear")
Location: United States, San Francisco Bay Area, San Mateo CA, 94402

Mail: bear@sonic.net
In addition to having implemented a scheme and couple of different
experimental lisp dialects on my own time, I served as the coordinator
for the most recent update of IEEE 1178-1990, the IEEE standard for 
scheme.  I'm fluent in twelve different programming languages, and 
can get by with frequent recourse to manuals in probably another
twelve.  I've made a point of learning languages that use very 
different paradigms in order to clarify my understanding of the 
benefits and problems of different semantics, syntaxes, and
capabilities.  

Most of my professional career has been as a language scientist 
of either formal or natural languages.  While working for NativeMinds, 
I got two patents in natural-language work; one for a method of
identifying the referents of pronouns in English text, and one for 
a method of autogenerating content for natural-language-using 
software agents.  At my last job, I worked with internationalization
problems and requirements extensively, and got so familiar with
the Unicode spec that I can quote large parts of it, although 
that does not make me happy. 

I'm a longtime participant in the comp.lang.scheme usenet group 
and the SRFI process.  The significant software I've written 
for various employers and on my own time includes compilers, 
parsers, taggers, natural language analysis tools, and corpus
linguistics tools.


Name: William D Clinger
Location: USA, New England, Boston, etc

Affiliation: Northeastern University
Mail: will+scheme@ccs.neu.edu
Web: http://www.ccs.neu.edu/home/will/
The R6RS has given us the option of writing programs
in the new and more static language it describes.  Two
implementations of the dynamic language most recently
described by the R5RS have added support for this new
mode of execution, and four brand new implementations
of R6 Scheme are well under way.

That represents a partial success, but this process
has disappointed users of the language formerly
known as Scheme.  Many had hoped that this process
would give them standard facilities for defining
libraries and records while offering at least some
common direction on matters such as Unicode, IEEE
floating-point arithmetic, and exception handling.
Instead, the R6RS made those facilities available
only to programmers who adopt the new language.

That was unnecessary.  As demonstrated by ERR5RS, the
major new features of the R6RS could have been added
without forbidding read/eval/print loops and dynamic
loading of libraries.  The Scheme Language Steering
Committee should ensure that this process addresses
the needs of programmers who use the dynamic language
paradigm of IEEE/R5 Scheme.

The committee should also direct the new editors to
address known technical problems of the R6RS.  The
ideal outcome would be a set of R7RS documents that
supersede both the R5RS and the R6RS by describing
a single language, which we might call Scheme, that
supports both dynamic and static modes of execution.
At worst, two distinct language standards could share
common specifications of basic syntax, semantics,
operations, and (some) standard libraries.


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

Affiliation: None relevant.
Mail: cowan@ccil.org
Web: http://www.ccil.org/~cowan
I will begin by thanking my anonymous nominator; the nomination came
entirely out of the blue, and I had to think quite hard before deciding
to accept.

If elected, I would be a Scheme "outside director":  I am deeply
interested in Scheme, but I am neither a heavy user nor an implementer.
I did implement a Lisp once, and am working on implementing another,
and I've done a certain amount of Scheme programming over the years,
so I'm broadly familiar with the concerns of both implementers and users.

It is important to me that Scheme continue to be updated so as to remain
relevant to many kinds of users.  I voted for R6RS not because it was
perfect, but because I thought it was the best compromise that could be
achieved given the process in place.  It dealt, not always perfectly,
with issues that had arisen over the time since the last major revision
of Scheme, RRRS.  I certainly do not want to see R6RS discarded; I also
am not committed to maintaining complete compatibility with it in future
versions of Scheme.

In order to steer a sailboat, it is not enough to keep the bow pointed
in the direction you want to go; depending on the wind, that may be the
worst possible maneuver.  Instead, it is often necessary to tack, moving
this way and then that way in order to reach the goal, particularly when
we don't yet know for sure exactly what the goal is!


Name: Olin Shivers
The primary challenge before the Scheme community, and the
Steering Committee that is to represent it, is the fact that our
community is comprised of multiple constituencies: hackers,
researchers, software engineers, implementors, designers, and
poets. Each group brings a valuable perspective to the question,
"What should Scheme be?" As a result, the language exists in a
tension, pulled in different directions by these various groups.
Thus, the challenge: the community must resolve these tensions in
a constructive way, or it risks having Scheme fragment and
dwindle into irrelevance.

The job of the Steering Committee, as I see it, is to listen to
and represent the community. There's a tension here, as well:
language design and specification is a task for specialists; 
on the other hand, if the design doesn't respect and build
community consensus, it will end up serving as little more than
a museum display -- a sort of Algol 68 with parens. This is where
the Steering Committee comes into play: defining and managing the
process by which Scheme proceeds forward.

I have been involved with Scheme since about 1981. I've spent
time in all of the different constituencies I named above, and
think I understand each of them. I'm still working with Scheme on
a daily basis, as a designer, implementor, educator, researcher
and programmer. Finally, I've been around long enough to believe
I have a fairly good grasp of who many of the principal actors in
the Scheme community are, and what each has to offer to any future
process. 

That's more or less who I am, and what I think the key issues are.
    -Olin


Name: Aubrey Jaffer
Location: Bedford (Boston) Massachusetts USA

Affiliation: Clear Methods Inc.
Mail: agj@alum.mit.edu
Web: http://people.csail.mit.edu/jaffer
The R6RS charter stated only two goals for R6RS: a module system and a
set of libraries.  Seeing the debacle this dearth of direction
produced, I believe the steering committee should do more steering.

I am not smart enough to design a major language feature correctly
without implementing and using it.  Implementing and testing proposed
features would have avoided many of the failings of R6RS.  I want to
direct the R7RS editors to consider only features which have been
implemented and tested through use.

As processor hardware is becoming increasingly parallel, the next
Scheme should support both SIMD and MIMD parallelism pervasively, SIMD
through parallel execution over multidimensional arrays, and MIMD by
changing the descriptions of Scheme constructs with "unspecified
evaluation order" to descriptions allowing concurrent evaluation.
(purely functional programs are already safe for such parallel
evaluation).


Name: Kent Dybvig
Location: Bloomington, Indiana, USA

Affiliation: Indiana University and Cadence Research Systems
Web: http://www.cs.indiana.edu/~dyb
I have been involved in research on Scheme language design and
implementation since 1980, created several implementations of Scheme
(most notably Chez Scheme), contributed open-source code used in other
implementations, written several editions of an introductory and
reference text for Scheme, participated in the revised-report process
since 1984, taught introductory computer science as well as other
courses using Scheme, and consulted for commercial Scheme users.  This
background helps me see Scheme from several perspectives, and it helps
me understand Scheme's history, present state, and community.  My stint
as chair of the R6RS editors committee gives me a unique perspective on
the roles of and challenges facing the R7RS editors.  I will have my
own opinions on what R7RS should look like and will voice those
opinions as appropriate, but I will not use a position on the steering
committee as a mechanism to push those opinions.  While I'm not eager
to take on another major responsibility, I am willing to serve and will
put in the time and effort required if elected.


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

Affiliation: none
Web: http://www.deinprogramm.de/sperber/
My involvement with the Scheme community is on public record, most
prominently my work as R6RS project editor.  I want Scheme to continue
to be a viable language for research, development, and teaching.
Presently, Scheme is at a crucial juncture with regard to these goals,
and I believe continuity in the standardization effort is a prerequisite
to reaching them.  Standardization is a human endeavor, and thus
involves mistakes and conflict: I have made many mistakes and was
involved in many conflicts during R6RS, and have tried to learn from
them.  While we would all like perfection and purity in every report,
our community is best served by following a path of gradual refinement
based on our experience and the best of our abilities, with intermediate
results that are improved if imperfect.  R6RS is a step in that
direction, but there is room for improvement: Particular problems were
the secrecy of the first two years and resulting exclusion of the
community, and the lack of published and agreed-on goals until late in
the process.  If elected to the Steering Committee, I intend to apply
what I have learned to support the next editors' committee in their
effort, and help them avoid our mistakes.  Additionally, I would like to
help establish a process for gathering experience of users and
implementors with the R6RS standard itself, identifying work to be done,
mistakes made, and areas that need to be improved.