Scheme Request For Implementation — Process

by Dave Mason, with edits by various editors

Abstract

The goal of this mechanism is to provide a permanent registry for Scheme Requests For Implementation (SRFIs — pronounced "surfie"). This is not a formal standards-creation mechanism. Rather, it is a formal way to manage the production of proposals for Scheme.

There are many other things that this process is not. Discussion of those, rationales for some of the implementation details, and answers to related questions are to be found in the SRFI FAQ page.

Related to this process is a Scheme special form, documented in SRFI 7, that a Scheme program can use to ascertain whether an implementation supports a particular standard or feature.

Mechanism

The site https://srfi.schemers.org/ will provide an archive of draft, final and withdrawn SRFIs and a submission process to submit SRFIs for consideration.

The editors of the SRFIs will be experienced members of the Scheme community independent of the major implementors. They will attempt to keep the quality of SRFIs high, but will ultimately accept any SRFI which conforms to the structure requirements below.

A moderated mailing list, srfi-announce at srfi dot schemers dot org, will be used to announce when new SRFI proposals become drafts. It will carry a final notification when the SRFI has been either final or withdrawn. Anyone can subscribe to the list, and implementors are especially encouraged to subscribe.

There will be a mailing list created for the evaluation period of each SRFI where all discussion of the proposal will take place. Anyone may join these lists. The discussion will be archived and the archived discussion will remain part of the permanent record of the SRFI.

Process

All proposals must follow the following steps:

1. Authors submit a proposal by sending email to srfi minus editors at srfi dot schemers dot org.
2. Within seven days, one of the editors will read and respond to the proposal. The response may be a request to clarify, justify, or withdraw the proposal. Such a request must not reflect the personal bias of an editor. Rather, it will be made strictly to maintain a high quality of submissions. The editors may not turn a proposal back more than twice. On the third submission, the editors will move the proposal to draft status if it conforms to the specification below. At the discretion of the editors, a proposal that does not completely conform may be moved to draft status. Every proposal must conform before it is moved to final status.
3. When the proposal has been vetted by the editors, it receives its SRFI number and becomes draft. The editors will create a mailing list for the discussion of the proposal. A short notice of the new draft SRFI, including the title and abstract, SRFI number, URL, and instructions to access the SRFI's mailing list, will be sent to srfi minus announce at srfi dot schemers dot org. As part of the initial editing process, the editors will ensure that related standards (RⁿRS, SRFIs, RFCs and others) are appropriately identified and that the proposal meets the structural requirements described below. If other related standards are identified during the comment process or after acceptance, the editors will keep the references up-to-date. A proposal cannot normally be finalized until 60 days have passed since its initial submission.

4. If the authors choose, they may submit revised versions of the proposal at any point during the comment period. Every such revision shall be announced to the SRFI's mailing list, and all revisions will be retained in the permanent record of the SRFI.

   The SRFI process used to set a hard limit of ninety days on the discussion period. This was done because "Active discussion or revision after 90 days normally suggests that a proposal has been revised at least three times and is not yet mature enough for standardization." The current editor has removed this limit, but strongly encourages authors to submit SRFIs that they believe will only take ninety days, and reserves the right to withdraw SRFIs if authors become unresponsive.

5. At any time during the comment period, the authors can choose to withdraw the proposal. If the editors determine that insufficient time for discussion has followed a significant revision of the proposal, the proposal will be withdrawn. Otherwise, the proposal will be made final if it meets the requirements below. The outcome will be announced to srfi minus announce at srfi dot schemers dot org.
6. If the SRFI is withdrawn at the end of the comment period, it will be moved to a withdrawn proposal archive. Subsequent related proposals by the same or different authors may include/modify the text of the withdrawn proposal, and may include references to it.
7. When the authors are ready to submit an SRFI for finalization, they may, at their discretion, ask the editors to announce a "last call" period. This is a period, typically a week, in which reviewers on the mailing list are encouraged to submit their final comments. The hope is that all substantial issues have already been resolved, and that the last call period will just encourage people on the mailing list to do one final check. If authors are confident that discussion of the SRFI is already finished, they may request finalization without a last call period.
8. When the SRFI is accepted, it will be placed on the list of final SRFIs. This will include a link to the history of the proposal, including all earlier versions and the archive of the discussion from the comment period. Any identified SRFIs that are superseded by or incompatible with the newly final SRFI will be updated to reflect this fact.
9. A final SRFI may later be withdrawn, but only if it has been replaced with a newer SRFI and the author of the original SRFI agrees. In that case, there will be a "See also" link from the withdrawn SRFI to the new one. Note that withdrawn SRFIs are still present on the web site, in full — just marked withdrawn.

×

Once the SRFI number has been assigned, the proposal will be in one of three states: draft, final, or withdrawn. Lists of proposals in all three states will be available and archived indefinitely, and SRFI numbers will not be reused. The only changes that may be made to a final SRFI are:

1. updating of URLs (including those of related SRFIs)
2. noting that the SRFI has been deprecated or has been superseded by a subsequent SRFI
3. withdrawing the SRFI, but only with permission of the author, and only if a replacement SRFI has been finalized
4. improving the sample implementation and tests
5. correcting errors (but not errors of design), e.g. spelling errors, typos, or contradictory statements
6. adding "post-finalization notes," which document later recommendations by the authors and are placed in the Status section

Every Scheme implementation is encouraged to provide implementations of final SRFIs where possible, and to retain existing implementations of deprecated SRFIs for a reasonable time period.

