by Dave Mason, with edits by various editors
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.
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.
All proposals must follow the following steps:
srfi minus editors at srfi dot schemers dot org.
srfi minus announce at srfi dot schemers dot org. As part of the initial editing process, the editors will ensure that related standards (RnRS, 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.
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.
srfi minus announce at srfi dot schemers dot org.
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:
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 RnRS, may supersede or conflict with existing SRFIs. The editors and authors will work to update the relationship of active SRFIs to such standards.
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
158. In this case, a tag like
errata-1 is added in
the Git repository.
Every SRFI must meet the following requirements:
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.
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.
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.
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.