This page explains how some of the provisions of the WG2 charter are being applied in practice, as well as some other process-related matters.

Membership

All Schemers are welcome to participate in creating the R7RS Large language; anyone who does so is implicitly a member of WG2.

Members may optionally add their own names to the wiki home page. This may become a requirement to be considered a member of the WG in future, if it becomes advantageous to have a clearer WG2 membership list.

We have a Code of Conduct which details how and why the chair might decide to exclude someone from WG2 as allowed by the charter. (The ‘good reason’ required by the charter is defined as a CoC violation, and the SC must advise on and agree to the exclusion before it happens).

We are obliged to try to seek consensus on issues and turn to a vote only if we cannot reach such consensus. Consensus is reached in the issue tracker. If consensus cannot be found, and a vote results in no majority for change, the status quo remains.

Votes are addressed to the larger Scheme community beyond the (usually smaller) group which works in the issue tracker. The chair reserves the right to reject the result of a vote if less than around 50% of respondents who are actual maintainers of Scheme implementations support a particular idea. The chair also sees it as her responsibility to reject merely ‘WG2 internal’ consensus on features which she considers to require input from maintainers of implementations, pending input from implementers (possibly in the form of a vote).

Delivery

The charter foresees continuous delivery and ratification of the report in multiple parts.

The R7RS Large report will be delivered in three volumes: Foundations, Batteries (Standard Libraries), and Environments. This is detailed elsewhere on the wiki.

Foundations are being delivered in a series of fascicles, but these are drafts only and will not be submitted for ratification. The final Foundations volume will be a single text submitted for ratification either on its own account, or together with the other two, depending how the schedule appears to work out.

Batteries and Environments will likely be delivered as a single volume when they are done and ratified individually or together, again depending on how the schedule works out.

The N=3 rule

The WG has imposed this informal rule on itself upon the strong recommendation of the Steering Committee.

For an idea to be accepted into the Foundations, an implementation of that idea must be shipped with the core distributions of at least three implementations of the Scheme language. The three versions do not need to have identical APIs, but ideally it is possible to implement the APIs in terms of one another. If there is no agreement on an API for an idea, we can try and find a compromise; ideally we ship a well-established API, but we can try to fix identified problems with them if needed.

In certain individual cases, it may make sense to take a slightly more expansive or informal view of what the ‘core distribution’ of a Scheme implementation includes. Chicken Scheme historically had a very minimal core distribution which necessitated separate modules for basic common features like e.g. bignum and Unicode support, but in practice nearly everyone installed those modules. (This has changed a bit with Chicken version 6.)

The purpose of this requirement is not (primarily) to ensure that implementations can or will support the idea. The main purpose is so that we have evidence that an idea has been proven to work in real production code, to avoid standardizing something that turns out to be a bad idea.

In order to count, the Scheme implementations must have some kind of significant community around them. An experimental implementation with no real users does not support the primary purpose of the N=3 requirement.

The implementations must be independent of one another. If one Scheme implementation A uses parts of the runtime of another Scheme implementation B, then only features of A which are not simple wrappers of the implementation in B count. (This may affect e.g. Racket, which runs on Chez; and Gerbil, which runs on Gambit.)

The following accepted features are known not to meet N=3 and may yet be removed:

• Identifier properties (N=1: Chez only)
• Ephemerons (N=2 for fully correct support: Chez and MIT/GNU Scheme; Guile support is coming soon; not entirely faithful support in Gambit, Gerbil, and Chibi)

The following features are very likely to be provisionally accepted although they do not yet meet N=3, but are close:

• Guardians (N=2: Chez, Guile; other finalization mechanisms are supported by implementations including Gambit)

An idea whose value of N is 0 is, in general, ineligible for consideration in the Foundations in any form.

The Batteries do not have an N=3 requirement, but it is still desirable to have strong evidence that an idea is well-supported and used in Scheme or in some other language closely related (Common Lisp, Emacs Lisp, Clojure; maybe Haskell or ML). The reason is that it is a lot less problematic for a future RnRS to remove a portable library than to remove a core language feature (although we want to avoid situations where a future RnRS will have to do this nonetheless)

• Home

• FAQ about R7RS Large

• WG2

  • Members
  • Meetings

• Needed SRFIs