Title

SRFI Libraries

Author

David Van Horn

Status

This SRFI is currently in ``draft'' status. To see an explanation of each status that a SRFI can hold, see here. To provide input on this SRFI, please mail to <srfi minus 97 at srfi dot schemers dot org>. See instructions here to subscribe to the list. You can access previous messages via the archive of the mailing list.

Received: 2008/03/25
Draft: 2008/03/25 - 2008/05/24

Abstract

Over the past ten years, numerous libraries have been specified via the Scheme Requests for Implementation process. Yet until the recent ratification of the Revised⁶ 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. Moreover, portable R⁶RS reference implementations and test suites are provided, where possible, for the SRFI Libraries.

Issues

Some authors have already specified the names that should be used (e.g., list-lib for SRFI 1 and vector-lib for SRFI 43) for Schemes with a library system, however these names are not used here. SRFI 41 Streams is the only SRFI to specify an R⁶RS library and therefore it specifies its library names. These names are not used here. In both cases, a consistent naming scheme is used which happens to differ from the author's originally chosen names. (Note that most implementations, which do have some kind of library system, do not follow the author recommendations for names in existing SRFIs.)
This SRFI uses (srfi N), but this is not allowed in R⁶RS, even though it is consistent with the R⁶RS recommendation that library names be suitable as part of file names (indeed, numbers are used in the versioning component of library names). So if there is a consensus that this should be the way to reference SRFIs, I'm willing to make a de facto extension of R⁶RS that allows for this. Other alternatives include (srfi-N), which is non-hierarchical and thus violates the recommendations of R⁶RS on choosing library names and may cause some ugliness when systems map names to a file system location and all the srfis appear in the root directory. Other options include (srfi nN *), (org schemers srfi-N *), (srfis srfi-N *), etc. All of these are, in my opinion, ugly hacks around R⁶RS limitations.
Some SRFIs are omitted on the grounds that they alter the semantics of standard Scheme bindings (e.g., SRFI 70, Numbers). It is possible that these SRFIs could be provided as libraries that effectively supersede (rnrs base) by exporting the same bindings as (rnrs base), but with the altered semantics. Combining several such SRFIs would not work as intended, but it may be a sensible alternative to omission. On the other hand, this might be seen as a perversion of the original author's intent that these semantics really be the semantics of the standard bindings.
Some SRFIs are omitted on the grounds that they alter or extend the lexical syntax of Scheme programs, which cannot be provided by an R⁶RS library (see next issue). However, extensions to lexical syntax could be part of a SRFI library so long as that library (or some other library) also exports procedures that implement the extended syntax. In other words, extensions to the lexical syntax of the standard read and write procedures cannot be part of a SRFI library, but nonstandard read and write procedures are okay. SRFI 38 does this. Should this approach be adopted in general?
R6RS allows for lexical extension via #!<identifier> lexemes. Should this SRFI incorporate those SRFIs that are excluded for extending the lexical syntax and define the appropriate #!srfi-N lexeme?
Some omitted SRFIs may be implemented as libraries (eg. Conditions), but have been omitted because they are subsumed by R⁶RS, or are don't make much sense without other SRFIs which cannot be implemented as libraries (such as Exception Handling for Programs). Should these SRFIs be included?
Is SRFI 44, Collections, really a SRFI Library? It's more of a meta-SRFI than a library.
SRFI 4, Homogeneous numeric vector datatypes, has a substantial library component but also modifies the lexical syntax of the language. Should it be considered a SRFI Library?
Should export levels be specified?
Withdrawn SRFIs are not considered here. Should they be?
Versioning information is not included in the library naming scheme. This SRFI does not specify the meaning of importing SRFI libraries declared with versioning information.
ERR⁵RS: My hope is that this SRFI carries over without issue to ERR⁵RS. But someone who knows more about the library system of ERR⁵RS will have to evaluate this.
See the "author's notes", marked in the text by italics.

Rationale

With the advent of R⁶RS, it has become possible to write and distribute portable Scheme code as libraries. However, there is no agreed upon way to refer to SRFI libraries, leaving implementors to create their own conventions thus thwarting portability of code which relies on SRFIs. So there is an immediate and obvious need for standardized SRFI library names.

Moreover, there is a clear need to reexamine the existing body of SRFI libraries and to come to a consensus on how to resolve issues, if any, that arise under the latest Scheme standards.

Finally, because the library system of R⁶RS facilitates the distribution of portable libraries, this SRFI will provide portable reference implementations and test suites for SRFI libraries, where possible. Again, this facilitates distribution of portable code that relies on SRFIs and can greatly benefit Scheme systems with minimal or no support for SRFIs.

Specification

