Scheme Request for Implementation - FAQ
The ``Scheme Request for Implementation'' process is documented elsewhere. This document is
intended to provide some of the rationale about SRFIs rather than
cluttering up that document.
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 being provided to the Scheme community by
the editors, currently David
Sperber, and David Van
Horn, with a home provided by the Programming Languages
and Compilers group at the University of Tübingen.
- 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-???? and IEEE-???. 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. The editors of the SRFIs do not currently include any of the
editors of any of the Revised Reports.
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 reports.
Of course anyone, including authors of future Revised Reports, is
welcome to employ the definition and rationale of an 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 the discussions
of the RnRS authors, as they have often considered issues that are
candidates for SRFIs.
- Are SRFIs a discussion forum for preliminary ideas?
- 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 proposal.
- I really think that there should be a place to archive non-implementation documents.
- 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 time?
- 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 unofficial standards.
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 implementation?
- 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.
- Do SRFIs exist to describe the features of a particular Scheme implementation?
- 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 requires.
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
- 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 implementation?
- Does the SRFI copyright permit using parts of a SRFI in
the documentation of my
- 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 proposed.
The SRFI Editors
Last modified: Mon Apr 27 08:37:30 MST 2009