# Scheme Requests for Implementation

Since 1998, the Scheme Requests for Implementation (SRFI) process has been helping Scheme users write portable, useful Scheme code. We write concrete, detailed proposals and sample implementations for libraries and other additions to the Scheme language, and we encourage Scheme implementors to adopt them.

If you're interested in reading existing proposals, writing a new one (template), providing feedback on a draft proposal, helping with a sample implementation, or reporting a bug, please read about our process, skim our FAQ, and subscribe to some of our mailing lists, including srfi-announce and srfi-discuss.

In addition to mailing lists about SRFIs, we host the Scheme Topics mailing lists, which are for discussing specific subjects that we hope may lead to SRFIs and other cooperative work, but which are currently not ready for specific proposals through the SRFI process. So far, we have these lists: schemecomm, schemedoc, schemepersist, and schemeweb.

Everyone is welcome to join our discussions. Please subscribe here. (You must subscribe in order to post messages.)

## The SRFIs

• 196: Range Objects, by John Cowan (text) and Wolfgang Corcoran-Mathe (sample implementation)Draft: 2020-05-17Keywords: Data Structure

Ranges are immutable collections that can be enumerated but are represented algorithmically rather than by a per-element data structure. This SRFI defines a large subset of the sequence operations defined on lists, vectors, and other collections. If necessary, ranges can be converted to a list of its elements or a generator that will lazily produce each element in the range.

• 195: Multiple-value boxes, by Marc Nieper-WißkirchenDraft: 2020-05-04Keywords: Data StructureSee also SRFI 111: Boxes.

This SRFI extends the specification of the boxes of SRFI 111 so that they are multiple-values aware. Whereas a SRFI 111 box is limited in that it can only box a single value, multiple values can be boxed with this SRFI.

• 194: Random data generators, by Shiro Kawai (design), Arvydas Silanskas (implementation), and John Cowan (editor and shepherd)Draft: 2020-05-04Keywords: RandomnessSee also SRFI 27: Sources of Random Bits.

This SRFI defines a set of SRFI 158 generators and generator makers that yield random data of specific ranges and distributions. It is intended to be implemented on top of SRFI 27, which provides the underlying source of random integers and floats.

• 193: Command lines, by Lassi KortelaDraft: 2020-04-19Keywords: Operating System

R6RS and R7RS define a command-line procedure. While a useful baseline, the specification is not detailed enough to cover all practical situations. This SRFI clarifies the definition of command-line and adds a few related procedures. Precise semantics for Unix and Windows are given. Scheme scripts, standalone executables, compilation and REPL use are accounted for. Option parsing is out of scope.

• 192: Port Positioning, by John CowanBased on R6RS.Draft: 2020-04-14Keywords: I/OSee also SRFI 181: Custom ports.

This is an extract from the R6RS that documents its support for positioning ports. Binary ports can be positioned to read or write at a specific byte; textual ports at a specific character, although character positions can't be synthesized portably. It has been lightly edited to fit R7RS style.

• 191: Procedure Arity Inspection, by John CowanBased on SRFI 102.Draft: 2020-04-14Keywords: Introspection

Many Scheme systems provide mechanisms for inspecting the arity of a procedural value, making it a common feature, however there is no standard interface. As a result there is no portable way to observe the arity of a procedure without actually applying it. This SRFI proposes a simple interface that is consistent with existing Scheme systems' facilities and prior proposals.

• 190: Coroutine Generators, by Marc Nieper-WißkirchenDraft: 2020-03-30Keywords: Syntax

This SRFI defines syntax to create SRFI 121/158 coroutine generators conveniently and in the flavor of Python generator functions.

• 189: Maybe and Either: optional container types, by John Cowan (text) and Wolfgang Corcoran-Mathe (sample implementation)Draft: 2020-03-29Keywords: Data Structure

This SRFI defines two disjoint immutable container types known as Maybe and Either, both of which can contain objects collectively known as their payload. A Maybe object is either a Just object or the unique object Nothing (which has no payload); an Either object is either a Right object or a Left object. Maybe represents the concept of optional values; Either represents the concept of values which are either correct (Right) or errors (Left).

Note that the terms Maybe, Just, Nothing, Either, Right, and Left are capitalized in this SRFI so as not to be confused with their ordinary use as English words. Thus "returns Nothing" means "returns the unique Nothing object"; "returns nothing" could be interpreted as "returns no values".

• 188: Splicing binding constructs for syntactic keywords, by Marc Nieper-WißkirchenFinal: 2020-06-03Keywords: Syntax

Splicing binding constructs for syntactic keywords are versions of let-syntax and letrec-syntax that can be used in a definition context in the same way as begin.

• 187: ALAMBDA and ADEFINE, by Joo ChurlSooBased on SRFI 92.Withdrawn: 2020-03-27Keywords: Miscellaneous, Type Checking

This SRFI introduces alambda, which creates a procedure that checks its actual arguments, takes various types of required and optional variables.
This SRFI is based on SRFI 92 as an extension of the optional arguments of SRFI 182.

• 186: Transcoders and transcoded ports, by John CowanBased on R6RS.Final: 2020-05-12Keywords: I/OSee also SRFI 80: Stream I/O, SRFI 81: Port I/O, and SRFI 181: Custom ports.

This is an extract from the R6RS that documents its support for transcoders and transcoded ports. These provide a hook into the Scheme port system from below, allowing the creation of textual ports that provide non-default encoding and decoding from arbitrary binary ports. It has been lightly edited to fit R7RS style.

• 185: Linear adjustable-length strings, by John CowanFinal: 2020-04-26Keywords: Data Structure

Scheme specifies mutable fixed-length strings. SRFI 118 adds two procedures, string-append! and string-replace!, which allow the length of the string to change. This SRFI provides two linear-update versions of these procedures: that is, the implementation may change the string length or return a new string instead. In addition, two convenience macros are provided that make the procedures somewhat easier to use.

• 184: define-record-lambda, by Joo ChurlSooWithdrawn: 2020-03-27Keywords: Data Structure

This SRFI introduces a macro, DEFINE-RECORD-LAMBDA, that defines a set of procedures, that is, a group of constructors and a predicate. The constructors also make a group of procedures, namely record lambdas, that have no explicit field accessors and mutators. They can have various kinds of fields, such as common fields, required fields, optional fields, automatic fields, read-only fields, read-write fields, invisible fields, immutable fields, and virtual fields.

• 183: Another format procedure, Fox, by Joo ChurlSooWithdrawn: 2020-03-27Keywords: I/OSee also SRFI 54: Formatting.

This SRFI introduces the formatting procedure Fox ("format of X"), which takes one required argument and a variable number of additional arguments and returns a formatted string.

• 182: ADBMAL, ALET, and ALET*, by Joo ChurlSooWithdrawn: 2020-03-27Keywords: Data Structure, Multiple Value Returns

Unlike the VALUES and CALL-WITH-VALUES mechanism of R5RS, this one uses an explicit representation for multiple return values as a single value, namely a procedure. Decomposition of multiple values is done by simple application. The macro, ADBMAL, evaluates to a procedure that takes one procedure argument. The ADBMAL macro can be compared with LAMBDA. While a LAMBDA expression that consists of <formals> and <body> requires some actual arguments later when the evaluated LAMBDA expression is called, an ADBMAL expression that consists of <expression>s corresponding to actual arguments of LAMBDA requires <formals> and <body>, that is, an evaluated LAMBDA expression, later when the evaluated ADBMAL expression is called.

This SRFI also introduces the new LET-syntax ALET and ALET*, which depend on ADBMAL to manipulate multiple values, and which are compatible with LET and LET* of R5RS in single-value bindings. They also have a binding form making use of VALUES and CALL-WITH-VALUES to handle multiple values, and new binding forms for list, cons, and other multiple values. In addition, they have several new binding forms for useful functions such as escape, iteration, optional arguments, etc.

• 181: Custom ports, by John CowanDraft: 2020-02-15Keywords: I/O

This SRFI is a lightly edited version of parts of library section 8.2.7, library section 8.2.10, and library section 8.2.13 of the R6RS. These sections are themselves based on parts of SRFI 79. These procedures provide support for transcoders and transcoded ports.

• 180: JSON, by Amirouche BoubekkiDraft: 2020-01-18Keywords: I/O

This library describes a JavaScript Object Notation (JSON) parser and printer. It supports JSON that may be bigger than memory.

• 179: Nonempty Intervals and Generalized Arrays (Updated), by Bradley J. LucierDraft: 2020-01-11Keywords: Data Structure

This SRFI specifies an array mechanism for Scheme. Arrays as defined here are quite general; at their most basic, an array is simply a mapping, or function, from multi-indices of exact integers $i_0,\ldots,i_{d-1}$ to Scheme values. The set of multi-indices $i_0,\ldots,i_{d-1}$ that are valid for a given array form the domain of the array. In this SRFI, each array's domain consists of the cross product of nonempty intervals of exact integers $[l_0,u_0)\times[l_1,u_1)\times\cdots\times[l_{d-1},u_{d-1})$ of $\mathbb Z^d$, $d$-tuples of integers. Thus, we introduce a data type called $d$-intervals, or more briefly intervals, that encapsulates this notion. (We borrow this terminology from, e.g., Elias Zakon's Basic Concepts of Mathematics.) Specialized variants of arrays are specified to provide portable programs with efficient representations for common use cases.

• 178: Bitvector library, by John CowanDraft: 2019-12-22Keywords: Data Structure
This SRFI describes a set of operations on homogeneous bitvectors. Operations analogous to those provided on the other homogeneous vector types described in SRFI 160 are provided, along with operations analogous to the bitwise operations of SRFI 151. In addition, a compact string representation compatible with Common Lisp is specified, which may be supported by the read and write procedures and by the program parser so that programs can contain references to literal bitvectors.
• 177: Portable keyword arguments, by Lassi KortelaDraft: 2019-10-16Keywords: Binding

Many Scheme implementations have keyword arguments, but they have not been widely standardized. This SRFI defines the macros lambda/kw and call/kw. They can be used identically in every major implementation currently in use, making it safe to use keyword arguments in portable code. The macros expand to native keyword arguments in Schemes that have them, letting programmers mix portable code and implementation-specific code.

• 176: Version flag, by Lassi KortelaFinal: 2020-02-24Keywords: Operating System

This SRFI defines a standard command-line flag to get version information from a Scheme implementation. The output is Line-oriented S-expressions which are easy to parse from Scheme, C, and shell scripts and can co-exist with non-S-expression output. A standard vocabulary is defined; extensions are easy to make.

• 175: ASCII character library, by Lassi KortelaFinal: 2019-12-20Keywords: Data Structure

This SRFI defines ASCII-only equivalents to many of the character procedures in standard Scheme plus a few extra ones. Recent Scheme standards are based around Unicode but the significant syntactic elements in many file formats and network protocols are all ASCII. Such low-level code can run faster and its behavior can be easier to understand when it uses ASCII primitives.

• 174: POSIX Timespecs, by John CowanFinal: 2019-12-21Keywords: Data Structure

This SRFI defines the trivial type timespec, which is used to represent the struct timespec defined by the POSIX <time.h> header.

• 173: Hooks, by Amirouche BoubekkiFinal: 2019-10-24Keywords: Miscellaneous

This library describes a mechanism known as hooks. Hooks are a certain kind of extension point in a program that allows interleaving the execution of arbitrary code with the execution of the program without introducing any coupling between the two.

• 172: Two Safer Subsets of R7RS, by John CowanFinal: 2019-11-10Keywords: Miscellaneous

This SRFI provides two libraries for use with R7RS that provide a way to sandbox the eval procedure to make it safer to use in evaluating Scheme expressions of doubtful provenance. The intention is to call eval, passing it an S-expression representing a Scheme procedure and the environment defined by one of these libraries. Since code evaluated by eval runs in a null lexical environment, the resulting procedure can then be invoked with less concern about possible side effects.

Use of these libraries does not provide any sort of safety guarantee. There are still many loopholes uncaught, including attempts to process circular structure and over-allocation of memory. The claim is only that the probability of such an attack is reduced, not that it is eliminated. However, using these libraries is a simple provision that is easy to implement and easy to use. For higher safety, it can readily be combined with other provisions.

• 171: Transducers, by Linus BjörnstamFinal: 2019-10-26Keywords: Data Structure

A library implementing transducers — composable algorithmic transformations. Scheme has many different ways of expressing transformations over different collection types, but they are all unique to whatever base type they work on. This SRFI proposes a new construct, the transducer, that is oblivious to the context in which it is being used.

• 170: POSIX API, by Olin Shivers (original author), John Cowan (editor and shepherd), and Harold Ancell (implementer and editor)Based on scsh by Olin Shivers.Draft: 2019-05-04Keywords: Operating System

The host environment is the set of resources, such as the filesystem, network and processes, that are managed by the operating system on top of which a Scheme program is executing. This SRFI specifies some of the ways the host environment can be accessed from within a Scheme program. It does so by leveraging widespread support for POSIX, the Portable Operating System Interface standardized by the IEEE. Not all of the functions of this SRFI are available on all operating systems.

• 169: Underscores in numbers, by Lassi KortelaFinal: 2019-07-26Keywords: Syntax

Many people find that large numbers are easier to read when the digits are broken into small groups. For example, the number 1582439 might be easier to read if written as 1 582 439. This applies to source code as it does to other writing. We propose an extension of Scheme syntax to allow the underscore as a digit separator in numerical constants.