This specification includes a list of library names for existing SRFIs that specify libraries. These names are assigned according to a naming convention given below.

Although R⁶RS's notion of a library is the one used here, this SRFI attempts to minimize assumptions made about a Scheme systems conformance to R⁶RS so that systems may support SRFI Libraries without necessarily supporting all of R⁶RS.

Referencing SRFI Libraries

A SRFI library reference has the following form,

(srfi <uinteger 10> <identifier> ...),

where <identifier> is one of the included SRFI library names defined below, and

<uinteger
10>

is one of the included SRFI numerals given below. The non-terminals <uinteger 10> and <identifier> are defined as given in R⁶RS Chapter 4, Lexical syntax.

Discussion: According to R⁶RS, library references consist only of identifiers, so this naming scheme does not strictly conform to R⁶RS, however this is a moderate and reasonable extension to request that allows SRFI Libraries to remain hierarchical, consistent with the precedent of the R⁶RS Standard Libraries.

A SRFI Library can be referenced by number, as in

(srfi 1),

or equivalently using the library's name, as in

(srfi 1 lists).

Discussion: Even though the latter uses a library name, the SRFI number must still be supplied. This is done to ensure fairness and uniqueness—a SRFI should not be able to prevent other SRFIs from using the same name, but at the same time, SRFI library references should remain unambiguous.

Discussion: Since the number-only naming scheme ensures both uniqueness and fairness, the named-library scheme is redundant, but it is included to make library imports more readable. Although the same could be achieved via a comment, comments are not checked. The named-library scheme can thus be used to increase the likelihood that the correct library is imported.

The remaining identifier subforms are used to name sublibraries within a SRFI Library. For example, SRFI 41, Streams, defines primitive and derived libraries within the streams library. These can be referenced as

(srfi 41 streams primitive),
(srfi 41 streams derived).

Naming convention

Libraries that define datatypes are typically pluralized (e.g., arrays, basic-string-ports). Libraries that provide new expression forms are named by the name of their new form (e.g., let-values, rec, and-let*). Libraries that define a single procedure (or that have a primary procedure) are given the name of the procedure (e.g., error, cat). Libraries that provide a large API of syntaxes and values are named in a descriptive manner derived from their title (e.g., lightweight-testing, real-time-multithreading). This naming convention is consistent with the names chosen in the R⁶RS Standard Libraries.

Discussion: There is opportunity for grouping related SRFIs together. For example, SRFI 28, Basic Format Strings, and SRFI 48, Intermediate Format Strings, could be grouped into a common format library with simple and intermediate components. This has been avoided, preferring instead to follow a one SRFI, one (top-level) library convention. Although within a single SRFI, several sub-libraries can be defined, thus achieving grouping. This simplifies the naming convention and prevents the need for a naming authority which decides what shall and shall not be grouped together. Instead, grouping must be achieved by the SRFI process, as it should.

Included SRFIs

The criterion for inclusion in the set of SRFI Libraries is that the finalized SRFI only specify a set of bindings which can be provided as a library. SRFI Libraries need not be implementable as an R⁶RS library, but they must specify an interface which could be used as if it were. This means, for example, that lexical syntax extensions cannot be a part of a SRFI Library. SRFIs that specify global semantic changes to Scheme also cannot be SRFI Libraries. For example, a Lazy Scheme SRFI or a SRFI that fixed order of evaluation in procedure application could not be a SRFI Library because these features cannot be provided as a set of bindings.

Some SRFIs specify alternative semantics to standard Scheme bindings. In some cases, such as SRFI 5's let, it's clear that making the alternative binding for let available as a library binding is desirable. Authors that wish to use SRFI 5's let, rather than R⁶RS's let, simply import the SRFI 5 binding and exclude the R⁶RS binding for let (or rename to avoid the clash).

Other SRFIs, however, define alternative bindings that are intended to be used throughout a Scheme system. For example, SRFI 63's equal? and most of SRFI 70, Numbers, are defined like this. But if the author intends for these bindings to replace the standard bindings, then there is no way of making this feature available as a library, so the SRFI cannot be a SRFI Library.

The approach taken in this SRFI is that a SRFI is excluded as a SRFI Library if it explicitly states the binding is to replace the standard one. For example, SRFI 70, Numbers, is excluded because it explicitly revises the text of R⁵RS, thus intending to make a global semantic change to the language which cannot be provided as a library. On the other hand, SRFI 63, Homogeneous and Heterogeneous Arrays, is included and provides a binding for equal? because the SRFI 63 document does not explicitly state this should replace the standard equal? binding.

The following SRFI library names are defined:

SRFI	Library names	Title
1	lists	List Library
2	and-let*	AND-LET: an AND with local bindings, a guarded LET special form
5	let	A compatible let form with signatures and rest arguments
6	basic-string-ports	Basic String Ports
8	receive	`receive`: Binding to multiple values
9	records	Defining Record Types
11	let-values	Syntax for receiving multiple values
13	strings	String Libraries
14	char-sets	Character-Set Library
16	case-lambda	Syntax for procedures of variable arity
17	generalized-set!	Generalized set!
18	multithreading	Multithreading support
19	time	Time Data Types and Procedures
21	real-time-multithreading	Real-time multithreading support
23	error	Error reporting mechanism
25	multi-dimensional-arrays	Multi-dimensional Array Primitives
26	cut	Notation for Specializing Parameters without Currying
27	random-bits	Sources of Random Bits
28	basic-format-strings	Basic Format Strings
29	localization	Localization
31	rec	A special form for recursive evaluation
38	with-shared-structure	External Representation for Data With Shared Structure
39	parameters	Parameter objects
41	streams, streams primitive, streams derived	Streams
42	eager-comprehensions	Eager Comprehensions
43	vectors	Vector Library
44	collections	Collections
45	lazy	Primitives for expressing iterative lazy algorithms
46	syntax-rules	Basic Syntax-rules Extensions
47	arrays	Array
48	intermediate-format-strings	Intermediate Format Strings
51	rest-values	Handling rest list
54	cat	Formatting
57	records	Records
59	vicinities	Vicinity
60	integer-bits	Integers as Bits
61	cond	A more general `cond` clause
63	arrays	Homogeneous and Heterogeneous Arrays
64	testing	A Scheme API for test suites
66	octet-vectors	Octet Vectors
67	compare-procedures	Compare Procedures
69	basic-hash-tables	Basic hash tables
71	let	`LET`-syntax for multiple values
74	blobs	Octet-Addressed Binary Blocks
78	lightweight-testing	Lightweight testing
86	mu-and-nu	MU and NU simulating VALUES & CALL-WITH-VALUES, and their related LET-syntax
87	case	=> in case clauses
95	sorting-and-merging	Sorting and Merging

Omitted SRFIs

SRFIs are not libraries, they are requests for features. Thus, several SRFIs specify features which cannot be provided as a library and those SRFIs are intentionally omitted here. For example, SRFIs which specify extensions to concrete syntax or extensions to the semantics of top-level programs cannot be provided as libraries and are therefore omitted from this SRFI. The following table lists omitted (finalized) SRFIs and the reason for their omission.

SRFI Title Reason for omission

0 Feature-based conditional expansion construct Modifies semantics of top-level programs.

4 Homogeneous numeric vector datatypes Modifies lexical syntax.

7 Feature-based program configuration language Defines a configuration language distinct from Scheme.

10 #, external form Modifies lexical syntax.

22 Running Scheme Scripts on Unix Does not specify a library.

30 Nested Multi-line Comments Modifies lexical syntax (subsumed by R⁶RS).

34 Exception Handling for Programs Subsumed by R⁶RS.

36 I/O Conditions Subsumed by R⁶RS.

37 args-fold: a program argument processor Does not specify a library.

41 A Library of Streams Deprecated by SRFI 41, Streams.

49 Indentation-sensitive syntax Modifies lexical syntax.

55 require-extension Modifies semantics of top-level programs.

58 Array Notation Modifies lexical syntax.

62 S-expression comments Modifies lexical syntax (subsumed by R⁶RS).

70 Numbers Modifies standard semantics for number system.

72 Hygienic macros Modifies macro expansion semantics.

88 Keyword objects Modifies lexical syntax.

89 Optional positional and named parameters Modifies syntax and semantics of application, which cannot be provided by a library. Dependent on lexical syntax modification (SRFI 88).

90 Extensible hash table constructor Dependent on lexical syntax modification (SRFI 88).

94 Type-Restricted Numerical Functions Dependent on number system modification (SRFI 70).

