For review purposes only. Send feedback to steering-committee-feedback (at) scheme-reports.org
The purpose of working group 1 is to develop specifications, documents, and proofs of implementability for a "small" language in the Scheme family. This small language will encapsulate the fundamental features of Scheme. Its target uses include education, programming language research, small embedded systems, and embedded scripting languages, where it is appropriate to use a lightweight language at the semantic level and/or in the implementation.
For educational uses, this language should be compatible and comparable in size with R5RS. This will allow reuse of the large base of existing teaching materials (textbooks, tutorials, web documents, etc). In a nutshell this language should remain true to the language design precepts found in the RnRS introduction ("Programming languages should be designed not by piling feature on top of feature, …").
The language developed by working group 1 must include support for macros and modules/libraries in a way that is appropriate for the language's small size. The language's semantics must also be compatible with traditional read/eval/print loops. Features of the language should be marked as optional if their implementation is likely to be burdensome for some target uses (for example, floating point arithmetic, file I/O, "load", "eval", and read/eval/print loops may not make sense for small or embedded systems).
When deciding which features to include in the small language, working group 1 should consider all features provided by R5RS Scheme, and all criticisms of those features. Self consistency is an important objective, which may require adding new 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 small language should be backwards compatible with the IEEE, R5RS, and R6RS standards.
The programming languages developed by working groups 1 and 2 must be consistent, and the programming language developed by working group 1 should be a proper subset of the language developed by working group 2.
So far as is practical, this relationship between the small and large languages should be achieved by having the documents that describe the large language refer to the documents that describe the small language instead of duplicating those documents or portions of them. That in turn will require coordination between working groups 1 and 2.
Requirements for membership, and the decision process for membership, should be described here.
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 the scheme-reports.org site, and by maintaining a public mailing list devoted to discussion of the small language being designed by working group 1.
Responsibilities of the publicity officer should be listed here.
Working group 1 must develop written specifications for the small language. These specifications must be accompanied by all formal comments and objections that have been raised by members of the working group or by the Scheme community at large. The specifications should also be accompanied by a written rationale, executable reference implementations, and other artifacts that would assist with constructive debate or increase acceptance of the small language.
Working group 1 is expected to produce
If the working group anticipates any difficulty meeting these milestones, its chair should inform the Steering Committee in advance of the milestone.
The chair of the working group is required to develop an internal process that allows the working group to achieve its objectives.
The working group is strongly encouraged to seek consensus on all decisions. Where consensus cannot be achieved, the working group may proceed on the basis of a majority or supermajority vote, but the results of such votes should be preserved within the public record, along with the reasons for dissent.
The specifications of the small language developed by working group 1 will be submitted to the Scheme community for approval. The Scheme Language Steering Committee will work with working group 1 to seek maximum possible timely consensus for its specifications.
If the Steering Committee concludes that specifications of the small language are not supported by at least 90% of a representative electorate, then those specifications will not be approved. If the Steering Committee concludes that the specifications of the small language are supported by at least 90% of a representative electorate, but believes that support could be increased by revising the specifications in response to specific objections, then approval of the specifications may be deferred until the Steering Committee can determine whether revised specifications would achieve a greater degree of support.
The following officers of working group 1 must be approved by the Steering Committee:
The Steering Committee may select the chair, and may replace any of the above officers.
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.