Title"Scheme Request for Implementation" Process
The goal of this mechanism is to provide a permanent registry for
"Scheme Request For Implementation"s (SRFIs - pronounced
"surfie"). This is not a formal standards creation mechanism.
Rather, it is a formal way to manage the production of proposals for
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
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
A moderated mailing list,
srfi-announce at srfi dot schemers dot org,
will be used to announce when new SRFI proposals become draft;
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:
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 3 states will be
available and archived indefinitely and SRFI numbers will not be
final state is permanent, and the only change that may be
made to such a SRFI is the updating of URLs (including related SRFIs)
or noting the SRFI as deprecated, conflicted, or superseded by a subsequent SRFI.
Every Scheme implementation is encouraged to provide implementations
of active SRFIs where possible, and to retain existing implementations
of deprecated SRFIs for a reasonable time period.
- Authors submit a proposal by sending email to
srfi minus editors at srfi dot schemers dot org.
- Within 7 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 (although it must conform before it will be moved to
- 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 temporary
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.
- 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
srfi minus announce at srfi dot schemers dot org,
and all revisions will be retained in the permanent record of the
SRFI. Re-submission may cause the comment period to be extended at
the discretion of the editors.
This part of the process is being reconsidered:
The total discussion period
must not exceed 90 days. Active discussion or revision
after 90 days normally suggests that a proposal has been revised at
least 3 times and is not yet mature enough for standardization.
- 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.
- If the SRFI is withdrawn at the end of the comment period, it will
be moved to a withdrawn proposal archive. At the discretion
of the editors, subsequent related proposals (by the same or different
authors) may be encouraged to include/modify the withdrawn proposal
and may be treated as a reactivation of the withdrawn proposal and
move it back to draft. A withdrawn proposal may not
normally be reactivated until 30 days after the withdrawal.
- 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.
- 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.
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.
Every SRFI must meet the following requirements:
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.
- It must have a succinct title.
- It must list the authors.
- It must list related standards and SRFIs, including dependencies, conflicts, and replacements.
- 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.
- 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.
- It must contain a detailed specification. This should be detailed
enough that a conforming implementation could be completely created
from this description.
- It must contain a sample implementation. This requirement may be met
(in order from the most to the least preferred) by:
- 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.
- 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
- An implementation-specific solution. Ideally, tricky issues that
had to be dealt with in the implementation will be identified.
- 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.
- 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 5. 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.
- A proposal must be submitted in HTML (3.2 or later) format
following the template located here.
If the author(s) are not familiar with this, the editors will accept
Plain ISO Latin 1 text and convert it to HTML, after which any
revisions must remain in HTML. All proposals must be written in
English, be properly formatted and be reasonably grammatical.
- It must contain a 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 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 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 an 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 SRFI Editors
The history of this document is here.