Growing Schemes Twenty Years of Scheme Requests for Implementation
Total Page：16
File Type：pdf, Size：1020Kb
Growing Schemes Twenty Years of Scheme Requests for Implementation ARTHUR A. GLECKLER, Editor, Scheme Requests for Implementation, USA SRFI[21], or Scheme Requests for Implementation, is an informal process for extending the Scheme programming language. It has run in parallel with, and has sometimes contributed to, more formal Scheme standardization efforts like R6RS and R7RS. Since the inception of SRFI in 1998, SRFI contributors have prepared 162 detailed documents proposing extensions to Scheme, most with sample implementations, and many with test suites as well. SRFIs cover ideas like mechanisms for concurrency, error handling, internationalization, and pattern matching; control constructs and data structures; module systems; operating system interfaces; and more. In this paper, we explain the purpose of the SRFI process, how the process works, and how it has been part of the evolution of Scheme. We hope that implementers and users of Scheme and other programming languages can benefit from learning about this approach to moving the language forward. CCS Concepts: • Software and its engineering → Language features; Additional Key Words and Phrases: Scheme programming language, Scheme Requests for Implementation, standards ACM Reference Format: Arthur A. Gleckler. 2018. Growing Schemes: Twenty Years of Scheme Requests for Implementation. 1, 1 (September 2018), 18 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Twenty years ago, after an R5RS meeting, thirty-two people attended the Scheme Strawman Workshop[22, 36]. The workshop announcement said, “Our intent is to get users and implementors together to discuss their experiences with existing extensions and to discuss possible extensions and modifications to Scheme.” The discussion that started with that meeting has continued online ever since as SRFI, the Scheme Requests for Implementation. 1.1 Motivation If you are a Scheme programmer, you may use more than one Scheme implementation, either because different ones are suited for different operating systems, or because you prefer one for its performance but another for its debugging tools, or because one is better for teaching and another is better for production, or for another reason. But you would surely still like to be able to run code you wrote for one implementation on the others. Formal Scheme standards like R5RS, R6RS[5], and R7RS[8] lay the groundwork, providing a concrete, portable layer, but they only go so far. The Scheme Requests for Implementation process picks up where those standards leave off. SRFI is a less formal way to propose new extensions to Scheme, to discuss them with other users,and to encourage Scheme implementers to support them. Author’s address: Arthur A. Gleckler, Editor, Scheme Requests for Implementation, Sunnyvale, CA, 94087, USA, [email protected]. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on thefirstpage. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). © 2018 Copyright held by the owner/author(s). XXXX-XXXX/2018/9-ART https://doi.org/10.1145/nnnnnnn.nnnnnnn , Vol. 1, No. 1, Article . Publication date: September 2018. :2 • Arthur A. Gleckler 1.2 Making use of SRFIs There are many ways to make use of the SRFI process: • If you need a specific data structure, or a portable operating system interface, or a testing framework, or support for bitwise operations or concurrency or random numbers or regular expressions, or some other library or extension to the language, you can turn to existing SRFIs. Your Scheme implementation may already support the SRFI you want. If not, try using the provided sample implementation. • If the feature you want exists in one implementation but not in others, you can document it clearly and use the SRFI process to propose that other implementations adopt it. • If you are the author or maintainer of an existing Scheme implementation, you can choose from a wide variety of SRFIs and either use the provided sample implementations or write your own. • If you are helping to create one of the official Scheme standards, e.g.n anR RS, you can use the SRFI process to publish and discuss proposals for inclusion in your standard. Both R6RS[5] and R7RS-large[8] have done this. Or you can simply draw ideas from SRFIs and incorporate them, as R7RS-small[8] did. • You can participate in the discussion of proposed SRFIs, influencing their APIs and how they work, contributing to their design and implementation, and encouraging the authors and maintainers of your favorite Scheme implementations to adopt them. 2 HOW DOES THE SRFI PROCESS WORK? For many use cases, the SRFI process is simple: review the SRFIs provided by the Scheme implementation being used, find the one with the desired features, load it using that implementation’s standard mechanism, anduse it. If the implementation’s documentation doesn’t describe the SRFI, read the documentation on the SRFI web site[21]. Each SRFI is identified by a unique number in addition to its title, so it’s easy to look it up. As of thiswriting, there are 124 “final” SRFIs (see figure 1 and table 3) covering a wide variety ofneeds. 2.1 Requests SRFIs are requests, not formal standards. The idea is that someone who wants a new feature to be added to Scheme implementations can propose the feature, specify it in detail, provide a sample implementation and automated tests, and discuss and revise the proposal publicly so that it is as understandable and useful as possible. All this makes it as easy as possible for authors and maintainers of Scheme implementations to support the requested feature. Once a SRFI has been finished, or “finalized,” it’s up to the authors and maintainers of Scheme implementations to decide whether to support it. But even if they don’t, support for a particular SRFI can often be added to an implementation by its users. The SRFI editors ensure that all the requirements are met before a SRFI can be finalized1. For example: • Each SRFI document must be in HTML format. • Each SRFI document must follow a standard template[20] that includes a rationale, a detailed specification, a description of the sample implementation, an acknowledgements section, and an open-source copyright statement. • Sample implementations are required in all but the most unusual circumstances.2 • Automated tests are strongly encouraged. 1This work is done manually for the most part, but automated tests are run and spell checkers are used. 2Only five of the 124 final SRFIs — 18, 21, 22, 36, and 97 — do not include some form of sample implementation, either in the documentitself, elsewhere in the Git repo, or in some external location, e.g. as part of an existing Scheme implementation. , Vol. 1, No. 1, Article . Publication date: September 2018. Growing Schemes • :3 Per the SRFI process, the editors are not allowed to 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[24].” An editor’s job is to facilitate the discussion and dissemination of SRFIs, but not to approve or reject them based on the ideas they contain. Ultimately, each SRFI is the responsibility of its author. While the author may revise the SRFI based on public discussion on the SRFI mailing list — and, indeed, this is common — the final decision whether to finalize itisup to the author, assuming that the editor agrees that it meets the SRFI requirements.3 Once it is finalized, though, it is up to the maintainers and users of Scheme implementations to decide whether to incorporate it into each implementation. This approach gives many ideas the breathing room and support that they might not get with a more consensus-driven process. 2.2 Email The process of proposing and reviewing a new SRFI is organized around email. It is described in detail at [24], but is summarized here. An author proposing a new SRFI submits a proposal to the SRFI editor(s) at [email protected]. The proposal document must be in HTML format and must follow the standard template[20]. Once the editor is satisfied that the proposal conforms to the SRFI requirements, the editor assigns it a unique SRFI number, publishes it as a first draft on the SRFI web site, creates a public email mailing list specifically for discussionof the new proposal, creates a Git[12] distributed version control repository on Github[17], and announces the new SRFI and mailing list publicly. Discussion of the SRFI is held on its public mailing list. Anyone may subscribe to any SRFI’s mailing list. Any subscriber may participate in the discussion. All messages are not only delivered to every subscriber, but are archived publicly on the web so that there’s a public, long-term, searchable record of all the decisions and thinking that went into making the final SRFI, and of any alternatives that were discussed, objections thatwere raised, etc. Even after an SRFI is finalized, its email mailing list remains open. That way, clarifications and corrections can be made and other discussion can occur even years later. 2.3 States Each SRFI can be in one of several states: draft, final, and withdrawn. (See figure 1.) Each SRFI starts in the draft state, and remains in that state through however many drafts are published as a result of discussion. At any time while a SRFI is in the draft state, its author may decide that it is not ready for publication.