SRFI	Title	Reason for omission
0	Feature-based conditional expansion construct	Modifies semantics of top-level programs.
4	Homogeneous numeric vector datatypes	Modifies lexical syntax.
7	Feature-based program configuration language	Defines a configuration language distinct from Scheme.
10	`#,` external form	Modifies lexical syntax.
22	Running Scheme Scripts on Unix	Does not specify a library.
30	Nested Multi-line Comments	Modifies lexical syntax (subsumed by R⁶RS).
34	Exception Handling for Programs	Subsumed by R⁶RS.
36	I/O Conditions	Subsumed by R⁶RS.
37	args-fold: a program argument processor	Does not specify a library.
41	A Library of Streams	Deprecated by SRFI 41, Streams.
49	Indentation-sensitive syntax	Modifies lexical syntax.
55	`require-extension`	Modifies semantics of top-level programs.
58	Array Notation	Modifies lexical syntax.
62	S-expression comments	Modifies lexical syntax (subsumed by R⁶RS).
70	Numbers	Modifies standard semantics for number system.
72	Hygienic macros	Modifies macro expansion semantics.
88	Keyword objects	Modifies lexical syntax.
89	Optional positional and named parameters	Modifies syntax and semantics of application, which cannot be provided by a library. Dependent on lexical syntax modification (SRFI 88).
90	Extensible hash table constructor	Dependent on lexical syntax modification (SRFI 88).
94	Type-Restricted Numerical Functions	Dependent on number system modification (SRFI 70).

Existing SRFIs and R⁶RS

This section addresses any issues relevant to each existing SRFI's use and implementation in an R⁶RS Scheme system. These issues should be addressed and resolved by general agreement so that SRFI Libraries are consistent across implementations wherever possible.

I have identified only a small number of issues, outlined below. Surely, there are further issues, so please send mail to the discussion list if you know of others.

SRFI 9, Defining Record Types, and R⁶RS Records. What relation should SRFI 9 records have with R⁶RS records? For example, does record? hold of SRFI 9 record values? Are SRFI 9 records opaque? Is the type name bound to a rtd?
SRFI 42, Eager Comprehensions, defines qualifiers, which are used as macro keyword literals, and some of these conflict with names provided by (rnrs base). Should anything be specified about these keywords (eg, should this library provide bindings?, the same bindings as in (rnrs base)?, etc.)?
SRFI 74, Octet-Addressed Binary Blocks, blobs and R⁶RS bytevectors are conceptually the same. Should (bytevector? b) imply (blob? b) and vice versa? This is the case in reference implementation.

Future SRFIs

Authors of future SRFIs that specify libraries may choose names as they please, but they are encouraged to use library names following the naming convention of this SRFI. If names are chosen that are not compatible with the referencing scheme given here, authors should specify alternative names that can be used to refer to the library consistent with this specification.

SRFI 41, Streams, for example, specifies that its libraries are named by (streams), (streams primitive), and (streams derived), but according to this SRFI, they must also be named with the prefix (srfi 41 *).

Relation to SRFIs 0 and 7

Both SRFI 0, Feature-based conditional expansion construct, and SRFI 7, Feature-based program configuration language, use feature identifiers of the form srfi-N, with the expectation "that features will eventually be assigned meaningful names (aliases) by the SRFI editors to make reading and writing code less tedious than when using srfi-N feature identifiers."

It is recommended that implementations which support SRFIs 0 or 7 use the SRFI names defined here as aliases. SRFI feature identifiers are constructed by interpolating library references with "-". For example, the feature identifier for SRFI 1, List Library, is srfi-1, or equivalently, srfi-1-lists. Feature identifiers for sub-libraries are constructed in the same way, so for example the feature identifier for the streams primitive library is srfi-41-streams-primitive.

Implementation

To be provided later in the discussion period.

Acknowledgments

Code for the reference implementation is drawn from the SRFI reference implementations, Gauche, Guile, Larceny, PLT Scheme, Scheme 48, and SLIB. For discussions, I thank Will Clinger, Aziz Ghuloum, Dave Herman, Olin Shivers, Andre van Tonder, and my fellow SRFI editors. During the development of this SRFI, all of the library infrastructure was built using the van Tonder implementation of R⁶RS Libraries and Macros, which has proved to be quite a useful tool in writing portable Scheme code. It was later tested on Ikarus, Larceny, and PLT Scheme.

References

Revised⁶ Report on the Algorithmic Language Scheme: Michael Sperber, et al. (Editors)
http://www.r6rs.org/
R⁶RS Libraries and Macros: Andre van Tonder
http://www.het.brown.edu/people/andre/macros/
R⁶RS Libraries and syntax-case system: Abdulaziz Ghuloum and Kent Dybvig
http://www.cs.indiana.edu/~aghuloum/r6rs-libraries/
Teach Yourself Scheme in Fixnum Days: Dorai Sitaram
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html
A proposal for an Extended R⁵RS Scheme: William Clinger, et al.
http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter
Ikarus Scheme: http://www.cs.indiana.edu/~aghuloum/ikarus/
Larceny: http://www.ccs.neu.edu/home/will/Larceny/
PLT Scheme: http://plt-scheme.org/
Scheme 48: http://s48.org/

Copyright

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. REMEMBER, THERE IS NO SCHEME UNDERGROUND. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Editor: Donovan Kolby