• 168: Generic Tuple Store Database, by Amirouche BoubekkiFinal: 2019-11-08Keywords: I/OSee also SRFI 167: Ordered Key Value Store and SRFI 173: Hooks.

This library is a generic approach to the database abstractions known as triplestore and quadstore. Generic Tuple Store Database implements n-tuple ordered sets and associated primitives for working with them in the context of data management.

• 167: Ordered Key Value Store, by Amirouche BoubekkiFinal: 2019-11-08Keywords: I/O

This library describes an interface for an ordered key-value store that is suitable for implementing a storage engine for the generic tuple-store SRFI. It maps cleanly to existing ordered key-value databases that may or may not provide transactions.

• 166: Monadic Formatting, by Alex ShinnDraft: 2019-03-27Keywords: I/O

A library of procedures for formatting Scheme objects to text in various ways, and for easily concatenating, composing and extending these formatters efficiently without resorting to capturing and manipulating intermediate strings.

This SRFI is an updated version of SRFI 159, primarily with the difference that state variables are hygienic.

Summary of differences from SRFI 159:

• State variables are first class and hygienic
• Restored non-uniform comma rules as needed in India
• Restored upcased and downcased
• Several clarifications and more examples
• 165: The Environment Monad, by Marc Nieper-WißkirchenFinal: 2019-09-05Keywords: Miscellaneous
Monads model computations. The environment monad models computations that depend on values from a shared environment. These computations can read values from the environment, pass values to subsequent computations, execute sub-computations in an extended environment, and modify the environment for future computations.
• 164: Enhanced multi-dimensional Arrays, by Per BothnerFinal: 2019-08-08Keywords: Data Structure

This SRFI describes the array data type (a generalization of vectors to multiple indexes or dimensions), along with a set of procedures for working on them.

This specification is an extension of SRFI 25, with additions from Racket’s math.array package and other sources. It has been implemented in the Kawa dialect of Scheme.

• 163: Enhanced array literals, by Per BothnerFinal: 2019-01-18Keywords: Reader Syntax

This is a specification of a reader form (literals) for multi-dimensional arrays. It is an extension of the Common Lisp array reader syntax to handle non-zero lower bounds, optional explicit bounds, and optional uniform element types (compatible with SRFI 4). It can be used in conjunction with SRFI 25, SRFI 122, or SRFI 164. These extensions were implemented in Guile (except the handling of rank-0 arrays), and later in Kawa.

There are recommendations for output formatting and a suggested format-array procedure.

• 162: Comparators sublibrary, by John CowanFinal: 2019-08-27Keywords: Comparison

This SRFI provides a few extra procedures and comparators to go with SRFI 128, Comparators. Implementers are urged to add them to their SRFI 128 libraries, for which reason they are not packaged as a separate library.

• 161: Unifiable Boxes, by Marc Nieper-WißkirchenFinal: 2019-02-08Keywords: Data StructureSee also SRFI 111: Boxes.

Unifiable boxes are, like the boxes of SRFI 111, objects with a single mutable state. A constructor, predicate, accessor, and mutator are provided.

In addition to this, an equality predicate and union operations (link, union, unify) are provided. Applying a union operation to two unifiable boxes makes the two boxes equal (in the sense of the equality predicate). As a consequence, their state will also become identical. In the case of link and union, it will be the state of one of the two unioned boxes. In the case of unify, the state is determined by a supplied unification procedure.

Unifiable boxes are also known under the names disjoint-set data structure, union–find data structure or merge–find set.

• 160: Homogeneous numeric vector libraries, by John Cowan and Shiro Kawai (contributed a major patch)Based on SRFI 4 by Marc Feeley.Final: 2019-08-27

This SRFI describes a set of operations on SRFI 4 homogeneous vector types (plus a few additional types) that are closely analogous to the vector operations library, SRFI 133. An external representation is specified which may be supported by the read and write procedures and by the program parser so that programs can contain references to literal homogeneous vectors.

• 159: Combinator Formatting, by Alex ShinnFinal: 2018-01-17Keywords: I/O, R7RS Large, R7RS Large: Tangerine Edition

A library of procedures for formatting Scheme objects to text in various ways, and for easily concatenating, composing and extending these formatters efficiently without resorting to capturing and manipulating intermediate strings.

• 158: Generators and Accumulators, by Shiro Kawai, John Cowan, and Thomas GilrayFinal: 2017-10-27See also SRFI 121: Generators.

This SRFI defines utility procedures that create, transform, and consume generators. A generator is simply a procedure with no arguments that works as a source of values. Every time it is called, it yields a value. Generators may be finite or infinite; a finite generator returns an end-of-file object to indicate that it is exhausted. For example, read-char, read-line, and read are generators that generate characters, lines, and objects from the current input port. Generators provide lightweight laziness.

This SRFI also defines procedures that return accumulators. An accumulator is the inverse of a generator: it is a procedure of one argument that works as a sink of values.

• 157: Continuation marks, by Marc Nieper-WißkirchenFinal: 2018-01-29Keywords: Continuations

Continuation marks are a programming language feature that allows one to attach information to and retrieve information from continuations, generalizing stack inspection. Conceptually, a continuation consists of a number of frames where each frame stands for an active procedure call that is not a tail call. A continuation mark is then a key-value pair associated with a frame, with keys compared using eq?. At most one mark for a given key can be attached to a single frame.

Besides stack inspection, continuation marks can be used to implement dynamic scope, delimited continuations, or delayed evaluation that is able to handle iterative lazy algorithms.

This SRFI proposes to add continuation marks to the Scheme programming language. The interface defined here is modelled after Racket's continuation marks. It does not include all forms and procedures provided by Racket but provides a compatible subset.

• 156: Syntactic combiners for binary predicates, by Panicz Maciej GodekFinal: 2017-12-18Keywords: Syntax

Recognizing binary predicates as a specific area in which the use of prefix operators is an impediment, we propose a thin layer of "syntactic stevia" for in-fixing such predicates. It can be implemented using regular Scheme macros. We suggest that the code (is x < y) should be transformed to (< x y), and (is x < y <= z) -- to (let ((y* y)) (and (< x y*) (<= y* z))). In addition, we suggest special meaning to the _ symbol: (is _ < y) and (is x < _) should be transformed to (lambda (_) (< _ y)) and (lambda (_) (< x _)), respectively. This SRFI document also describes some other uses of the is macro and its limitations.

• 155: Promises, by Marc Nieper-WißkirchenFinal: 2018-09-15Keywords: Data Structure, Lazy Evaluation

Scheme, like ML, is a programming language with strict evaluation while others, like Haskell, use lazy evaluation. Scheme, however, possesses the primitives delay and force that make it possible to express lazy algorithms.

Lazy evaluation does not go well in conjunction with imperative, non-functional, side-effecting code. It should, however, be applicable in a purely functional setting. This is the case for the delayed evaluation model as described in the R7RS as long as no dynamically bound variables, also known as parameter objects, are present. It is the purpose of this SRFI to rework the specification in the R7RS so that lazy evaluation works with purely functional code that makes use of dynamic environments or, more generally, the dynamic extent. This is done by remembering the dynamic extent in effect when the delay expression is evaluated.

Another perceived misfeature of the R7RS model of delayed evaluation is the apparent need of the delay-force special form to express iterative lazy algorithms. It is shown that the delay-force special form is unneeded and that the implementation can (and should) handle iterative lazy algorithms without space leaks.

• 154: First-class dynamic extents, by Marc Nieper-WißkirchenFinal: 2018-09-15Keywords: MiscellaneousSee also SRFI 157: Continuation marks.

Scheme has the notion of the dynamic extent of a procedure call. A number of standard Scheme procedures and syntaxes like dynamic-wind, call-with-current-continuation, and parameterize deal with the dynamic extent indirectly. The same holds true for the procedures and syntaxes dealing with continuation marks as defined by SRFI 157.

This SRFI reifies the dynamic extent into a first-class value together with a well-defined procedural interface and a syntax to create procedures that remember not only their environment at creation time but also their dynamic extent, which includes their dynamic environment.

• 153: Ordered Sets, by John CowanWithdrawn: 2018-07-08Keywords: Data Structure

Osets are immutable collections that can contain any Scheme object. Osets enforce the constraint that no two elements can be the same in the sense of the oset's associated equality predicate The elements in an oset appear in a fixed order determined by the comparator used to create it.

• 152: String Library (reduced), by John CowanFinal: 2017-10-04Keywords: Data Structure

Scheme has an impoverished set of string-processing utilities, which is a problem for authors of portable code. This SRFI proposes a coherent and comprehensive set of string-processing procedures. It is a reduced version of SRFI 13 that has been aligned with SRFI 135, Immutable Texts. Unlike SRFI 13, it has been made consistent with the R5RS, R6RS, and R7RS-small string procedures.

• 151: Bitwise Operations, by John CowanFinal: 2017-07-10See also SRFI 142: Bitwise Operations.

This SRFI proposes a coherent and comprehensive set of procedures for performing bitwise logical operations on integers; it is accompanied by a reference implementation of the spec in terms of a set of seven core operators. The sample implementation is portable, as efficient as practical with pure Scheme arithmetic (it is much more efficient to replace the core operators with C or assembly language if possible), and open source.

The precise semantics of these operators is almost never an issue. A consistent, portable set of names and parameter conventions, however, is. Hence this SRFI, which is based mainly on SRFI 33, with some changes and additions from Olin's late revisions to SRFI 33 (which were never consummated). SRFI 60 (based on SLIB) is smaller but has a few procedures of its own; some of its procedures have both native (often Common Lisp) and SRFI 33 names. They have been incorporated into this SRFI. R6RS is a subset of SRFI 60, except that all procedure names begin with a bitwise- prefix. A few procedures have been added from the general vector SRFI 133.

Among the applications of bitwise operations are: hashing, Galois-field calculations of error-detecting and error-correcting codes, cryptography and ciphers, pseudo-random number generation, register-transfer-level modeling of digital logic designs, Fast-Fourier transforms, packing and unpacking numbers in persistent data structures, space-filling curves with applications to dimension reduction and sparse multi-dimensional database indexes, and generating approximate seed values for root-finders and transcendental function algorithms.

This SRFI differs from SRFI 142 in only two ways:

1. The bitwise-if function has the argument ordering of SLIB, SRFI 60, and R6RS rather than the ordering of SRFI 33.

2. The order in which bits are processed by the procedures listed in the "Bits conversion" section has been clarified and some of the procedures' names have been changed. See "Bit processing order" for details.

• 150: Hygienic ERR5RS Record Syntax (reduced), by Marc Nieper-WißkirchenFinal: 2018-01-16Keywords: Data Structure

This SRFI provides a specification and portable implementation of an extension of the ERR5RS record syntax of SRFI 131, where field names inserted by macro transformers are effectively renamed as if the macro transformer inserted a binding. This makes this SRFI compatible with the semantics of the record-type definitions of the R7RS as intended by its authors. In addition, field names may also be other types of Scheme datums, like numbers and strings, or SRFI 88 keyword objects.

• 149: Basic Syntax-rules Template Extensions, by Marc Nieper-WißkirchenFinal: 2017-07-08Keywords: Syntax

The rules for valid <template>s of <syntax rules> are slightly softened to allow for more than one consecutive <ellipsis> in subtemplates, and to allow pattern variables in subtemplates to be followed by more instances of the identifier <ellipsis> than they are followed in the subpattern in which they occur.

• 148: Eager syntax-rules, by Marc Nieper-WißkirchenFinal: 2017-08-08Keywords: Syntax

Writing powerful syntax-rules macros is hard because they do not compose well: The arguments of a macro expansion are not expanded. This SRFI defines an easy to comprehend high-level system for writing powerful, composable (or eager) macros, two of whose defining features are that its macro arguments are (in general) eagerly expanded and that it can be portably implemented in any Scheme implementation conforming to the R7RS.

• 147: Custom macro transformers, by Marc Nieper-WißkirchenFinal: 2017-03-07Keywords: Syntax

Each syntax definition assigns a macro transformer to a keyword. The macro transformer is specified by a transformer spec, which is either an instance of syntax-rules, an existing syntactic keyword (including macro keywords and the syntactic keywords that introduce the core forms, like lambda, if, or define), or a use of a macro that eventually expands into an instance of syntax-rules. In the latter case, the keyword of macro use is called a custom macro transformer.

• 146: Mappings, by Arthur A. Gleckler and Marc Nieper-WißkirchenFinal: 2018-05-24

Mappings are finite sets of associations, where each association is a pair consisting of a key and an arbitrary Scheme value. The keys are elements of a suitable domain. Each mapping holds no more than one association with the same key. The fundamental mapping operation is retrieving the value of an association stored in the mapping when the key is given.

• 145: Assumptions, by Marc Nieper-WißkirchenFinal: 2017-03-31Keywords: Optimization

A means to denote the invalidity of certain code paths in a Scheme program is proposed. It allows Scheme code to turn the evaluation into a user-defined error that need not be signalled by the implementation. Optimizing compilers may use these denotations to produce better code and to issue better warnings about dead code.

• 144: Flonums, by John Cowan and Will ClingerFinal: 2017-07-17

This SRFI describes numeric procedures applicable to flonums, a subset of the inexact real numbers provided by a Scheme implementation. In most Schemes, the flonums and the inexact reals are the same. These procedures are semantically equivalent to the corresponding generic procedures, but allow more efficient implementations.

• 143: Fixnums, by John CowanFinal: 2017-05-27

This SRFI describes arithmetic procedures applicable to a limited range of exact integers only. These procedures are semantically similar to the corresponding generic-arithmetic procedures, but allow more efficient implementations.

