Scheme
Request For Implementation - FAQScheme
Request For Implementation - FAQThe 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 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.)
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 anyone.
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.
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 reports.
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 the discussions of the RnRS authors, as they have often considered issues that are candidates for SRFIs.
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 public forums like r/scheme on Reddit. When the discussions have coalesced to the point where an implementation strategy is apparent, then it is time to write up a SRFI proposal.
You're not alone! There seem to be lots of people who disagree with the editors on this point. If you have ideas on how this should be done, please send mail to <srfi minus editors at srfi dot schemers dot org>
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.
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.
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, poorly reasoned, or poorly defended SRFIs will be nothing more than a waste of some time — regrettable, but necessary to retain an open process.
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.
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.
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 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.
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 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, assuming that 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?
Yes.
Yes.
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.
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.
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
created using 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, or diffs, and we'll check in the changes.
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
licensed).
srfi-123.html: srfi-123.md
pandoc \
--css=http://srfi.schemers.org/srfi.css \
--from=markdown_github-hard_line_breaks \
--include-in-header=header.html \
--standalone \
--to=html \
srfi-123.md \
>srfi-123.html
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.
Starting in about 2019, new SRFIs use some of the conventions of the R7RS Small report (PDF), section 1.3.2, a shortened form of which appears here. Note that SRFIs before about 2019 may not follow these conventions.
When speaking of an error situation, we use the phrase “an
error is signaled” to indicate that implementations must
detect and report the error by raising a non-continuable
exception, as if by the procedure raise. The
phrase “an error that satisfies predicate is signaled”
means that an error is signaled as above. Furthermore, if the
object that is signaled is passed to the specified predicate,
the predicate returns #t.
The phrase "is an error," however, means that implementations are not required to detect or report the error. In fact, the implementation may take any action whatsoever, such as signaling an error, extending a procedure’s behavior, or failing catastrophically. If the value of an expression is said to be “unspecified,” then the expression must evaluate to some object without signaling an error, but the value depends on the implementation.
Finally, the words and phrases “must,” “must not,” “shall,” “shall not,” “should,” “should not,” “may,” “required,” “recommended,” and “optional" are to be interpreted as described in RFC 2119 unless otherwise specified. They are used only with reference to implementer or implementation behavior, not with reference to programmer or program behavior.
We are happy to accept contributions. We'll publish your code in
the SRFI's Git repository. Please
include a README file, and use the copyright notice
from the SRFI process.
Please send email to srfi-editors@nospamsrfi.schemers.org.
See Errata in the Process document.
The history of this document is here.