The following people have accepted a nomination to serve on the next Scheme Language Steering Committee. Nominations are now closed.
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.
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.
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.
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.
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.
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.
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.
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!
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
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).
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.
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.