• 142: Bitwise Operations, by John CowanWithdrawn: 2017-08-10Keywords: Data Structure, SupersededSee also SRFI 151: Bitwise Operations.

This SRFI proposes a coherent and comprehensive set of procedures for performing bitwise logical operations on integers; it is accompanied by a reference implementation of the spec in terms of a set of seven core operators. The sample implementation is portable, as efficient as practical with pure Scheme arithmetic (it is worthwhile replacing the core operators with C or assembly language if possible), and open source.

The precise semantics of these operators is almost never an issue. A consistent, portable set of names and parameter conventions, however, is. Hence this SRFI, which is based mainly on SRFI 33, with some changes and additions from Olin's late revisions to SRFI 33 (which were never consummated). SRFI 60 (based on SLIB) is smaller but has a few procedures of its own; some of its procedures have both native (often Common Lisp) and SRFI 33 names. They have been incorporated into this SRFI. R6RS is a subset of SRFI 60, except that all procedure names begin with a bitwise- prefix. A few procedures have been added from the general vector SRFI 133.

Among the applications of bitwise operations are: hashing, Galois-field calculations of error-detecting and error-correcting codes, cryptography and ciphers, pseudo-random number generation, register-transfer-level modeling of digital logic designs, Fast-Fourier transforms, packing and unpacking numbers in persistent data structures, space-filling curves with applications to dimension reduction and sparse multi-dimensional database indexes, and generating approximate seed values for root-finders and transcendental function algorithms.

• 141: Integer division, by Taylor Campbell and John CowanFinal: 2016-12-14

This SRFI provides a fairly complete set of integral division and remainder operators.

• 140: Immutable Strings, by Per BothnerFinal: 2017-05-24Keywords: Data Structure

This attempts to solve the same issues with R7RS strings raised by SRFI-135, but with better integration with the Scheme language.

We propose to retain the name string as the type of sequences of Unicode characters (scalar values). There are two standard subtypes of string:

• Immutable strings, also called istrings, cannot be modified after they have been created. Calling string-set! on an istring throws an error. On the other hand, the core operations string-ref and string-length are guaranteed to be O(1).
• Mutable strings can be modified in-place using string-set! and other operations. However, string-ref, string-set!, or string-length have no performance guarantees. On many implementation they may take time proportional to the length of the string.

An implementation may support other kinds of strings. For example on the Java platform it may be reasonable to consider any instance of java.lang.CharSequence to be a string.

The main part of the proposal specifies the default bindings of various procedure names, as might be pre-defined in a REPL. Specifically, some procedures that traditionally return mutable strings are changed to return istrings. We later discuss compatibility and other library issues.

This combines SRFI-13, SRFI-135, and SRFI-118.

• 139: Syntax parameters, by Marc Nieper-WißkirchenFinal: 2016-10-02Keywords: Binding, Parameters

Syntax parameters are to the expansion process of a Scheme program what parameters are to the evaluation process of a Scheme program. They allow hygienic implementation of syntactic forms that would otherwise introduce implicit identifiers unhygienically.

• 138: Compiling Scheme programs to executables, by Marc Nieper-WißkirchenFinal: 2016-09-28Keywords: Operating System

This SRFI describes, for sufficiently POSIX-compatible systems, a portable interface for compiling Scheme programs conforming to the R7RS to binaries that can be directly executed on the host system.

• 137: Minimal Unique Types, by John Cowan and Marc Nieper-WißkirchenFinal: 2016-10-04Keywords: Data Structure

This SRFI is intended to standardize a primitive run-time mechanism to create disjoint types.

• 136: Extensible record types, by Marc Nieper-WißkirchenFinal: 2016-12-25Keywords: Data Structure

SRFI 9 and the compatible R7RS-small provide Scheme with record types. The basic problem that is solved by these record types is that they allow the user to introduce new types, disjoint from all existing types. The record type system described in this document is a conservative extension to SRFI 9 and R7RS record types (in other words, the keyword define-record-type defined in this specification can serve as the equally named keyword from SRFI 9 and R7RS and can thus be safely exported from (srfi 9) and (scheme base)) that is intended to solve another fundamental problem, namely the introduction of subtypes.

• 135: Immutable Texts, by William D ClingerFinal: 2016-09-06

In Scheme, strings are a mutable data type. Although it "is an error" (R5RS and R7RS) to use string-set! on literal strings or on strings returned by symbol->string, and any attempt to do so "should raise an exception" (R6RS), all other strings are mutable.

Although many mutable strings are never actually mutated, the mere possibility of mutation complicates specifications of libraries that use strings, encourages precautionary copying of strings, and precludes structure sharing that could otherwise be used to make procedures such as substring and string-append faster and more space-efficient.

This SRFI specifies a new data type of immutable texts. It comes with efficient and portable sample implementations that guarantee O(1) indexing for both sequential and random access, even in systems whose string-ref procedure takes linear time.

The operations of this new data type include analogues for all of the non-mutating operations on strings specified by the R7RS and most of those specified by SRFI 130, but the immutability of texts and uniformity of character-based indexing simplify the specification of those operations while avoiding several inefficiencies associated with the mutability of Scheme's strings.

• 134: Immutable Deques, by Kevin Wortman and John CowanFinal: 2016-07-01

This SRFI defines immutable deques. A deque is a double-ended queue, a sequence which allows elements to be added or removed efficiently from either end. A structure is immutable when all its operations leave the structure unchanged. Note that none of the procedures specified here ends with an exclamation point.

• 133: Vector Library (R7RS-compatible), by John CowanBased on SRFI 43 by Taylor Campbell.Final: 2016-03-20

This SRFI proposes a comprehensive library of vector operations accompanied by a freely available and complete reference implementation. The reference implementation is unencumbered by copyright, and useable with no modifications on any Scheme system that is R5RS-compliant. It also provides several hooks for implementation-specific optimization as well.

• 132: Sort Libraries, by John CowanBased on SRFI 32 by Olin Shivers.Final: 2016-04-20Keywords: Algorithm, R7RS Large, R7RS Large: Red EditionSee also SRFI 32: Sort Libraries.

This SRFI describes the API for a full-featured sort toolkit.

• 131: ERR5RS Record Syntax (reduced), by John Cowan and Will ClingerFinal: 2016-02-13Keywords: Data Structure

This SRFI is a reduced version of the SRFI 99 syntactic layer that can be implemented with syntax-rules without requiring low-level macros. Like SRFI-99's syntax layer, it is backward compatible with the define-record-type macro from SRFI 9 or R7RS-small. It is forward compatible with SRFI 99.

• 130: Cursor-based string library, by John CowanFinal: 2016-05-28Keywords: Data StructureSee also SRFI 13: String Libraries.

R5RS Scheme has an impoverished set of string-processing utilities, which is a problem for authors of portable code. Although R7RS provides some extensions and improvements, it is still very incomplete. This SRFI proposes a coherent and comprehensive set of string-processing procedures; it is accompanied by a portable sample implementation of the spec.

This SRFI is derived from SRFI 13. The biggest difference is that it allows subsequences of strings to be specified by cursors as well as the traditional string indexes. In addition, it omits the comparison, case-mapping, and mutation operations of SRFI 13, as well as all procedures already present in R7RS.

• 129: Titlecase procedures, by John CowanFinal: 2016-03-08Keywords: Internationalization

This SRFI defines R7RS-style char-title-case?, char-titlecase, and string-titlecase procedures.

• 128: Comparators (reduced), by John CowanFinal: 2016-02-14Keywords: Comparison

This SRFI provides comparators, which bundle a type test predicate, an equality predicate, an ordering predicate, and a hash function (the last two are optional) into a single Scheme object. By packaging these procedures together, they can be treated as a single item for use in the implementation of data structures.

• 127: Lazy Sequences, by John CowanFinal: 2016-01-18

Lazy sequences (or lseqs, pronounced "ell-seeks") are a generalization of lists. In particular, an lseq is either a proper list or a dotted list whose last cdr is a SRFI 121 generator. A generator is a procedure that can be invoked with no arguments in order to lazily supply additional elements of the lseq. When a generator has no more elements to return, it returns an end-of-file object. Consequently, lazy sequences cannot reliably contain end-of-file objects.

This SRFI provides a set of procedures suitable for operating on lazy sequences based on SRFI 1.

• 126: R6RS-based hashtables, by Taylan Ulrich Bayırlı/KammerFinal: 2016-02-01Keywords: Data Structure

We provide a hashtable API that takes the R6RS hashtables API as a basis and makes backwards compatible additions such as support for weak hashtables, external representation, API support for double hashing implementations, and utility procedures.

• 125: Intermediate hash tables, by John Cowan and Will ClingerFinal: 2015-05-28

This SRFI defines an interface to hash tables, which are widely recognized as a fundamental data structure for a wide variety of applications. A hash table is a data structure that:

• Is disjoint from all other types.
• Provides a mapping from objects known as keys to corresponding objects known as values.
• Keys may be any Scheme objects in some kinds of hash tables, but are restricted in other kinds.
• Values may be any Scheme objects.
• Has no intrinsic order for the key-value associations it contains.
• Provides an equality predicate which defines when a proposed key is the same as an existing key. No table may contain more than one value for a given key.
• Provides a hash function which maps a candidate key into a non-negative exact integer.
• Supports mutation as the primary means of setting the contents of a table.
• Provides key lookup and destructive update in (expected) amortized constant time, provided a satisfactory hash function is available.
• Does not guarantee that whole-table operations work in the presence of concurrent mutation of the whole hash table (values may be safely mutated).
• 124: Ephemerons, by John CowanFinal: 2015-11-06

An ephemeron is an object with two components called its key and its datum. It differs from an ordinary pair as follows: if the garbage collector (GC) can prove that there are no references to the key except from the ephemeron itself and possibly from the datum, then it is free to break the ephemeron, dropping its reference to both key and datum. In other words, an ephemeron can be broken when nobody else cares about its key. Ephemerons can be used to construct weak vectors or lists and (possibly in combination with finalizers) weak hash tables.

Much of this specification is derived with thanks from the MIT Scheme Reference Manual.

• 123: Generic accessor and modifier operators, by Taylan Ulrich Bayırlı/KammerFinal: 2015-10-14Keywords: Miscellaneous

Lisp dialects including Scheme have traditionally lacked short, simple, generic syntax for accessing and modifying the fields of arbitrary "collection" objects. We fill this gap for Scheme by defining generalized accessors, and an associated SRFI-17 setter.

• 122: Nonempty Intervals and Generalized Arrays, by Bradley J. LucierFinal: 2016-12-24Keywords: Data Structure

This SRFI specifies an array mechanism for Scheme. Arrays as defined here are quite general; at their most basic, an array is simply a mapping, or function, from multi-indices of exact integers $i_0,\ldots,i_{d-1}$ to Scheme values. The set of multi-indices $i_0,\ldots,i_{d-1}$ that are valid for a given array form the domain of the array. In this SRFI, each array's domain consists of a rectangular interval $[l_0,u_0)\times[l_1,u_1)\times\cdots\times[l_{d-1},u_{d-1})$, a subset of $\mathbb Z^d$, $d$-tuples of integers. Thus, we introduce a data type called intervals, which encapsulate the cross product of nonempty intervals of exact integers. Specialized variants of arrays are specified to provide portable programs with efficient representations for common use cases.

• 121: Generators, by Shiro Kawai, John Cowan, and Thomas GilrayWithdrawn: 2019-07-18

This SRFI defines utility procedures that create, transform, and consume generators. A generator is simply a procedure with no arguments that works as a source of a series of values. Every time it is called, it yields a value. Generators may be finite or infinite; a finite generator returns an end-of-file object to indicate that it is exhausted. For example, read-char, read-line, and read are generators that generate characters, lines, and objects from the current input port. Generators provide lightweight laziness.

• 120: Timer APIs, by Takashi KatoFinal: 2015-08-06Keywords: Miscellaneous

This SRFI defines interfaces to handle timer processes.

• 119: wisp: simpler indentation-sensitive scheme, by Arne BabenhauserheideFinal: 2015-06-23Keywords: Reader Syntax

This SRFI describes a simple syntax which allows making scheme easier to read for newcomers while keeping the simplicity, generality and elegance of s-expressions. Similar to SRFI 110, SRFI 49 and Python it uses indentation to group expressions. Like SRFI 110 wisp is general and homoiconic.

Different from its predecessors, wisp only uses the absolute minimum of additional syntax-elements which are required for writing and exchanging arbitrary code-structures. As syntax elements it only uses a colon surrounded by whitespace, the period followed by whitespace as first code-character on the line and optional underscores followed by whitespace at the beginning of the line.

It resolves a limitation of SRFI 110 and SRFI 49, both of which force the programmer to use a single argument per line if the arguments to a procedure need to be continued after a procedure-call.

Wisp expressions can include arbitrary s-expressions and as such provide backwards compatibility.

wisp s-exp
define : factorial n
__  if : zero? n
____   . 1
____   * n : factorial (- n 1)

display : factorial 5
newline

(define (factorial n)
(if (zero? n)
1
(* n (factorial (- n 1)))))

(display (factorial 5))
(newline)

• 118: Simple adjustable-size strings, by Per BothnerFinal: 2015-07-07Keywords: Data Structure

Scheme specifies mutable fixed-length strings. We add two procedures string-append! and string-replace! which allow the size of the string to change. We also require that the standard Scheme procedures make-string and string-copy return variable-size strings.

• 117: Queues based on lists, by John CowanFinal: 2015-08-25