New standards, such as RⁿRS, may supersede or conflict with existing SRFIs. The editors and authors will work to update the relationship of active SRFIs to such standards.

Errata

Anyone who finds an error should report it to the SRFI's discussion mailing list. That way, it will be recorded publicly.

We always attempt to reach the author for guidance.

If the corrections are only to the implementation, not the document, we just make the change.

If the author agrees to proposed corrections to the document, or if the author never expresses an opinion but there is consensus about corrections on the mailing list, we'll revise the document. See the example of SRFI 158. In this case, a tag like errata-1 is added in the Git repository.

Structure

Every SRFI must meet the following requirements:

1. It must have a succinct title.
2. It must list the authors.
3. It must list related standards and SRFIs, including dependencies, conflicts, and replacements.
4. It must begin with an abstract. This will be fewer than 200 words long. It will outline the need for, and design of, the proposal.
5. It must contain a detailed rationale. This will typically be 200-500 words long and will explain why the proposal should be incorporated as a standard feature in Scheme implementations. If there are other standards which this proposal will replace or with which it will compete, the rationale should explain why the present proposal is a substantial improvement.
6. It must contain a detailed specification. This should be detailed enough that a conforming implementation could be completely created from this description.
7. It must contain a sample implementation. This requirement may be met (in order from the most to the least preferred) by:
   1. A portable Scheme implementation (possibly using earlier SRFIs). This is the most desirable option, because then implementors can provide a (possibly slow) implementation with no effort.
   2. A mostly-portable solution that uses some kind of hooks provided in some Scheme interpreter/compiler. In this case, a detailed specification of the hooks must be included so that the SRFI is self-contained.
   3. An implementation-specific solution. Ideally, tricky issues that had to be dealt with in the implementation will be identified.
   4. A separately available implementation, where a sample implementation is large or requires extensive modifications (rather than just additions) to an existing implementation. This implementation will eventually be archived along with the SRFI and the discussion related to it.
   5. An outline of how it might be implemented. This should be considered a last resort, and in this case the rationale for the feature must be stronger.

   The sample implementation should normally conform to the specification in point 6 above. If there is any variance (such as the implementation being overly restrictive), the specification will be considered correct, the variance should be explained, and a timetable provided for the sample implementation to meet the specification.

   The sample implementation should include automated tests. Tests make porting to new Scheme implementations easier. They also help users understand how your SRFI is to be used. However, if the sample implementation is trivial or not really meant to be used, i.e. it is just a proof of concept, it's okay to omit tests. That should be a rare case. No specific test framework is required, but both SRFI 64 and SRFI 78 are available.

   A SRFI may be submitted without an implementation so that the specification may be refined before effort is invested in implementing it. However, an implementation should be provided as soon as possible.

8. A proposal must be submitted in HTML (3.2 or later) format following the template located here. All proposals must be written in English, be properly formatted, and be reasonably grammatical.
9. It must contain an MIT/Expat copyright statement as follows (where AUTHOR should be replaced by the name(s) of the author(s) and YEAR will be the year in which the SRFI number is allocated):

   Copyright (C) AUTHOR (YEAR).

   Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

   The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.

   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

   In addition to the SRFI document, any software written specifically for the SRFI should be published under the above license. However, at the editors' discretion, the SRFI may reference software that was already written and published under another license, citing that software as its sample implementation. The BSD 2- and 3-clause licenses are specifically allowed for this purpose.

   Starting in December, 2023, SRFIs use the SPDX (The Software Package Data Exchange) system for tracking licenses of SRFI sample implementations. This is the checklist used to ensure that SPDX metadata is applied properly:

   1. The SRFI text MUST include the text of the MIT/Expat license.
   2. All source and data files included in the repo SHOULD be published under the MIT/Expat license.
      1. Any license notice already present in a file MUST be retained as is.
      2. If the format of a file supports comments, and the file is at least fifteen lines long, it MUST contain a copyright notice. It MUST also contain the corresponding SPDX metadata. If the file uses a custom license, the SPDX LicenseRef strategy SHOULD be employed. If a file is a derivative work, it may also include the license of the original work, or a reference to it, if that is required by the license of the original work.
      3. If the format of a file does not support comments, nothing SHOULD be added to the file. Instead, the standard external SPDX metadata SHOULD be used.
   3. The reuse lint command SHOULD pass, i.e. the SRFI SHOULD be REUSE-compliant. This means that every source file SHOULD contain a SPDX-License-Identifier tag with the license, and that a LICENSES/ directory SHOULD contain the referenced license's text.

The editors may not reject a proposal because they disagree with the importance of the proposal, or because they think it is a wrong-headed approach to the problem. The editors may, however, reject a proposal because it does not meet the requirements listed here.

In particular, lack of a sample implementation (as defined above) is grounds for rejection. This can only occur if the "sample implementation" requirement is being met by an outlined implementation (type 5), and there is consensus that the implementation outline is not adequate. Note that this is never a permanent rejection, because creation of an implementation of one of the other types is a complete refutation of this basis for rejection.

The other likely basis for rejection is an inadequate design specification. In this case, the editors will attempt to help the author(s) conform to the requirements.

Remember, even if a proposal becomes a final SRFI, the need for it must be compelling enough for implementors to decide to incorporate it into their systems, or it will have been a waste of time and effort for everyone involved. If the quality of any SRFI is not high, the likelihood of implementors adding this feature to their implementation is extremely low.

Definitions

The following terms may be used in SRFIs with the corresponding definitions: The term "a SRFI <n>-conformant implementation" means an implementation of Scheme which conforms to the specification described in SRFI <n>.

The history of this document is here.