1 History and Motivation
1.1 Origins at MIT (1975–1980)
The Scheme programming language was conceived in the mid-1970s at the Massachusetts Institute of Technology’s Artificial Intelligence Laboratory. Guy L. Steele Jr. and Gerald Jay Sussman, seeking to explore the semantics of programming languages through a minimal yet expressive dialect of Lisp, developed a series of “Lambda Papers” that introduced key concepts such as lexical scoping, first-class procedures, and continuations. The language was originally implemented as a teaching tool to study computation and language design, and its early experiments laid the groundwork for the formal specification process that followed.
1.2 Purpose of the Revision Process
The series of *Revised Reports on the Algorithmic Language Scheme* (abbreviated RnRS) was established to provide a stable, precise, and evolving standard for the language. Each revision aimed to refine the syntax, semantics, and standard library while preserving the core principles of minimalism, clarity, and expressive power. The process allowed the Scheme community to incorporate new ideas, correct ambiguities, and respond to practical implementation feedback without compromising the language’s foundational simplicity.
1.3 Relationship to Lisp and Lambda Calculus
Scheme is a dialect of Lisp, inheriting its parent’s use of S-expressions and dynamic typing. However, from its earliest days, Scheme diverged by adopting lexical scoping (as opposed to the dynamic scoping of earlier Lisp dialects) and by treating functions as first-class objects. The language’s design was heavily influenced by the lambda calculus, particularly in its support for anonymous functions and its disciplined approach to control flow through continuations. This linkage to theoretical models made Scheme a popular vehicle for research in programming language semantics.
2 Key Reports in the RnRS Series
2.1 R0RS to R3RS (Informal Drafts)
2.1.1 R0RS and the Lambda Papers
The first informal specification, sometimes retroactively called R0RS, was never published as a formal report. Instead, the ideas were disseminated through the Lambda Papers written by Steele and Sussman between 1975 and 1980. These papers introduced the foundational concepts that later appeared in the official revision reports.
2.1.2 R1RS (1985) – First formal standard
The first official *Revised Report* (R1RS) was published in 1985. It codified the core syntax and semantics of Scheme, including lexical scoping, tail recursion, and a simple numeric tower. R1RS served as the first widely recognized standard for the language and was used as a reference for early implementations.
2.1.3 R2RS and R3RS (1986–1990)
R2RS (1986) and R3RS (1990) followed in quick succession, adding minor clarifications and extending the standard library. R2RS introduced the let family of binding constructs, while R3RS refined the specification for continuations and introduced the call-with-current-continuation (call/cc) procedure. These reports remained relatively concise, reflecting Scheme’s minimalist philosophy.
2.2 R4RS (1991) – Consolidation
2.2.1 Introduction of Hygienic Macros
R4RS represented a significant step forward by incorporating a hygienic macro system based on pattern matching. This allowed programmers to define syntactic extensions that automatically avoided variable capture, a long-standing problem in earlier Lisp macro systems. The syntax-rules facility was introduced as a simple, declarative way to write macros.
2.2.2 Clarification of Tail Recursion
R4RS formalized the requirement that Scheme implementations must support an unbounded number of active tail calls. This guarantee, known as proper tail recursion, distinguished Scheme from most other programming languages and enabled iteration to be expressed naturally via recursion without stack overflow.
2.3 R5RS (1998) – The Classic Standard
2.3.1 Standard Library and Core Syntax
R5RS further refined the language while keeping the specification remarkably small—only about 50 pages. It defined a core set of procedures for arithmetic, lists, vectors, strings, and I/O, and established a clean separation between the language core and implementation-specific extensions. R5RS became the most widely implemented and referenced standard for many years.
2.3.2 Exceptions and Continuations
R5RS provided a simple exception-handling mechanism through with-exception-handler and raise, though many implementations extended this with additional facilities. The support for continuations via call/cc was fully specified, allowing powerful control flow abstractions.
2.3.3 The "Revised^5 Report" colloquialism
Due to the numbering convention (the report title reads “Revised^5 Report on the Algorithmic Language Scheme”), R5RS is often colloquially referred to as “Revised^5 Report” or simply “R5RS” in the Scheme community. This naming pattern has persisted for all subsequent reports.
2.4 R6RS (2007) – Expansive Redesign
2.4.1 Module System
R6RS introduced a formal module system based on explicit import and export declarations. This was a major departure from earlier implicit namespace handling and was intended to support larger-scale software development. Libraries could define their own identifiers and control visibility, promoting better encapsulation.
2.4.2 Unicode and Improved Numeric Tower
R6RS mandated full Unicode support for strings and identifiers, and significantly expanded the numeric tower to include unlimited-precision integers, rationals, reals, and complex numbers. The specification also defined a richer set of arithmetic operations and exactness properties.
2.4.3 Controversy and Incompatibilities
R6RS proved controversial within the Scheme community. Many implementation developers argued that the new module system was overly complex, and that the expanded library and numeric requirements made it difficult to implement efficiently on resource-constrained platforms. Several popular implementations chose not to adopt R6RS, leading to fragmentation.
2.5 R7RS (2013) – Small and Large Schemes
2.5.1 R7RS Small (2013)
2.5.1.1 Core language and libraries
R7RS Small aimed to produce a minimal standard that would be backward-compatible with R5RS while incorporating select improvements from R6RS. It retained the classic syntax and added a few new procedures, such as when, unless, and case-lambda, as well as a simple exception system and a library mechanism based on a subset of the R6RS module system.
2.5.1.2 Portability and minimalism
A key goal of R7RS Small was to maximize portability across diverse implementations. The specification deliberately kept the core language small and left many advanced features (e.g., full Unicode, compound types) to the separate R7RS Large effort or to implementation-specific extensions.
2.5.2 R7RS Large (ongoing)
2.5.2.1 Red Edition and subsequent editions
The R7RS Large process is organized into thematic editions. The first completed edition, called the Red Edition, focused on data structures and procedural programming. Subsequent editions (e.g., Orange, Yellow, and Green) have addressed topics such as strings, regular expressions, and parallel computing. Each edition adds a set of libraries that are optional for implementations but recommended for full conformance.
2.5.2.2 Community-driven process
The R7RS Large work is conducted openly under the auspices of the Scheme community, with proposals submitted as Scheme Requests for Implementation (SRFIs). The process is designed to be inclusive and iterative, with public discussion and testing before final adoption.
3 Core Language Features Defined by RnRS
3.1 Lexical Scoping and First-Class Procedures
From the earliest reports, Scheme has enforced lexical (static) scoping: the meaning of a variable is determined by its location in the source code, not by the call stack. Procedures are first-class objects – they can be created dynamically, passed as arguments, returned from other procedures, and stored in data structures. This property, combined with lexical scoping, enables closures (procedures that capture their lexical environment).
3.2 Homoiconicity and S-Expressions
Scheme code is represented as S-expressions (symbolic expressions), making it easy to manipulate programmatically. Homoiconicity allows macros to treat code as data and vice versa, a feature inherited from Lisp. All RnRS reports preserve this characteristic, though the macro systems have evolved.
3.3 Proper Tail Recursion
A distinguishing feature of Scheme is its requirement that tail calls must not consume stack space. This means iterative processes can be written as recursive procedures without risk of stack overflow. The guarantee is specified in every RnRS report from R4RS onward and is considered essential for the language’s expressiveness.
3.4 Macro System
3.4.1 Syntax-rules (pattern-based) in R5RS
R5RS introduced syntax-rules, a pattern-based macro definition facility that is both hygienic and declarative. A macro is defined by a set of patterns and corresponding templates; the system ensures that identifiers introduced by the macro are renamed to avoid capturing variables from the surrounding code.
3.4.2 Syntax-case in R6RS and R7RS
R6RS replaced syntax-rules with the more powerful syntax-case system, which allows macros to perform arbitrary computation at expansion time by matching against syntactic patterns and generating code using templates. R7RS Small retained syntax-rules as the primary macro facility, but many implementations support syntax-case as an extension.
3.4.3 Explicit renaming macros
An alternative approach to macro writing, known as explicit renaming, has been adopted by some implementations (e.g., Chicken Scheme). This technique gives the macro writer direct control over variable renaming and supports both hygienic and unhygienic macros. While not part of any formal RnRS report, explicit renaming is discussed in the community as a complement to pattern-based systems.
3.5 Continuations and Call/cc
Scheme provides a first-class representation of the current continuation through the procedure call-with-current-continuation (usually abbreviated call/cc). A continuation captures the state of a computation at a given point; it can be stored and later invoked to resume execution from that point. This feature enables advanced control constructs such as exceptions, coroutines, and backtracking. Every RnRS report from R3RS onward has included call/cc.
3.6 Number Tower and Exactness
3.6.1 Exact and inexact rationals
Scheme distinguishes between exact and inexact numbers. Exact numbers represent rational numbers with unlimited precision, while inexact numbers are approximations (typically floating-point). Arithmetic operations propagate exactness, and the exactness is preserved through transcendental functions when feasible. All RnRS reports include this distinction.
3.6.2 Complex numbers in all reports
From R1RS onward, Scheme has supported complex numbers as a built-in numeric type. The full numeric tower (integer, rational, real, complex) is defined along with exact/inexact semantics. R6RS and later reports also provide a richer set of transcendental functions (e.g., sin, log, exp) that operate on complex arguments.
4 Impact and Legacy
4.1 Influence on Other Languages (JavaScript, Clojure, Racket)
Scheme’s innovations, especially lexical scoping, first-class functions, and closures, have influenced many modern programming languages. JavaScript’s closure semantics and support for anonymous functions trace back to Scheme. Clojure, a Lisp dialect that runs on the Java Virtual Machine, explicitly acknowledges Scheme as an inspiration for its functional style and emphasis on immutability. Racket, originally a dialect of Scheme, evolved into a separate language platform but retains much of Scheme’s core design.
4.2 Teaching and Academic Use
Scheme has long been a favorite language for introductory programming courses, particularly due to its minimal syntax and powerful abstractions. The textbook *Structure and Interpretation of Computer Programs* (SICP), which uses Scheme, has been widely used to teach fundamental principles of computer science. Many universities continue to adopt Scheme or its descendants in courses on programming languages and functional programming.
4.3 Comparison with Common Lisp and ANSI Standard
Common Lisp, standardized as ANSI X3.226-1994, takes a different approach: it is a large, multi-paradigm language with a rich standard library, while Scheme remains intentionally small and minimalist. Common Lisp uses dynamic scoping by default (though lexical scoping is also available) and provides a more complex macro system. Scheme’s clean semantics and emphasis on recursion over iteration make it more accessible for educational contexts, whereas Common Lisp is often favored for industrial applications requiring extensive built-in functionality.
4.4 Practical Implementations (Guile, Chicken, Gambit, etc.)
Numerous implementations of Scheme have been created, many targeting different niches:
- GNU Guile: An implementation designed for embedding in applications, used for GNU system extensions.
- Chicken Scheme: A compiler that translates Scheme to C, focusing on portability and a rich set of egg libraries.
- Gambit Scheme: Another compiler to C, known for high performance and support for concurrent programming.
- Racket: Originally a Scheme implementation (PLT Scheme) that later developed its own language platform with a strong emphasis on language-oriented programming.
- Chez Scheme: A high-performance implementation with a fast compiler and advanced macro support, used commercially.
5 Future Directions
5.1 Post-R7RS Activity
After the publication of R7RS Small, the community’s focus shifted to completing R7RS Large. As of the early 2020s, several editions have been published, but the process remains ongoing. Some implementers have expressed interest in a possible R8RS Small that might further simplify or unify the language, but no official work has begun.
5.2 Role of Scheme Requests for Implementation (SRFIs)
The SRFI process has been a critical mechanism for proposing and standardizing extensions to Scheme independently of the formal report cycle. Many features that eventually appear in R7RS Large (such as hash tables, regular expressions, and concurrency libraries) first circulated as SRFIs. This grassroots approach helps maintain community involvement while allowing the language to evolve incrementally.
5.3 Potential R8RS or Alternative Standards
Given the fragmentation that followed R6RS, the future of the RnRS series is unclear. Some community members advocate for a new, lightweight standard that reconciles the R5RS and R7RS Small philosophies, possibly targeting embedded and web use cases. Others argue that the diversity of implementations and their individual dialects (e.g., Racket’s own language series) reduces the need for a single monolithic standard. Any future revision will likely aim for broad consensus, minimalism, and backward compatibility with the most popular existing implementations.