List queues are mutable ordered collections that can contain any Scheme object. Each list queue is based on an ordinary Scheme list containing the elements of the list queue by maintaining pointers to the first and last pairs of the list. It's cheap to add or remove elements from the front of the list or to add elements to the back, but not to remove elements from the back. List queues are disjoint from other types of Scheme objects.

• 116: Immutable List Library, by John CowanFinal: 2014-11-28

Scheme currently does not provide immutable pairs corresponding to its existing mutable pairs, although most uses of pairs do not exploit their mutability. The Racket system takes the radical approach of making Scheme's pairs immutable, and providing a minimal library of mutable pairs with procedures named mpair?, mcons, mcar, mcdr, set-mcar!, set-mcdr!. This SRFI takes the opposite approach of leaving Scheme's pairs unchanged and providing a full set of routines for creating and dealing with immutable pairs. The sample implementation is portable (to systems with SRFI 9) and efficient.

• 115: Scheme Regular Expressions, by Alex ShinnFinal: 2014-07-14

This SRFI provides a library for matching strings with regular expressions described using the SRE "Scheme Regular Expression" notation first introduced by SCSH, and extended heavily by IrRegex.

• 114: Comparators, by John CowanWithdrawn: 2017-08-10Keywords: Comparison, SupersededSee also SRFI 128: Comparators (reduced).

This proposal is a rewrite of SRFI 67, Compare Procedures, extending it from procedures that represent a total order to procedure bundles that represent one or more of a total order, an equality predicate, and a hash function. By packaging these procedures together, along with a type test predicate, they can be treated as a single item for use in the implementation of data structures.

• 113: Sets and bags, by John CowanFinal: 2014-11-28

Sets and bags (also known as multisets) are unordered collections that can contain any Scheme object. Sets enforce the constraint that no two elements can be the same in the sense of the set's associated equality predicate; bags do not.

• 112: Environment Inquiry, by John CowanFinal: 2013-09-12Keywords: Operating System

This is a proposal for environment inquiry, providing human-readable information at run time about the hardware and software configuration on which a Scheme program is being executed. They are mostly based on Common Lisp, with additions from the Posix uname() system call.

• 111: Boxes, by John CowanFinal: 2013-07-03

Boxes are objects with a single mutable state. Several Schemes have them, sometimes called cells. A constructor, predicate, accessor, and mutator are provided.

• 110: Sweet-expressions (t-expressions), by David A. Wheeler and Alan Manuel K. GloriaFinal: 2013-09-09Keywords: Reader Syntax

This SRFI describes a set of syntax extensions for Scheme, called sweet-expressions (t-expressions), that has the same descriptive power as s-expressions but is designed to be easier for humans to read. The sweet-expression syntax enables the use of syntactically-meaningful indentation to group expressions (similar to Python), and it builds on the infix and traditional function notation defined in SRFI-105 (curly-infix-expressions). Unlike nearly all past efforts to improve s-expression readability, sweet-expressions are general (the notation is independent from any underlying semantic) and homoiconic (the underlying data structure is clear from the syntax). This notation was developed by the “Readable Lisp S-expressions Project” and can be used for both programs and data.

Sweet-expressions can be considered a set of additional abbreviations, just as 'x already abbreviates (quote x). Sweet-expressions and traditionally formatted s-expressions can be freely mixed; this provides backwards compatibility, simplifies transition, and enables developers to maximize readability. Here is an example of a sweet-expression and its equivalent s-expression (note that a sweet-expression reader would accept either format):

sweet-expression s-expression
define fibfast(n)   ; Typical function notation
if {n < 2}        ; Indentation, infix {...}
n              ; Single expr = no new list
fibup n 2 1 0  ; Simple function calls

(define (fibfast n)
(if (< n 2)
n
(fibup n 2 1 0)))

• 109: Extended string quasi-literals, by Per BothnerFinal: 2013-06-21Keywords: Reader Syntax

This specifies a reader extension for extended string quasi-literals, including nicer multi-line strings, and enclosed unquoted expressions.

This proposal is related to SRFI-108 (named quasi-literal constructors) and SRFI-107 (XML reader syntax), as they share quite a bit of syntax.

• 108: Named quasi-literal constructors, by Per BothnerFinal: 2013-06-21Keywords: Reader Syntax

This specifies an extensible reader syntax for named value constructors. A reader prefix is followed by a tag (an identifier), and then expressions and literal text parameters. The tag can be though of as a class name, and the expression and literal text are arguments to an object constructor call. The reader translates &tag{...} to a list ($construct$:tag ...), where $construct$:tag is normally bound to a predefined macro.

This propsal depends on SRFI-109 (extended string quasi-literals) (in spite of having a lower number). It also shares quite of bit of syntax with SRFI-107 (XML reader syntax).

We specify a reader extension that reads data in a superset of XML/HTML format, and produces conventional S-expressions. We also suggest a possible semantics interpretation of how these forms may be evaluated to produce XML-node values, but this is non-normative.

• 106: Basic socket interface, by Takashi KatoFinal: 2013-08-20Keywords: I/O

This document specifies basic socket interfaces.

• 105: Curly-infix-expressions, by David A. Wheeler and Alan Manuel K. GloriaFinal: 2012-11-06Keywords: Reader Syntax

Lisp-based languages, like Scheme, are almost the only programming languages in modern use that do not support infix notation. In addition, most languages allow infix expressions to be combined with function call notation of the form f(x). This SRFI provides these capabilities, both for developers who already use Scheme and want these conveniences, and also for other developers who may choose to use other languages in part because they miss these conveniences. Scheme currently reserves {...} “for possible future extensions to the language”. We propose that {...} be used to support “curly-infix-expression” notation as a homoiconic infix abbreviation, as a modification of the Scheme reader. It is an abbreviation in much the same way that 'x is an abbreviation for (quote x).

A curly-infix list introduces a list whose visual presentation can be in infix order instead of prefix order. For example, {n > 5}(> n 5), and {a + b + c}(+ a b c). By intent, there is no precedence, but e.g., {x + {y * z}} maps cleanly to (+ x (* y z)). Forms with mixed infix operators and other complications have “$nfx$” prepended to enable later processing, e.g., {4 + 5 * 6}($nfx$ 4 + 5 * 6). Also, inside a curly-infix list (recursively), expressions of the form f(...) are simply an abbreviation for (f ...).

Note that this is derived from the “readable” project. We intend to later submit at least one additional SRFI that will build on top of this SRFI, but curly-infix-expressions are useful on their own.

• 104: Library Files Utilities, by Derick EddingtonWithdrawn: 2010-05-23Keywords: Operating System

This SRFI implements SRFI 103: Library Files as a library. It is useful for working with library files.

• 103: Library Files, by Derick EddingtonWithdrawn: 2013-05-08Keywords: Operating System

This SRFI defines a standard for locating files containing libraries with list-of-symbols library names, for unixes and Windows. It defines a standard for files containing R6RS libraries. It supports different Scheme dialects.

• 102: Procedure Arity Inspection, by David Van HornWithdrawn: 2013-02-24Keywords: Introspection

Many Scheme systems provide mechanisms for inspecting the arity of a procedural value, making it a common feature, however there is no standard interface. As a result there is no portable way to observe the arity of a procedure without actually applying it. This SRFI proposes a simple interface that is consistent with existing Scheme systems' facilities and prior proposals.

• 101: Purely Functional Random-Access Pairs and Lists, by David Van HornFinal: 2013-02-24

Random-access lists [1] are a purely functional data structure for representing lists of values. A random-access list may act as a drop in replacement for the usual linear-access pair and list data structures (pair?, cons, car, cdr), which additionally supports fast index-based addressing and updating (list-ref, list-set). The impact is a whole class of purely-functional algorithms expressed in terms of index-based list addressing become feasible compared with their linear-access list counterparts.

This document proposes a library API for purely functional random-access lists consistent with the R6RS [2] base library and list utility standard library [3].

• 100: define-lambda-object, by Joo ChurlSooFinal: 2010-06-21Keywords: Data Structure

This SRFI introduces a macro, DEFINE-LAMBDA-OBJECT which defines a set of procedures, that is, a group, two constructors, and a predicate. The constructors also make a group of procedures, namely lambda objects. The macro extends DEFINE-RECORD-TYPE (SRFI 9) in being more general but much less general than DEFCLASS (CLOS). The macro has no explicit field accessors and mutators but parent groups, required fields, optional fields, automatic fields, read-write fields, read-only fields, inaccessible hidden fields, immutable virtual fields, and common sharing fields.

• 99: ERR5RS Records, by William D ClingerFinal: 2009-10-07Keywords: Data Structure

Many Scheme programmers have considered records to be one of the most important features missing from the R5RS. The R6RS proposed a record system, but its design has been widely criticized and it was not intended for use in R5RS programs anyway.

This SRFI proposes a better record system for use in R5RS, ERR5RS, and R6RS programs. The syntactic layer of this SRFI's record system is an extension of SRFI 9. The procedural and inspection layers of this SRFI's record system are perfectly compatible with its syntactic layer. This entire SRFI is compatible with the procedural and inspection layers of the R6RS record system, but offers several worthwhile improvements over the R6RS system.

• 98: An interface to access environment variables, by Taro Minowa (Higepon)Final: 2008-09-19Keywords: Operating System

This SRFI specifies the procedure get-environment-variable, which gets the value of the specified environment variable, and the procedure get-environment-variables, which gets an association list of all environment variables.

• 97: SRFI Libraries, by David Van HornFinal: 2008-12-22Keywords: Modules

Over the past ten years, numerous libraries have been specified via the Scheme Requests for Implementation process. Yet until the recent ratification of the Revised6 Report on the Algorithmic Language Scheme, there has been no standardized way of distributing or relying upon library code. Now that such a library system exists, there is a real need to organize these existing SRFI libraries so that they can be portably referenced.

This SRFI is designed to facilitate the writing and distribution of code that relies on SRFI libraries. It identifies a subset of existing SRFIs that specify features amenable to provision (and possibly implementation) as libraries (SRFI Libraries) and proposes a naming convention for this subset so that these libraries may be referred to by name or by number.

• 96: SLIB Prerequisites, by Aubrey JafferFinal: 2008-07-07Keywords: Features

This SRFI specifies a set of procedures and macros presenting a uniform interface sufficient to host the SLIB Scheme Library system.

• 95: Sorting and Merging, by Aubrey JafferFinal: 2007-01-29Keywords: Algorithm

Sorting and Merging are useful operations deserving a common API.

• 94: Type-Restricted Numerical Functions, by Aubrey JafferFinal: 2007-01-30Keywords: Arithmetic

In the coding of numerial calculations in latent-typed languages it is good practice to assure that those calculations are using the intended number system. The most common number systems for programmatic calculations are the integers, reals, and complexes. This SRFI introduces 14 real-only and 3 integer-only variants of R5RS procedures to facilitate numerical type checking and declaration.

• 93: R6RS Syntax-Case Macros, by Kent DybvigWithdrawn: 2006-08-23Keywords: Syntax, R6RS process

The syntactic abstraction system described here extends the R5RS macro system with support for writing low-level macros in a high-level style, with automatic syntax checking, input destructuring, output restructuring, maintenance of lexical scoping and referential transparency (hygiene), and support for controlled identifier capture, with constant expansion overhead. Because it does not require literals, including quoted lists or vectors, to be copied or even traversed, it preserves sharing and cycles within and among the constants of a program. It also supports source-object correlation, i.e., the maintenance of ties between the original source code and expanded output, allowing implementations to provide source-level support for debuggers and other tools.

• 92: ALAMBDA and ALAMBDA*, by Joo ChurlSooWithdrawn: 2007-04-09Keywords: Miscellaneous, Type Checking

This SRFI introduces ALAMBDA and ALAMBDA*, each of which has two modes of operation:

1. it creates a procedure that checks actual arguments and takes optional arguments,
2. it returns a different procedure by checking each of actual arguments and the number of them.
• 91: Extended ports, by Marc FeeleyWithdrawn: 2007-07-10Keywords: I/O

This SRFI specifies an extension to the R5RS ports that supports several useful features: binary I/O and text I/O, bulk I/O, file opening attributes, and bidirectional ports. Binary I/O is provided through byte ports which are ports whose fundamental I/O unit is an 8 bit byte. Because characters can be encoded with bytes using a character encoding such as ISO 8859-1, UTF-8, and UTF-16BE, any byte port is also a character port (a port that supports the character level I/O of R5RS). A byte port's character encoding and various other attributes are specified when the port is opened. Because reasonable defaults exist, these attributes are specified using a named optional parameter syntax. All procedures which have the same name as in R5RS are compatible with R5RS but may provide additional functionality.

• 90: Extensible hash table constructor, by Marc FeeleyFinal: 2007-07-10Keywords: Data Structure

This SRFI specifies the procedure make-table, a hash table constructor compatible with SRFI 69 (Basic hash tables). The procedure make-table allows various parameters of the hash table to be specified with optional named parameters when it is constructed. These parameters are: the initial size, the minimum and maximum load factor, the key equivalence function, the key hashing function, whether the references to the keys are weak, and similarly for the values. By using optional named parameters, as specified in SRFI 89 (Optional positional and named parameters), the constructor's API can be easily extended in a backward compatible way by other SRFIs and Scheme implementations.

• 89: Optional positional and named parameters, by Marc FeeleyFinal: 2007-07-10Keywords: Binding

