Date: 2010-01-20
Working group 1 will develop specifications, documents, and proofs of practical implementability for a language that embodies the essential character of Scheme and that can be extended and integrated with other systems.
The purpose of this work is to facilitate sharing of Scheme code. One goal is to be able to reuse code written in one conforming implementation in another conforming implementation with as little change as possible. Another goal is for users of this work to be able to understand each other's code based on a shared and unambiguous interpretation of its meaning.
The language is intended for use in education, programming-language research, embedded systems, and embedded scripting languages. It will also be a platform on which other languages can be built. For these uses, a language that is "lightweight" at the semantic and/or implementation level is appropriate.
The language should be easy for a human to learn and understand. It should be easy to make an unsophisticated implementation for research, development, and study, and it should be possible to make a sophisticated implementation that is suitable for serious computation. A sophisticated implementation should be an appropriate kernel for a larger Scheme system.
The language should be mostly compatible, and comparable in size, with R5RS. This will allow reuse of the large base of existing This will allow reuse of the large base of existing teaching materials (textbooks, tutorials, web documents, etc) and code using that dialect. The language should follow the design precepts found in the R5RS introduction:
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
To promote extensibility, the language developed by working group 1 must include support for macros and modules in a way that is appropriate for the language's size and goals. Semantics compatible with interactive read/eval/print loops should be provided.
When deciding which features to include in the language, working group 1 should consider all features provided by R5RS Scheme, and all criticisms of those features. Existing features of IEEE Scheme may be removed only if a strong case can be made that they are fundamentally flawed. Insofar as practical, the language should be backwards compatible with the IEEE standard, the R5RS standard, and an appropriate subset of the R6RS standard.
Self consistency is an important objective, which may require adding new features.
Working group 1 must develop written specifications for the language. These specifications must be accompanied by concise statements of all formal comments and objections that have been raised by members of the working group or by the Scheme community at large. The working group should also provide a written design rationale, executable reference implementations, test suites, and other artifacts that would assist with constructive debate or increase acceptance of the language.
Working group 1 is expected to produce a public status report after 6 months; a public draft after 12 months, to be updated every 3 months thereafter until endorsement a draft suitable for final endorsement after 18 months. If the working group anticipates any difficulty meeting these milestones, its chair should inform the Steering Committee in advance of the milestone.
Working groups 1 and 2 must work together to produce specifications that are consistent with one another. In particular, every implementation of the specifications produced by working group 2 must be an implementation of the specifications produced by working group 1. Every program that conforms to the specifications produced by working group 1 (and relies on no features beyond those guaranteed by those specifications) must also be a program that conforms to the specifications produced by working group 2.
Working group 1 must provide a substrate on which working group 2 can build that enables this level of compatibility.
So far as is practical, this relationship between the smaller and larger languages should be achieved by having the documents that describe the larger language refer to the documents that describe the smaller language instead of duplicating those documents or portions of them. That in turn will require coordination between working groups 1 and 2.
The Steering Committee will solicit applications for membership in the working group, and will appoint members from among the applicants, as well as whatever additional members they see fit. If members cease to be members for any reason, the Steering Committee may appoint replacements in the same way.
Members of the working group should endorse the goals of the working group and be willing and able to work toward consensus. Working groups 1 and 2 should have some members in common.
All technical discussions must be made public. This requirement can be satisfied by timely posting of email and the technical minutes of meetings at a public web site, and by maintaining a publicly readable mailing list devoted to working group 1's technical discussions.
The chair of the working group is expected to develop an internal process that allows the working group to achieve its objectives.
The working group is expected to strive for consensus on all decisions. Where consensus cannot be achieved, the working group may proceed on the basis of a vote, but the results of such votes must be preserved within the public record, along with the reasons for dissent. Minority positions may be registered as formal objections (see above).
The work products developed by working group 1 will be submitted to the Steering Committee for endorsement. The Steering Committee will work with working group 1 to seek maximum possible timely consensus on the work products. In considering whether to endorse the work products, the Steering Committee will consider whether the work products meet the charter requirements, as well as the level of support that they enjoy.
If formal objections remain at this time, the Steering Committee may choose to put the question of whether some or all work products satisfy charter requirements to a representative electorate. If the Steering Committee puts the question to an electorate, and concludes that less than 85% of the electorate consider the work products to meet the charter requirements, then the work products will not be endorsed.
If the Steering Committee believes that support could be increased by revising work products in response to specific objections, then it may request another draft/review cycle of the working group.
The Steering Committee selects, and may replace, the working group's chair.
The working group may elect or appoint other officers as it sees fit.
The names of the languages to be developed by working groups 1 and 2 have not yet been determined. The Steering Committee will consider names suggested by the working groups.