The SRFI process grew out of the Scheme Workshop held in
Baltimore, MD, on September 26, 1998, where the attendees
considered a number of proposals for standardized feature sets
for inclusion in Scheme implementations. Many of the proposals
received overwhelming support in a series of straw votes. Along
with this there was concern that the next Revised Report would
not be produced for several years and this would prevent the
timely implementation of standardized approaches to several
important problems and needs in the Scheme community.
The SRFI process is a service provided to the Scheme community by
the editors, currently Arthur A. Gleckler. See SRFI History for information on the
previous editors. As of July, 2015, SRFI is hosted on new
mail and web hosts. (See the new Hosting Plan.)
- Are SRFIs standards?
Yes and no. SRFIs are not official
standards. There exist organizations such as ISO, IEEE, ANSI,
etc. who are set up to develop official standards. The SRFI
process is designed as an attempt to maximize the quality of
SRFIs within the constraint of not assigning authority to
There are official Scheme standards, ANSI Scheme and
IEEE-1178-1990. SRFIs are in addition to these standards.
On the other hand, the process for creating SRFIs
is standardized, and each final SRFI remains
frozen and publicly available, hence they have many of the
properties of standards. So you might choose to think of them
as unofficial standards.
- Are SRFIs replacements for RnRS?
No. Each Revised Report has been written by a different body,
which determines what eventually is and is not included in
that report. The SRFI process is orthogonal to all of these
reports. Authors of SRFIs must not expect that their SRFIs
will be included, or even be considered, by the authors of
Of course anyone, including authors of future Revised
Reports, is welcome to employ the definition and rationale of
a SRFI, the discussion surrounding its adoption, and its
widespread implementation to argue that the authors of a
standard or report should consider adding the contents of the
SRFI to that standard.
If SRFIs had existed before R4RS, the macro appendix to
that report might have made more sense to have been released
as a SRFI. But it didn't. So it wasn't.
There is considerable value in reading
discussions of the RnRS authors, as they have often
considered issues that are candidates for SRFIs.
- Are SRFIs a discussion forum for
- No. SRFIs stands for ``Scheme Request for Implementation''.
Note the last word. If someone has amorphous ideas for
something that would be cool, but has no idea how it might be
done, they should discuss it in journals, workshops, seminars
or news groups. When the
discussions have coalesced to the point where an implementation
strategy is apparent, then it is time to write up a SRFI
- I really think that there should be a place to archive
- You're not alone! There seem to be lots of people who
disagree with the editors on this point. We will almost
certainly address this need in the not too distant future -
possibly within the SRFI process, or more likely with a
separate process. If you have ideas on how this should be done,
please send mail to <srfi
minus editors at srfi dot schemers dot org>
- Are SRFIs ``RFCs for the Scheme community''?
- Not quite. As RFC1796 (Not All RFCs are
Standards) says, RFCs serve a variety of purposes. The SRFI
editors feel that there are sufficient other venues for
discussion of ideas. The point of SRFIs is that a programmer
can dependably test to see what features a Scheme
implementation provides, and can therefore program in a
portable way beyond the bounds of standardized Scheme.
- What's with all the time periods? Why so little
The time periods are an attempt to drive the SRFI process as
quickly as possible while maintaining sufficient time for
sober second thought. To maximize the quality of SRFIs, we
want all of the relevant people to be involved in the
discussion of any particular SRFI proposal. Many of those
people are very busy, and this mechanism constrains the time
commitment they must make to stay on top of a proposal. It
also prevents discussion on a proposal from dragging on in an
endless repetition of the same points, long after anyone's
opinion is likely to be changed.
The other issue in the timing is to prevent editors from
stone-walling a proposal. It is not their job to make
qualitative judgments about proposals, but rather to maintain
the quality while expediting the creation of important
If a proposal is still under discussion after 90 days, it
means that it has been extended several times. The editors
will normally extend the discussion period to maintain a
minimum of 15 days after any significant change. Any proposal
still under active discussion and revision after 90 days is
not ready for codification. It will then be withdrawn for a
(normal) minimum of 30 days after which it may be
resubmitted. If it is now in good shape, it will likely
become final after the 60 day discussion period. Thus, it
will have been delayed a maximum of 90 days. This is likely
to happen only in very exceptional cases, and is the only
cost of the fixed time periods.
- What kind of standards are these,
anyway? There aren't any teeth in the rules!
- To have enforcement, there must be authority. There is no
absolute authority in the Scheme community, so there can be no
absolute enforcement. The final authority is the implementors.
If they believe that a particular SRFI documents a useful or
important feature, they will add it to their implementations;
if not, they won't. The discussion relating to any SRFI will be
retained indefinitely, and implementors can refer to that when
making their decision. Hence poorly worded, reasoned, or
defended SRFIs will be nothing more than a waste of some time -
regrettable, but necessary to retain an open process.
- Why do I have to include a reference
- See the discussion above about preliminary ideas. SRFIs are about
implementation. If you haven't either: (a) built one, or (b)
have a very clear outline of how to build one, then you aren't
documenting anything useful about implementation. As the
process document says: if you think the editors are wrong to
withdraw your proposal because it doesn't have a sufficient
outline of implementation, then prove us wrong by going and
implementing it on some system. Then your SRFI will return to
draft, and eventually active status.
- What standard should my reference implementation use?
- We encourage contributors to use R7RS combined with other
SRFIs as a basis. However, some SRFIs will require features not
present in R7RS and other SRFIs, and that's okay. Furthermore,
using other RnRS standards, as well as IEEE Scheme, is acceptable.
- What should my reference implementation include?
- It should implement all the features described in the SRFI document.
It should also include automated tests. Having them will
help implementors, and that will increase the likelihood that
your SRFI will be incorporated in Scheme implementations. It
will also help users understand how your SRFI is to be used.
However, if the reference 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.
- Do SRFIs exist to describe the features of a particular
No. Every SRFI should describe a cohesive feature set that is
portable across a variety of Scheme implementations. (Here we
mean portable in the sense of being possible to implement,
not in the sense of a portable implementation.) Rather than
testing to see if the implementation is, e.g. Guile-4.3c, a
program should test for the particular features that it
This is a lesson learned from the Emacs world where it
used to be that code would check to see what version of Emacs
it was running on and make assumptions about the features
that that particular version provided. Unfortunately that
made the code un-portable to alternative Emacs
implementations that had the required features but different
series of version numbers. The same lesson can be observed in
old C code that assumed that such-and-such a system had
particular features. More commonly today, C programs use a
configuration program that determines what libraries and
functions are available, regardless of the system or
compiler. The mechanism documented in SRFI
7 essentially provides a similar capability, while
staying within Scheme code.
The biggest advantage of checking for features rather than
implementations is that code becomes portable to systems of
which the author was unaware, if they provide the features
that the program requires.
- The process document mentions that different SRFIs may
conflict with each other. Won't that make it impossible for an
implementation to support conflicting SRFIs?
- Not necessarily. See SRFI 7.
- Does the SRFI copyright permit using a SRFI sample
implementation (or a derivative of one) in my Scheme
- Does the SRFI copyright permit using parts of a SRFI in
the documentation of my Scheme implementation?
- Where did the acronym come from? It's a mouthful.
- Alan Bawden suggested RFI at the Scheme workshop as a
humorous reference to RFCs. The S was added because the initial
editors (and others) felt that ``Scheme'' should be in there
somewhere. If you pronounce it ``ess-are-eff-eye'' it certainly
is a mouthful, but if you pronounce it ``surfie'', as we do,
it's fine. Scheme Implementation Request (SIR) was also
- Are there any special considerations if I use Github to
propose or comment on a SRFI?
- Please keep the discussion of each SRFI on its mailing
list. For example, if you create a pull request, send all your
comments to the mailing list. While Github's tools can be
convenient, we don't want to lose any of our history to Github.
While their APIs make it straightforward to download almost
everything (e.g. comments, issues, and pull requests), we don't
have code in place to do that automatically.
- What if I don't want to use Github?
- If you'd rather not use Github to propose SRFIs or
revisions to them, feel free to point the editors at alternate
Git repos or to send us patch files. (Patch files can be
git format-patch -M origin/master or
git send-email.) If you're a SRFI author and
would rather not use Git, either, just send updated files (or
links to them) and we'll check in the changes.
- May I use Markdown or another format?
- You may include a Markdown version, but you must still submit
the SRFI document as HTML.
Below is a snippet from the
Makefile of SRFI 123.
It generates HTML from Markdown using the Pandoc tool (GPL
Remember that the editors need to make slight changes to the
document, e.g. to add to its history of drafts, and won't edit
the document in a format other than HTML. We've made exceptions
for Markdown because of the ease of using Pandoc, but that's at
the editors' discretion.
- May I contribute code to a final SRFI, e.g. an implementation
of the SRFI for a specific Scheme implementation?
- We are happy to accept contributions. We'll put your code in
the SRFI's Git repository under
README file, and use the copyright notice
from the SRFI process.
- Whom should I contact if I find a problem with the web site, etc?
- Please send email to firstname.lastname@example.org.
- How are errata handled?
- Anyone who finds an error should report it to the SRFI's
discussion mailing list. That way, it will be recorded
If the author agrees to a correction and it is
straightforward, we'll revise the document itself. See the
example of SRFI
Otherwise, or until the author has expressed an opinion, we
add a link to an errata
page to the Status section. See the example of SRFI
48. That way, the document remains unchanged, but
everyone can easily find the correction.
In either case, a tag like
errata-1 is added in
the Git repository.