This SRFI specifies the define* and lambda* special forms. These forms extend the R5RS define and lambda special forms to simplify the use of optional positional and named parameters. Optional positional parameters, optional named parameters and required named parameters are covered by this SRFI. The formal parameter list syntax specified in this SRFI is different from the syntax used by Common Lisp and the DSSSL languages but nevertheless offers similar functionality and a nicer syntax. Formal parameter lists which conform to the R5RS syntax have the same meaning as in R5RS.

• 88: Keyword objects, by Marc FeeleyFinal: 2007-07-03Keywords: Reader Syntax

This SRFI defines keyword objects, a data type similar to Scheme symbols. Keyword objects have the same lexical syntax as symbols but they must end in a colon. Moreover keyword objects are self-evaluating. Procedures for converting between strings and keyword objects (string->keyword and keyword->string) and a type predicate (keyword?) are defined. Finally this SRFI specifies the changes to the Scheme lexical syntax required to accomodate keywords.

• 87: => in case clauses, by Chongkai ZhuFinal: 2006-10-18Keywords: Control Flow

This SRFI proposes an extension to the case syntax to allow the => clauses as in cond.

• 86: MU and NU simulating VALUES & CALL-WITH-VALUES, and their related LET-syntax, by Joo ChurlSooFinal: 2006-06-20Keywords: Data Structure, Multiple Value Returns

Unlike the values/call-with-values mechanism of R5RS, this SRFI uses an explicit representation for multiple return values as a single value, namely a procedure. Decomposition of multiple values is done by simple application. Each of the two macros, mu and nu, evaluates to a procedure that takes one procedure argument. The mu and nu can be compared with lambda. While lambda expression that consists of <formals> and <body> requires some actual arguments later when the evaluated lambda expression is called, mu and nu expressions that consist of <expression>s corresponding to actual arguments of lambda require <formals> and <body>, that is, an evaluated lambda expression, later when the evaluated mu and nu expressions are called.

This SRFI also introduces new let-syntax depending on mu and nu to manipulate multiple values, alet and alet* that are compatible with let and let* of R5RS in single value bindings. They also have a binding form making use of values and call-with-values to handle multiple values. In addition, they have several new binding forms for useful functions such as escape, recursion, etc.

• 85: Recursive Equivalence Predicates, by William D ClingerWithdrawn: 2006-10-21Keywords: Comparison

This SRFI defines two related equivalence predicates that are recursive, not just partial recursive: they terminate on all arguments. One of these predicates, equiv?, is consistent with the equal? procedure described in the R5RS: Whenever equal? terminates, equiv? returns the same value as equal?.

• 84: Universal Identifiers, by Andrew WilcoxWithdrawn: 2006-11-09Keywords: Data Structure

This SRFI proposes a social convention to allow programmers to easily create short, simple Scheme symbols which are guaranteed to be universally unique: No other programmer also following this SRFI will accidentally create a symbol eq? to yours.

Universally unique symbols are useful to identify standards, languages, libraries, types, classes, and other resources.

• 83: R6RS Library Syntax, by Matthew Flatt and Kent DybvigWithdrawn: 2006-09-13Keywords: Modules, R6RS process

The module system presented here is designed to let programmers share libraries, i.e., code that is intended to be incorporated into larger programs, and especially into programs that use library code from multiple sources. The module system supports macro definitions within modules, allows macro exports, and distinguishes the phases in which definitions and imports are needed. This SRFI defines a standard notation for libraries, a semantics for library expansion and execution, and a simple format for sharing libraries.

• 82: Stream Ports, by Michael SperberWithdrawn: 2006-11-20Keywords: I/O

This SRFI augments SRFI 81 (Port I/O) by allowing ports to be constructed from streams as described in SRFI 80 (Stream I/O).

• 81: Port I/O, by Michael SperberWithdrawn: 2006-11-20Keywords: I/O

This SRFI defines an I/O layer similar in nature to the ports subsystem in R5RS, and provides conventional, imperative buffered input and output.

The layer architecture is similar to the upper three layers of the I/O subsystem in The Standard ML Basis Library.

In particular, the subsystem fulfills the following requirements:

• binary and text I/O, mixed if needed
• the ability to create arbitrary I/O ports from readers and writers

It builds on the Primitive I/O layer specified in SRFI 79 (Primitive I/O).

• 80: Stream I/O, by Michael SperberWithdrawn: 2006-11-20Keywords: I/O

This SRFI defines an I/O layer for lazy, mostly functional buffered streams.

The layer architecture is similar to the upper three layers of the I/O subsystem in The Standard ML Basis Library.

In particular, this layer provides

• dynamic redirection of input or output
• binary and text I/O, mixed if needed
• translated data streams
• the ability to create I/O streams from arbitrary readers and writers

It builds on the Primitive I/O layer specified in SRFI 79 (Primitive I/O).

• 79: Primitive I/O, by Michael SperberWithdrawn: 2006-11-16Keywords: I/OSee also SRFI 181: Custom ports.

This SRFI defines a simple, primitive I/O subsystem for Scheme that is intended to function as the lowest layer of a more comprehensive suite of I/O layers. It provides unbuffered I/O, and is close to what a typical operating system offers. Thus, its interface is suitable for implementing high-throughput and zero-copy I/O.

The Primitive I/O layer also allows clients to implement custom data sources and sinks via a simple interface.

Moreover, this SRFI defines a condition hierarchy specifying common I/O-related exceptional situations.

The Primitive I/O layer only handles blocking-I/O. Non-blocking and selective I/O is left for another SRFI.

This I/O layer was designed in conjunction with two other layers that can be built on top of it: SRFI 80 (Stream I/O) and SRFI 81 (Port I/O).

• 78: Lightweight testing, by Sebastian EgnerFinal: 2006-03-06Keywords: Testing

A simple mechanism is defined for testing Scheme programs. As a most primitive example, the expression

(check (+ 1 1) => 3)

evaluates the expression (+ 1 1) and compares the result with the expected result 3 provided after the syntactic keyword =>. Then the outcome of this comparison is reported in human-readable form by printing a message of the form
(+ 1 1) => 2 ; *** failed ***
; expected result: 3

Moreover, the outcome of any executed check is recorded in a global state counting the number of correct and failed checks and storing the first failed check. At the end of a file, or at any other point, the user can print a summary using check-report.

In addition to the simple test above, it is also possible to execute a parametric sequence of checks. Syntactically, this takes the form of an eager comprehension in the sense of SRFI 42 [5]. For example,

(check-ec (:range e 100)
(:let x (expt 2.0 e))
(= (+ x 1) x) => #f (e x))

This statement runs the variable e through {0..99} and for each binding defines x as (expt 2.0 e). Then it is checked if (+ x 1) is equal to x, and it is expected that this is not the case (i.e. expected value is #f). The trailing (e x) tells the reporting mechanism to print the values of both e and x in case of a failed check. The output could look like this:
(let ((e 53) (x 9007199254740992.0)) (= (+ x 1) x)) => #t ; *** failed ***
; expected result: #f

The specification of bindings to report, (e x) in the example, is optional but very informative. Other features of this SRFI are:
• A way to specify a different equality predicate (default is equal?).
• Controlling the amount of reporting being printed.
• Switching off the execution and reporting of checks entriely.
• Retrieving a boolean if all checks have been executed and passed.
• 77: Preliminary Proposal for R6RS Arithmetic, by William D Clinger and Michael SperberWithdrawn: 2006-09-13Keywords: Arithmetic, R6RS process

Scheme's arithmetic system was designed to allow a wide variety of implementations. After many years of implementation experience, however, most implementations now fall into a small number of categories, and the benefits of continued experimentation no longer justify the confusion and portability problems that have resulted from giving implementations so much freedom in this area. Moreover, the R5RS generic arithmetic is difficult to implement as efficiently as purely fixnum or purely flonum arithmetic. (Fixnum arithmetic is typically limited-precision integer arithmetic implemented using one or more representations that may be especially efficient on the executing machine; flonum arithmetic is typically limited-precision floating-point arithmetic using one or more representations that may be especially efficient on the executing machine.)

This SRFI is an effort to extend and clarify the R5RS arithmetic to make it more portable, more comprehensive, and enable faster programs.

Furthermore, one of us (Sperber) has argued that Scheme's arithmetic requires radical overhaul. The other (Clinger) agrees that revisions are needed. Whether these revisions qualify as radical is best left to the judgement of individual readers.

This SRFI proposes to revise section 6.2 ("Numbers") of R5RS by:

• requiring a Scheme implementation to provide the full tower, including exact rationals of arbitrary precision, exact rectangular complex numbers with rational real and imaginary parts, and inexact real and complex arithmetic
• defining fixnum arithmetic (parameterized by precision)
• defining flonum arithmetic (inexactly)
• defining new procedures for performing exact arithmetic
• defining new procedures for performing inexact arithmetic
• describing the external representation and semantics of 0.0, -0.0, infinities and NaNs for systems that implement inexact real arithmetic using IEEE binary floating point<?
• changing the specification of eqv? to behave more sensibly with inexact numbers
• defining Scheme's real numbers to be the complex numbers whose imaginary part is an exact zero
• adding an external representation for inexact numbers that expresses the precision of a binary floating point representation
• defining procedures for some new operations, including integer division and remainder on real numbers, and bitwise operations,
• restricting the domains of some R5RS procedures
• clarifying the semantics of some R5RS procedures
• possibly changing the semantics of some R5RS procedures
• 76: R6RS Records, by Will Clinger, R. Kent Dybvig, Michael Sperber, and Anton van StraatenWithdrawn: 2006-04-24Keywords: Data Structure, R6RS process

This SRFI describes abstractions for creating new data types representing records - data structures with named fields. This SRFI comes in four parts:

• a procedural layer for creating and manipulating record types and record instances
• an explicit-naming syntactic layer for defining the various entities associated with a record type - construction procedure, predicate, field accessors, mutators, etc. - at once
• an implicit-naming syntactic layer built on top of the explicit-naming syntactic layer, which chooses the names for the various products based on the names of the record type and fields
• a set of reflection procedures
• 75: R6RS Unicode data, by Matthew Flatt and Marc FeeleyWithdrawn: 2006-05-27Keywords: Internationalization, R6RS process

Unicode is a widespread universal character code that supports most of the world's (natural) languages. The extensions to Scheme specified in this SRFI concern the support of Unicode in Scheme's character, string, and symbol datatypes. This SRFI does not (fully) specify how I/O of Unicode data is performed or how Scheme source code is encoded in files; these aspects are left for other SRFIs to specify.

• 74: Octet-Addressed Binary Blocks, by Michael SperberFinal: 2005-12-15Keywords: Data Structure

This SRFI defines a set of procedures for creating, accessing, and manipulating octet-addressed blocks of binary data, in short, blobs. The SRFI provides access primitives for fixed-length integers of arbitrary size, with specified endianness, and a choice of unsigned and two's complement representations.

• 73: Exact Infinities, by Chongkai ZhuWithdrawn: 2005-11-30Keywords: Arithmetic

Many Scheme implementations support exact arbitrary-precision integer arithmetic as well as exact rational number computation. This SRFI extends the rational numbers of R5RS by adding two rational infinities (1/0, -1/0).

With infinities added to the number system we find that division by zero "works". It lets initialization of variables precede bounds checks and gives flexibility in placement of those checks.

• 72: Hygienic macros, by André van TonderFinal: 2005-09-21Keywords: Syntax

This SRFI describes a procedural macro proposal for Scheme with the following features:

• ### Improved hygiene:

We argue that conventional hygiene algorithms may lead to accidental variable capture errors in procedural macros. We propose an improved algorithm that avoids these problems.

• ### Reflective tower:

We specify a reflective tower of arbitrary height, and propose a refinement of lexical scoping that takes into account the phase of use of an identifier in determining its meaning.

• ### Syntax-case:

In the current proposal, the syntax-case form is expressible as a macro in terms of a simpler set of primitives and is specified as library syntax.

• ### Procedural interface:

The primitive interface for manipulating compound syntax objects consists of procedures rather than special forms. In particular, the traditional abstractions car, cdr, cons , ... can be used on syntactic data.

• ### Fast hygiene algorithm:

The reference implementation documents a fast imperative hygiene algorithm that is eager and linear in expression size.

• ### Capturing identifiers:

A primitive make-capturing-identifier is provided for intentional variable capture and for building expansion-time fluid binding constructs.

• 71: Extended LET-syntax for multiple values, by Sebastian EgnerFinal: 2005-08-12Keywords: Binding

This SRFI is a proposal for extending let, let*, and letrec for receiving multiple values. The syntactic extension is fully compatible with the existing syntax. It is the intention that single-value bindings, i.e. (let ((var expr)) ...), and multiple-value binding can be mixed freely and conveniently.

The most simple form of the new syntax is best explained by an example:

(define (quo-rem x y)
(values (quotient x y) (remainder x y)))

(define (quo x y)
(let ((q r (quo-rem x y)))
q))

The procedure quo-rem delivers two values to its continuation. These values are received as q and r in the let-expression of the procedure quo. In other words, the syntax of let is extended such that several variables can be specified---and these variables receive the values delivered by the expression (quo-rem x y).

The syntax of let is further extended to cases in which a rest argument receives the list of all residual values. Again by example,

(let (((values y1 y2 . y3+) (foo x)))
body)

In this example, values is a syntactic keyword indicating the presence of multiple values to be received, and y1, y2, and y3+, resp., are variables bound to the first value, the second value, and the list of the remaining values, resp., as produced by (foo x). The syntactic keyword values allows receiving all values as in (let (((values . xs) (foo x))) body). It also allows receiving no values at all as in (let (((values) (for-each foo list))) body).

A common application of binding multiple values is decomposing data structures into their components. This mechanism is illustrated in its most primitive form as follows: The procedure uncons (defined below) decomposes a pair x into its car and its cdr and delivers them as two values to its continuation. Then an extended let can receive these values:

(let ((car-x cdr-x (uncons x)))
(foo car-x cdr-x))

Of course, for pairs this method is probably neither faster nor clearer than using the procedures car and cdr. However, for data structures doing substantial work upon decomposition this is different: Extracting the element of highest priority from a priority queue, while at the same time constructing the residual queue, can both be more efficient and more convenient than doing both operations independently. In fact, the quo-rem example illustrates this point already as both quotient and remainder are probably computed by a common exact division algorithm. (And often caching is used to avoid executing this algorithm twice as often as needed.)

As the last feature of this SRFI, a mechanism is specified to store multiple values in heap-allocated data structures. For this purpose, values->list and values->vector construct a list (a vector, resp.) storing all values delivered by evaluating their argument expression. Note that these operations cannot be procedures.

• 70: Numbers, by Aubrey JafferFinal: 2005-09-11Keywords: Arithmetic, Data Structure

This SRFI proposes text to replace section 6.2 "Numbers" of R5RS in order to extend its capabilities, correct errors in its specification, make it more explicit about limitations of precision and magnitude, and improve portability between implementations. More specifically, this new text:

• incorporates an inexact real positive infinity and an inexact real negative infinity,
• extends number syntax to incorporate inexact real infinities,
• adapts Common-Lisp semantics for expt' and extends them to include inexact real infinities,
• corrects the description of sqrt',
• sharpens the distinction between exact and inexact numbers,
• removes a contradiction related to exactness,
• extends gcd' and lcm' to exact rational numbers,
• extends quotient', modulo', and remainder' to finite real numbers,
• clarifies the behavior of inexact->exact' applied to an exact argument,
• clarifies the behavior of exact->inexact' applied to an inexact argument,
• adds convenience procedures exact-round', exact-ceiling', exact-floor', and exact-truncate',
• 69: Basic hash tables, by Panu KalliokoskiFinal: 2005-09-14Keywords: Data Structure

This SRFI defines basic hash tables. Hash tables are widely recognised as a fundamental data structure for a wide variety of applications. A hash table is a data structure that:

1. provides a mapping from some set of keys to some set of values associated to those keys
2. has no intrinsic order for the (key, value) associations it contains
3. supports in-place modification as the primary means of setting the contents of a hash table
4. provides key lookup and destructive update in amortised constant time, provided that a good hash function is used.

This SRFI aims to accomplish these goals:

1. to provide a consistent, generic and widely applicable API for hash tables
2. to improve code portability by providing a standard hash table facility with guaranteed behaviour
3. to help the programmer by defining utility routines that account for the most common situations of using hash tables.
• 68: Comprehensive I/O, by Michael SperberWithdrawn: 2005-11-29Keywords: I/O

This SRFI defines a comprehensive I/O subsystem for Scheme with three layers, where each layer is built on top of the one below it:

• The lowest, primitive layer provides unbuffered I/O, and is close to what a typical operating system offers.
• The middle layer builds on lazy, mostly functional buffered streams.
• The upper layer is similar in nature to the ports subsystem in R5RS, and provides conventional, imperative buffered input and output.

The layer architecture is similar to the upper three layers of the I/O subsystem in The Standard ML Basis Library.

In particular, the subsystem provides

• arbitrary lookahead at the streams level
• dynamic redirection of input or output at the ports level
• binary and text I/O, mixed if needed
• translated data streams
• unbuffered I/O at the primitive layer
• the ability to create arbitrary I/O streams, such as to and from blobs and strings

The subsystem does not provide

• formatted I/O
• non-blocking or selective I/O
• portable filenames, or any functionality for manipulating filenames
• filesystem operations
• socket I/O
• extremely high-throughput or zero-copy I/O

However, all of these could be added on top of one or several of the layers specified in this SRFI.

• 67: Compare Procedures, by Sebastian Egner and Jens Axel SøgaardFinal: 2005-09-11Keywords: Comparison

This SRFI can be seen as an extension of the standard procedures =, <, char<? etc. of R5RS -- or even as a replacement. The primary design aspect in this SRFI is the separation of representing a total order and using it. For representing the order, we have chosen for truly 3-way comparisons. For using it we provide an extensive set of operations, each of which accepts a procedure used for comparison. Since these compare procedures are often optional, comparing built-in types is as convenient as R5RS , sometimes more convenient: For example, testing if the integer index i lies in the integer range {0, ..., n - 1} can be written as (<=/<? 0 i n), implicitly invoking default-compare.

As soon as new total orders are required, the infrastructure provided by this SRFI is far more convenient and often even more efficient than building each total order from scratch.

Moreover, in case Scheme users and implementors find this mechanism useful and adopt it, the benefit of having a uniform interface to total orders to be used in data structures will manifest itself. Most concretely, a new sorting procedure in the spirit of this SRFI would have the interface (my-sort [ compare ] xs), using default-compare if the optional compare was not provided. Then my-sort could be defined using the entire infrastructure of this SRFI: Efficient 2- and 3-way branching, testing for chains and pairwise inequality, min/max, and general order statistics.

• 66: Octet Vectors, by Michael SperberFinal: 2005-12-15Keywords: Data Structure

This SRFI defines a set of procedures for creating, accessing, and manipulating uniform vectors of octets.

• 65: define-immutable: A Syntax to Define Identifiers With Immutable Values, by Andrew WilcoxWithdrawn: 2005-05-17Keywords: Binding, Lazy Evaluation

The define-immutable form defines an identifier whose value never changes.

The expression part of the definition is evaluated lazily: it is not evaluated unless and until the identifier is evaluated. This permits an immutable definition to use other definitions in more ways than is possible when using define in internal definitions.

A series of immutable definitions have simple semantics, making them easy to program and understand.

(let ()
(define-immutable x (+ z 5))
(define-immutable y (/ 100 4))
(lambda (x)
(+ n x)))
x)
=>
40

• 64: A Scheme API for test suites, by Per BothnerFinal: 2006-06-18Keywords: Testing

This defines an API for writing test suites, to make it easy to portably test Scheme APIs, libraries, applications, and implementations. A test suite is a collection of test cases that execute in the context of a test-runner. This specifications also supports writing new test-runners, to allow customization of reporting and processing the result of running test suites.

• 63: Homogeneous and Heterogeneous Arrays, by Aubrey JafferFinal: 2005-04-27Keywords: Data Structure

The SRFI, which is to supersede SRFI-47, "Array",

• synthesizes array concepts from Common-Lisp and Alan Bawden's "array.scm";
• incorporates all the uniform vector types from SFRI-4 "Homogeneous numeric vector datatypes";
• adds a boolean uniform array type;
• adds 16.bit and 128.bit floating-point uniform-array types;
• adds decimal floating-point uniform-array types; and
• adds array types of (dual) floating-point complex numbers.
Multi-dimensional arrays subsume homogeneous vectors as the one-dimensional case, obviating the need for SRFI-4.

SRFI-58 gives a read/write invariant syntax for the homogeneous and heterogeneous arrays described here.

This SRFI proposes a simple extension to Scheme's lexical syntax that allows individual S-expressions to be made into comments, ignored by the reader. This contrasts with the standard Lisp semicolon comments, which make the reader ignore the remainder of the line, and the slightly less common block comments, as SRFI 30 defines: both of these mechanisms comment out slices of text, not S-expressions.

• 61: A more general cond clause, by Taylor CampbellFinal: 2005-07-21Keywords: Binding, Control Flow

This SRFI proposes an extension to the cond syntax to allow a more general clause, one that allows binding the results of tests as in the => clauses and user-defined meaning of the success & failure of tests.

• 60: Integers as Bits, by Aubrey JafferFinal: 2005-03-08Keywords: Data Structure

Treating integers as two's-complement strings of bits is an arcane but important domain of computer science. It is used for:

• hashing;
• Galois-field[2] calculations of error-detecting and error-correcting codes;
• cryptography and ciphers;
• pseudo-random number generation;
• register-transfer-level modeling of digital logic designs;
• Fast-Fourier transforms;
• packing and unpacking numbers in persistant data structures;
• space-filling curves with applications to dimension reduction and sparse multi-dimensional database indexes; and
• generating approximate seed values for root-finders and transcendental function algorithms.
• 59: Vicinity, by Aubrey JafferFinal: 2005-03-08Keywords: I/O

A vicinity is a descriptor for a place in the file system. Vicinities hide from the programmer the concepts of host, volume, directory, and version. Vicinities express only the concept of a file environment where a file name can be resolved to a file in a system independent manner.

All of these procedures are file-system dependent. Use of these vicinity procedures can make programs file-system independent.

• 58: Array Notation, by Aubrey JafferFinal: 2005-03-08Keywords: Reader Syntax

SRFI-47 and its successor SRFI-63 provide both homogeneous numeric and heterogeneous multidimensional arrays which subsume Scheme vectors. The notation presented here builds upon Common-Lisp array syntax to represent heterogeneous arrays; and introduces a new Scheme-based notation for denoting homogeneous numeric arrays.

• 57: Records, by André van TonderFinal: 2005-03-07Keywords: Data Structure

We describe a syntax for defining record types. A predicate, constructor, and field accessors and modifiers may be specified for each record type. We also introduce a syntax for declaring record type schemes, representing families of record types that share a set of field labels. A polymorphic predicate and polymorphic field accessors and modifiers may be specified for each record type scheme. A syntax is provided for constructing records by field label, for in-place and for functional record update, and for composing records.

• 56: Binary I/O, by Alex ShinnWithdrawn: 2005-10-31Keywords: I/O

This SRFI extends Scheme with procedures to read and write binary data to and from ports, including utility procedures for writing various integer and floating point values in both big and little endian formats. Predicates are provided to test if binary I/O is allowed on a port, along with new procedures for creating such ports.

• 55: require-extension, by Felix L. Winkelmann and D.C. FrostFinal: 2004-11-05Keywords: Features

This SRFI specifies an extremely simple facility for making an extension or library available to a Scheme toplevel environment.

• 54: Formatting, by Joo ChurlSooFinal: 2004-06-24Keywords: I/O

This SRFI introduces the CAT procedure that converts any object to a string. It takes one object as the first argument and accepts a variable number of optional arguments, unlike the procedure called FORMAT.

• 53: Syntactic computations with computation-rules, by André van TonderWithdrawn: 2004-09-06Keywords: Syntax

This SRFI provides a portable framework for writing complex high-level macros that perform nontrivial computations during expansion.

• 52: Permitting and Supporting Extended Character Sets, by Thomas LordWithdrawn: 2004-06-17Keywords: Data Structure

This SRFI describes how to modify the Revised Report (R5RS) in order to enable conforming implementations to use an extended character set such as (but not limited to) Unicode.

Changes to some requirements of the report are recommended. Currently, the Revised Report contains requirements which are difficult or impossible to satisfy with some extended character sets.

New required procedures are proposed, specified, and included in the reference implementation. These procedures enable portable Scheme programs to manipulate Scheme source texts and source data accurately, even in implementations using extended character sets.

This SRFI concludes with some suggestions for implementors interested in providing good Unicode support, using these suggestions to illustrate how the proposed changes to the Revised Report can "play out" in Unicode-based Scheme.

This SRFI does not attempt to provide a comprehensive library for global text processing. For example, one issue in global text processing is the need for linguistically-sensitive, locale-sensitive procedures for sorting strings. Such procedures are beyond the scope of this SRFI. On the other hand, by making Scheme compatible with extended character sets, this SRFI is a step in the direction of permitting global text processing standard libraries to be developed in a form portable across all conforming implementations.

This SRFI does not propose that implementations be required to support Unicode or any other extended character set. It does not specify a representation for Unicode characters or strings. It does revise the specifications of the report so that char? values may be Unicode (or other) characters.

The reference implementation included should prove to be easily ported to and effective for all ASCII-only implementations and for many implementations using an 8-bit character set which is an extension of ASCII (it will require very minor modifications for each particular implementation). Other implementations may need to use a different implementation.

• 51: Handling rest list, by Joo ChurlSooFinal: 2004-06-07Keywords: Multiple Value Returns

This SRFI introduces the rest-values procedure which has three modes of operation:

1. it processes a rest list after checking its elements with default values or predicate procedures,
2. it processes a rest list with default values without checking its elements,
3. it processes a default list whose elements are lists or pairs, after checking their elements that are default values or predicate procedures with the elements of a rest list,

and eight macros which additionally check the rest arguments that are returned by rest-values.

• 50: Mixing Scheme and C, by Richard Kelsey and Michael SperberWithdrawn: 2005-12-20Keywords: Operating System

This SRFI describes an interface for calling C functions from Scheme, calling Scheme functions from C, and allocating storage in the Scheme heap. Scheme manages stub functions in C that negotiate between the calling conventions of Scheme and C and the memory allocation policies of both worlds.

The following facilities are available for interfacing between Scheme and C:

• Scheme code can call C functions.
• The external interface provides full introspection for all Scheme objects. External code may inspect, modify, and allocate Scheme objects arbitrarily.
• External code may signal errors to the Scheme system.
• External code may call back into Scheme. Scheme correctly unrolls the process stack on non-local exits.
• External modules may register bindings of names to values with a central registry accessible from Scheme. Conversely, Scheme code can register shared bindings for access by C code.

The interface is closely based on that of Scheme 48 and scsh.

• 49: Indentation-sensitive syntax, by Egil MöllerFinal: 2005-07-22Keywords: Reader Syntax

This SRFI descibes a new syntax for Scheme, called I-expressions, whith equal descriptive power as S-expressions. The syntax uses indentation to group expressions, and has no special cases for semantic constructs of the language. It can be used both for program and data input.

It also allows mixing S-expressions and I-expressions freely, giving the programmer the ability to layout the code as to maximize readability.

• 48: Intermediate Format Strings, by Ken DickeyFinal: 2004-03-02Keywords: I/O

This document specifies Format Strings, a method of interpreting a Scheme string which contains a number of format directives that are replaced with other string data according to the semantics of each directive. This SRFI extends SRFI-28 in being more generally useful but is less general than advanced format strings in that it does not allow, aside from ~F, for controlled positioning of text within fields.

• 47: Array, by Aubrey JafferFinal: 2004-06-14Keywords: Data Structure

"slib/array.scm" synthesizes array ideas from Common-Lisp and Alan Bawden with homogeneous vector ideas from SRFI-4 and SCM. The result portably integrates homogeneous and heterogeneous arrays into Scheme.

• 46: Basic Syntax-rules Extensions, by Taylor CampbellFinal: 2005-02-28Keywords: Syntax

This SRFI proposes two extensions to the R5RS1 syntax-rules pattern language: the first allows syntax-rules macros to generate macros, where the macro-generated macros use ellipsis that is not used by the macro-generating macros; the second allows for 'tail patterns.'

• 45: Primitives for Expressing Iterative Lazy Algorithms, by André van TonderFinal: 2004-04-05Keywords: Data StructureSee also SRFI 155: Promises.

Lazy evaluation is traditionally simulated in Scheme using delay and force. However, these primitives are not powerful enough to express a large class of lazy algorithms that are iterative. Indeed, it is folklore in the Scheme community that typical iterative lazy algorithms written using delay and force will often require unbounded memory.

Although varous modifications of delay and force had been proposed to resolve this problem (see e.g., the SRFI-40 discussion list) they all fail some of the benchmarks provided below. To our knowledge, the current SRFI provides the first exhaustive solution to this problem.

As motivation, we first explain how the usual laziness encoding using only delay and force will break the iterative behavior of typical algorithms that would have been properly tail-recursive in a true lazy language, causing the computation to require unbounded memory.

The problem is then resolved by introducing a set of three operations:

{lazy, delay, force}

which allow the programmer to succinctly express lazy algorithms while retaining bounded space behavior in cases that are properly tail-recursive. A general recipe for using these primitives is provided. An additional procedure {eager} is provided for the construction of eager promises in cases where efficiency is a concern.

Although this SRFI redefines delay and force, the extension is conservative in the sense that the semantics of the subset {delay, force} in isolation (i.e., as long as the program does not use lazy) agrees with that in R5RS. In other words, no program that uses the R5RS definitions of delay and force will break if those definition are replaced by the SRFI-45 definitions of delay and force.

• 44: Collections, by Scott G. MillerFinal: 2004-03-07Keywords: Data Structure

A Collections API which defines a common naming scheme and set of operations for creating, accessing, and manipulating common datastructures in Scheme. The API defines accessors, a common protocol for value access via generic and specific enumeration, and functions for inter-datastructure cooperation. Finally, a concrete specification of a compliant set of operators for the standard Scheme heterogenous datastructures (lists and vectors) and for the homogeneous Scheme string is provided.

• 43: Vector library, by Taylor CampbellFinal: 2004-10-26Keywords: Data Structure

This SRFI proposes a comprehensive and complete library of vector operations accompanied by a freely available and complete reference implementation. The reference implementation is unencumbered by copyright, and useable with no modifications on any Scheme system that is R5RS-compliant. It also provides several hooks for implementation-specific optimization as well.

Because this SRFI is more of a library or module specification than a request for additions to readers or any other internal implementation detail, in an implementation that supports a module or structure or package or library or unit (et cetera) systems, these procedures should be contained in a module / structure / package / library / unit called vector-lib.

• 42: Eager Comprehensions, by Sebastian EgnerFinal: 2003-07-07Keywords: Control Flow

This SRFI defines a modular and portable mechanism for eager comprehensions extending the algorithmic language Scheme [R5RS]. An eager comprehension is a convenient notation for one or more nested or parallel loops generating a sequence of values, and accumulating this sequence into a result.

• 41: Streams, by Philip L. BewigFinal: 2008-01-24See also SRFI 40: A Library of Streams.

Streams, sometimes called lazy lists, are a sequential data structure containing elements computed only on demand. A stream is either null or is a pair with a stream in its cdr. Since elements of a stream are computed only when accessed, streams can be infinite. Once computed, the value of a stream element is cached in case it is needed again.

Streams without memoization were first described by Peter Landin in 1965. Memoization became accepted as an essential feature of streams about a decade later. Today, streams are the signature data type of functional programming languages such as Haskell.

This Scheme Request for Implementation describes two libraries for operating on streams: a canonical set of stream primitives and a set of procedures and syntax derived from those primitives that permits convenient expression of stream operations. They rely on facilities provided by R6RS, including libraries, records, and error reporting. To load both stream libraries, say:

(import (streams))

• 40: A Library of Streams, by Philip L. BewigWithdrawn: 2017-08-10Keywords: Data Structure, SupersededSee also SRFI 41: Streams.

Along with higher-order functions, one of the hallmarks of functional programming is lazy evaluation. A primary manifestation of lazy evaluation is lazy lists, generally called streams by Scheme programmers, where evaluation of a list element is delayed until its value is needed.

The literature on lazy evaluation distinguishes two styles of laziness, called even and odd. Odd style streams are ubiquitous among Scheme programs and can be easily encoded with the Scheme primitives delay and force defined in R5RS. However, the even style delays evaluation in a manner closer to that of traditional lazy languages such as Haskell and avoids an "off by one" error that is symptomatic of the odd style.

This SRFI defines the stream data type in the even style, some essential procedures and syntax that operate on streams, and motivates our choice of the even style. A companion SRFI 41 Stream Library provides additional procedures and syntax which make for more convenient processing of streams and shows several examples of their use.

• 39: Parameter objects, by Marc FeeleyFinal: 2003-06-30Keywords: Binding, Parameters

This SRFI defines parameter objects, the procedure make-parameter to create parameter objects and the parameterize special form to dynamically bind parameter objects. In the dynamic environment, each parameter object is bound to a cell containing the value of the parameter. When a procedure is called the called procedure inherits the dynamic environment from the caller. The parameterize special form allows the binding of a parameter object to be changed for the dynamic extent of its body.

• 38: External Representation for Data With Shared Structure, by Ray DillingerFinal: 2003-04-02Keywords: I/O

This SRFI proposes (write-with-shared-structure) and (read-with-shared-structure), procedures for writing and reading external representations of data containing shared structure. These procedures implement a proposed standard external notation for data containing shared structure.

This SRFI permits but does not require replacing the standard (write) and (read) functions. These functions may be implemented without the overhead in time and space required to detect and specify shared structure.

An implementation conforms to this SRFI if it provides procedures named (write-with-shared-structure) and (read-with-shared-structure), which produce and read the same notation as produced by the reference implementation. It may also provide (read/ss) and (write/ss), equivalent functions with shorter names.

• 37: args-fold: a program argument processor, by Anthony CarricoFinal: 2003-01-13Keywords: Operating System

Many operating systems make the set of argument strings used to invoke a program available (often following the program name string in an array called argv). Most programs need to parse and process these argument strings in one way or another. This SRFI describes a set of procedures that support processing program arguments according to POSIX and GNU C Library Reference Manual guidelines.

• 36: I/O Conditions, by Michael SperberFinal: 2002-12-01Keywords: Exceptions, I/O

This SRFI specifies a set of condition types for I/O errors. The condition types are defined in terms of SRFI 35. Moreover, this SRFI requires a Scheme system implementing it to raise exceptions in the sense of SRFI 34 for errors occurring during the execution of the R5RS I/O operations.

• 35: Conditions, by Richard Kelsey and Michael SperberFinal: 2002-12-01Keywords: Exceptions

The SRFI defines constructs for creating and inspecting condition types and values. A condition value encapsulates information about an exceptional situation, or exception. This SRFI also defines a few basic condition types.

• 34: Exception Handling for Programs, by Richard Kelsey and Michael SperberFinal: 2002-12-01Keywords: Exceptions

This SRFI defines exception-handling and exception-raising constructs for Scheme, including

• a with-exception-handler procedure and a guard form for installing exception-handling procedures,
• a raise procedure for invoking the current exception handler.

This SRFI is based on (withdrawn) SRFI 12: Exception Handling by William Clinger, R. Kent Dybvig, Matthew Flatt, and Marc Feeley.

• 33: Integer Bitwise-operation Library, by Olin ShiversWithdrawn: 2003-07-17Keywords: Data Structure

R5RS Scheme has no utilities for performing bitwise logical operations on integers or bitstrings, which is a problem for authors of portable code. This SRFI proposes a coherent and comprehensive set of these functions; it is accompanied by a reference implementation of the spec in terms of a set of seven core operators. The reference implementation is

• portable
• efficient
• completely open, public-domain source

The precise semantics of these operators is almost never an issue. A consistent, portable set of names and parameter conventions, however, is. Hence this SRFI.

• 32: Sort Libraries, by Olin ShiversWithdrawn: 2003-07-17Keywords: Algorithm

Current Scheme sorting packages are, every one of them, surprisingly bad. I've designed the API for a full-featured sort toolkit, which I propose as an SRFI. The spec comes with 1200 lines of high-quality reference code: tightly written, highly commented, portable code, available for free. Implementors want this code. It's better than what you have.

• 31: A special form rec' for recursive evaluation, by Mirko LueddeFinal: 2002-12-02Keywords: Miscellaneous

We propose the implementation of a special form called rec. This form is a generalization and combination of the forms rec and named-lambda of [Clinger1985]. It allows the simple and non-imperative construction of self-referential expressions. As an important special case, it extends the A. Church form lambda such that it allows the direct definition of recursive procedures without using further special forms like let or letrec, without using advanced constructions like the H. B. Curry combinator and, unlike define, without introducing variable bindings into the external environment.

• 29: Localization, by Scott G. MillerFinal: 2002-08-01Keywords: I/O

This document specifies an interface to retrieving and displaying locale sensitive messages. A Scheme program can register one or more translations of templated messages, and then write Scheme code that can transparently retrieve the appropriate message for the locale under which the Scheme system is running.

• 28: Basic Format Strings, by Scott G. MillerFinal: 2002-06-25Keywords: I/O

This document specifies Format Strings, a method of interpreting a Scheme string which contains a number of escape sequences that are replaced with other string data according to the semantics of each sequence.

• 27: Sources of Random Bits, by Sebastian EgnerFinal: 2002-06-03Keywords: Randomness

This document specifies an interface to sources of random bits, or "random sources" for brevity. In particular, there are three different ways to use the interface, with varying demands on the quality of the source and the amount of control over the production process:

• The "no fuss" interface specifies that (random-integer n) produces the next random integer in {0, ..., n-1} and (random-real) produces the next random real number between zero and one. The details of how these random values are produced may not be very relevant, as long as they appear to be sufficiently random.
• For simulation purposes, on the contrary, it is usually necessary to know that the numbers are produced deterministically by a pseudo random number generator of high quality and to have explicit access to its state. In addition, one might want to use several independent sources of random numbers at the same time and it can be useful to have some simple form of randomization.
• For security applications a serious form of true randomization is essential, in the sense that it is difficult for an adversary to exploit or introduce imperfections into the distribution of random bits. Moreover, the linear complexity of the stream of random bits is more important than its statistical properties. In these applications, an entropy source (producing truely random bits at a low rate) is used to randomize a pseudo random number generator to increase the rate of available bits.

Once random sources provide the infrastructure to obtain random bits, these can be used to construct other random deviates. Most important are floating point numbers of various distributions and random discrete structures, such as permutations or graphs. As there is an essentially unlimited number of such objects (with limited use elsewhere), we do not include them in this SRFI. In other words, this SRFI is not about making all sorts of random objects---it is about obtaining random bits in a portable, flexible, reliable, and efficient way.

• 26: Notation for Specializing Parameters without Currying, by Sebastian EgnerFinal: 2002-02-14Keywords: Syntax

When programming in functional style, it is frequently necessary to specialize some of the parameters of a multi-parameter procedure. For example, from the binary operation cons one might want to obtain the unary operation (lambda (x) (cons 1 x)). This specialization of parameters is also known as "partial application", "operator section" or "projection".

The mechanism proposed here allows to write this sort of specialization in a simple and compact way. The mechanism is best explained by a few examples:

 (cut cons (+ a 1) <>) is the same as (lambda (x2) (cons (+ a 1) x2)) (cut list 1 <> 3 <> 5) is the same as (lambda (x2 x4) (list 1 x2 3 x4 5)) (cut list) is the same as (lambda () (list)) (cut list 1 <> 3 <...>) is the same as (lambda (x2 . xs) (apply list 1 x2 3 xs)) (cut <> a b) is the same as (lambda (f) (f a b))

As you see, the macro cut specializes some of the parameters of its first argument. The parameters that are to show up as formal variables of the result are indicated by the symbol <>, pronouced as "slot". In addition, the symbol <...>, pronounced as "rest-slot", matches all residual arguments of a variable argument procedure. As you can see from the last example above, the first argument can also be a slot, as one should expect in Scheme.

In addition to cut, there is a variant called cute (a mnemonic for "cut with evaluated non-slots") which evaluates the non-slot expressions at the time the procedure is specialized, not at the time the specialized procedure is called. For example,

 (cute cons (+ a 1) <>) is the same as (let ((a1 (+ a 1))) (lambda (x2) (cons a1 x2)))

As you see from comparing this example with the first example above, the cute-variant will evaluate (+ a 1) once, while the cut-variant will evaluate it during every invokation of the resulting procedure.

The mechanism proposed in this SRFI allows specializing any subset of the variables of a procedure. The result can be of fixed arity or of variable arity. The mechanism does not allow permutation, omission, duplication or any other processing of the arguments; for this it is necessary to write to use a different mechanism such as lambda.

• 25: Multi-dimensional Array Primitives, by Jussi PiitulainenFinal: 2002-05-21Keywords: Data Structure

A core set of procedures for creating and manipulating heterogeneous multidimensional arrays is proposed. The design is consistent with the rest of Scheme and independent of other container data types. It provides easy sharing of parts of an array as other arrays without copying, encouraging a declarative style of programming.

The specification is based on an original contribution by Alan Bawden in 1993.

• 24: Define-syntax in local lexical scopes, by Antti HuimaWithdrawn: 2002-04-12Keywords: Syntax

This document specifies a proper extension to Scheme which allows define-syntax forms to appear in those places where local definitions can appear (R5RS, 5.2.2). A corresponding letrec-variant is described.

• 23: Error reporting mechanism, by Stephan HoubenFinal: 2001-06-22Keywords: Control Flow, Error Handling

A mechanism is proposed to allow Scheme code to report errors and abort execution. The proposed mechanism is already implemented in several Scheme systems and can be implemented, albeit imperfectly, in any R5RS conforming Scheme.

• 22: Running Scheme Scripts on Unix, by Martin Gasbichler and Michael SperberFinal: 2002-01-20Keywords: Operating System

This SRFI describes basic prerequisites for running Scheme programs as Unix scripts in a uniform way. Specifically, it describes:

• the syntax of Unix scripts written in Scheme,
• a uniform convention for calling the Scheme script interpreter, and
• a method for accessing the Unix command line arguments from within the Scheme script.
• 21: Real-time multithreading support, by Marc FeeleyFinal: 2001-03-02Keywords: Concurrency

This SRFI defines the following multithreading datatypes for Scheme

• Mutex
• Condition variable
• Time

It also defines a mechanism to handle exceptions and some multithreading exception datatypes.

• 20: Simple object system, by Christian QueinnecWithdrawn: 2001-04-29Keywords: Miscellaneous

This SRFI presents an object system to define classes, generic functions as well as to support some level of introspection. This object system is based on Meroon-V3 which is itself inspired by CLOS. Meroon-V3 is distributed and used since 1992.

• 19: Time Data Types and Procedures, by Will FitzgeraldFinal: 2000-08-31Keywords: Data Structure

Points in time are represented a the number of seconds (with nanosecond precision) since "the epoch," a zero point in time. Several standard variants are defined, including UTC (universal coordinated time), TAI (international atomic time), and monotonic time. A point in time can also be represented as a Julian Day or Modified Julian Day number. Time durations, including time spent in a process or thread, are defined. Conversion routines are provided. The procedure CURRENT-TIME queries the current time in a specified variant, with a system-dependent resolution. Procedures for time arithmetic and time comparisons are also provided.

A date is a representation of a point in time in the Gregorian calendar, a 24 hour clock (with nanosecond precision) and a time zone offset from UTC. Procedures for converting between time and dates are provided, as well as for reading and writing string representations of dates.

• 18: Multithreading support, by Marc FeeleyFinal: 2001-03-14Keywords: Concurrency

This SRFI defines the following multithreading datatypes for Scheme

• Mutex
• Condition variable
• Time

It also defines a mechanism to handle exceptions and some multithreading exception datatypes.

• 17: Generalized set!, by Per BothnerFinal: 2000-07-24Keywords: Assignment

This is a proposal to allow procedure calls that evaluate to the "value of a location" to be used to set the value of the location, when used as the first operand of set!.For example:

(set! (car x) (car y))

becomes equivalent to
(set-car! x (car y))

Many programming languages have the concept of an lvalue. that is an "expression" that "evaluates" to a location, and which can appear on the left-hand-side of an assignment. Common Lisp has a related concept of "generalized variables" which can be used in setf and some other special forms. However, the Common Lisp concept is based on the idea of compile-time recognition of special "location-producing" functions; this does not seem to be in the "spirit of Scheme".

This SRFI proposes an extension of set! so that it provides similar functionality as Common Lisp's setf, except that the updater is associated with a procedure value, rather than a name.

• 16: Syntax for procedures of variable arity, by Lars T HansenFinal: 2000-03-10Keywords: Pattern Matching

CASE-LAMBDA, a syntax for procedures with a variable number of arguments, is introduced.

• 15: Syntax for dynamic scoping, by Lars T HansenWithdrawn: 2000-03-10Keywords: Binding

FLUID-LET, a binding syntax for dynamic scoping, is introduced.

• 14: Character-set Library, by Olin ShiversFinal: 2000-12-28

The ability to efficiently represent and manipulate sets of characters is an unglamorous but very useful capability for text-processing code -- one that tends to pop up in the definitions of other libraries. Hence it is useful to specify a general substrate for this functionality early. This SRFI defines a general library that provides this functionality.

It is accompanied by a reference implementation for the spec. The reference implementation is fairly efficient, straightforwardly portable, and has a "free software" copyright. The implementation is tuned for "small" 7 or 8 bit character types, such as ASCII or Latin-1; the data structures and algorithms would have to be altered for larger 16 or 32 bit character types such as Unicode -- however, the specs have been carefully designed with these larger character types in mind.

Several forthcoming SRFIs can be defined in terms of this one:

• string library
• delimited input procedures (e.g., read-line)
• regular expressions
• 13: String Libraries, by Olin ShiversFinal: 2000-12-28Keywords: Data Structure

R5RS Scheme has an impoverished set of string-processing utilities, which is a problem for authors of portable code. This SRFI proposes a coherent and comprehensive set of string-processing procedures; it is accompanied by a reference implementation of the spec. The reference implementation is

• portable
• efficient
• open source

The routines in this SRFI are backwards-compatible with the string-processing routines of R5RS.

• 12: Exception Handling, by William Clinger, R. Kent Dybvig, Matthew Flatt, and Marc FeeleyWithdrawn: 2000-01-22Keywords: Control Flow, Exceptions

The SRFI defines exception-handling constructs for Scheme, including

• the CURRENT-EXCEPTION-HANDLER procedure for obtaining the current exception-handling procedure,
• the WITH-EXCEPTION-HANDLER procedure and HANDLE-EXCEPTIONS form for installing an exception-handling procedure,
• the ABORT and SIGNAL procedures for raising exceptions, and
• constructs for creating and inspecting condition values, which encapsulate information about an exception.

This SRFI requires a Scheme implementation to raise an exception whenever an error is to be signaled or whenever the system determines that evaluation cannot proceed in a manner consistent with the semantics of Scheme. However, this SRFI does not define the information to be supplied by an implementation for each possible kind of exception; such a specification is left open for future SRFIs.

• 11: Syntax for receiving multiple values, by Lars T HansenFinal: 2000-03-15Keywords: Binding

The SRFI introduces syntactic forms LET-VALUES and LET*-VALUES that bind the values of expressions that return multiple values.

• 10: #, external form, by Oleg KiselyovFinal: 2000-01-13Keywords: Reader Syntax

The present SRFI proposes an extensible external representation of Scheme values, a notational convention for future SRFIs. This SRFI adds #,( as a new token and extends production rules of the grammar for a Scheme reader. The #,() form can be used for example to denote values that do not have a convenient printed representation, as well for conditional code compilation. It is proposed that future SRFIs that contain new read syntax for values use the #,() notation with an appropriate tag symbol.

As a particular example and the reference implementation for the #,() convention, this SRFI describes an interpretation of the #,() external form as a read-time application.

• 9: Defining Record Types, by Richard KelseyFinal: 1999-09-09Keywords: Data Structure

This SRFI describes syntax for creating new data types, called record types. A predicate, constructor, and field accessors and modifiers are defined for each record type. Each new record type is distinct from all existing types, including other record types and Scheme's predefined types.

• 8: receive: Binding to multiple values, by John David StoneFinal: 1999-08-30Keywords: Binding

The only mechanism that R5RS provides for binding identifiers to the values of a multiple-valued expression is the primitive call-with-values. This SRFI proposes a more concise, more readable syntax for creating such bindings.

• 7: Feature-based program configuration language, by Richard KelseyFinal: 1999-08-19Keywords: Features

This SRFI describes a configuration language to be used for specifing the set of Scheme features or extensions required to run a program. In addition to a list of required features, a program may also contain Scheme code to be used only when a particular feature or combination of features is available.

The configuration language is entirely distinct from Scheme; it is neither embedded in Scheme nor includes Scheme as a subset.

• 6: Basic String Ports, by William D ClingerFinal: 1999-07-01Keywords: I/O, Operating System

Scheme's i/o primitives are extended by adding three new procedures that

• create an input port from a string,
• create an output port whose contents are accumulated in Scheme's working memory instead of an external file, and
• extract the accumulated contents of an in-memory output port and return them in the form of a string.
• 5: A compatible let form with signatures and rest arguments, by Andy GaynorFinal: 1999-04-26Keywords: Binding

The named-let incarnation of the let form has two slight inconsistencies with the define form. As defined, the let form makes no accommodation for rest arguments, an issue of functionality and consistency. As defined, the let form does not accommodate signature-style syntax, an issue of aesthetics and consistency. Both issues are addressed here in a manner which is compatible with the traditional let form but for minor extensions.

• 4: Homogeneous numeric vector datatypes, by Marc FeeleyFinal: 1999-05-22Keywords: Data Structure

This SRFI describes a set of datatypes for vectors whose elements are of the same numeric type (signed or unsigned exact integer or inexact real of a given precision). These datatypes support operations analogous to the Scheme vector type, but they are distinct datatypes. An external representation is specified which must be supported by the read and write procedures and by the program parser (i.e. programs can contain references to literal homogeneous vectors).

• 3: List-Set Library, by Olin ShiversWithdrawn: 1999-08-26Keywords: Data Structure

This SRFI proposes a coherent and comprehensive set of procedures for manipulating lists as sets; it is accompanied by a reference implementation of the spec. The reference implementation is

• portable
• efficient
• completely open, public-domain source

Be aware that these procedures are inherently O(n^2) in the lengths of their parameter lists - serious set operations on large lists should use alternate techniques.

• 2: AND-LET*: an AND with local bindings, a guarded LET* special form, by Oleg KiselyovFinal: 1999-03-01Keywords: Binding, Control Flow

Like an ordinary AND, an AND-LET* special form evaluates its arguments -- expressions -- one after another in order, till the first one that yields #f. Unlike AND, however, a non-#f result of one expression can be bound to a fresh variable and used in the subsequent expressions. AND-LET* is a cross-breed between LET* and AND.

• 1: List Library, by Olin ShiversFinal: 1999-10-09

R5RS Scheme has an impoverished set of list-processing utilities, which is a problem for authors of portable code. This SRFI proposes a coherent and comprehensive set of list-processing procedures; it is accompanied by a reference implementation of the spec. The reference implementation is

• portable
• efficient
• completely open, public-domain source
• 0: Feature-based conditional expansion construct, by Marc FeeleyFinal: 1999-05-07Keywords: Features

It is desirable that programs which depend on additions to standard Scheme name those additions. SRFIs provide the specifications of these additions ("features"), and SRFI 0 provides the means to actually check that these features are present in the Scheme system by means of the cond-expand construct. It is anticipated that there will be two main classes of features:

• sets of value and syntax bindings

("Reader syntax" refers to aspects of the syntax described by the grammars in the Scheme reports.)

The former class of features will probably include most SRFIs, exemplified by the list library specified in SRFI 1. The latter class includes Unicode source code support and different kinds of parentheses.

Control over the presence of individual features will vary over different Scheme systems. A given feature may be absent or provided by default in some Scheme systems and in others some mechanism (such as an "import" clause in the code or a program configuration file, a command line option, a dependency declaration in a module definition, etc.) will be required for the feature to be present in the system.

Moreover, in some systems a given feature may be in effect throughout the entire program if it is in effect anywhere at all. Other systems may have more precise mechanisms to control the scope of a feature (this might be the case for example when a module system is supported). In general it is thus possible that a feature is in effect in some parts of the program and not in others. This allows conflicting SRFIs to be present in a given program as long as their scope do not intersect.

SRFI 0 does not prescribe a particular mechanism for controlling the presence of a feature as it is our opinion that this should be the role of a module system. We expect that future module system SRFIs will need to extend the semantics of SRFI 0 for their purposes, for example by defining feature scoping rules or by generalizing the feature testing construct.

## History

Every SRFI is hosted on Github, but if you'd like a complete archive of all SRFI documents and code, please download srfi.tgz.

The SRFI process has been important to the development of some of the official Scheme standards, including R6RS and R7RS. It has been running since 1998, and there have been many different editors.

At the 2018 Scheme Workshop, SRFI editor Arthur A. Gleckler gave a talk entitled Growing Schemes: Twenty Years of Scheme Requests for Implementation (YouTube, PDF) on SRFI, its history, and future plans.

Here's a graph of the total number of SRFIs since SRFI 0 was published on 1999-01-05:

Here is our privacy statement.