261: Portable SRFI Library Reference

by WANG Zheng (ufo5260987423)

Status

This SRFI is currently in draft status. Here is an explanation of each status that a SRFI can hold. To provide input on this SRFI, please send email to srfi-261@nospamsrfi.schemers.org. To subscribe to the list, follow these instructions. You can access previous messages via the mailing list archive.

• Received: 2025-05-02
• 60-day deadline: 2025-07-06
• Draft #1 published: 2025-05-07
• Draft #2 published: 2025-06-13
• Draft #2 published: 2025-07-01

Abstract

This SRFI proposal addresses systemic compatibility issues exposed by the SRFI-97-defined library reference format (srfi :<SRFI number> <identifier> ...) and advocates for two more modernized, portable and readable alternatives: (srfi srfi-<SRFI number>) and (srfi <identifier>-<SRFI number>).

Table of contents

• Rationale
• Specification
  • Portable SRFI Reference
  • Readable and Equivalent SRFI Reference
  • Reserved, Restricted and Equivalent SRFI Reference
• Naming convention
  • Included SRFIs
  • Omitted SRFIs
• Implementation
• Acknowledgements

Issues

• Discussion: Should this proposal be a patch or replacement to SRFI 97?
• Discussion: The srfi- prefix is used in order to make the SRFI number component an identifier, as required by R⁶RS.
• Discussion: Restriction on portable set of characters may cause incompatible update to previous proposals. Further discussion is required.
• Discussion: SRFI 103 proposed a standard for locating files containing libraries with list-of-symbols library names for Unixes and Windows, and above illegal library file names were suggested to be encoded. But it were finally withdrawn.
• Discussion: The following table should be checked by our community together, because since SRFI 111, I have been writing reasons purely based on speculation. They actually are beyond my my technical skills and language proficiency.

Rationale

SRFI 97 minimized assumptions made about a Scheme system's conformance to that systems may support SRFI Libraries without needing to support all of the R⁶RS and R⁷RS library systems. However, its SRFI library reference format (srfi :<SRFI number> <identifiers> ...) introduces portability and toolchain challenges due to the colon : character. This design stems from R⁶RS's prohibition against unsigned integers as standalone library name components (e.g., (1 lists) is invalid). This proposal advocates replacing it with (srfi srfi-<SRFI number>) and (srfi <identifier>-<SRFI number>), resolving three core issues:

1. Filesystem Incompatibility: Colons are reserved characters in major systems (e.g., Windows drive identifiers C://). Mapping (srfi :1) to paths like srfi/:1/ fails on Windows and requires error-prone workarounds elsewhere. Hyphens - are universally valid, enabling predictable paths like srfi/srfi-1/.
2. Modern Scheme Unalignment: R⁷RS's hierarchical define-library syntax favors flat namespaces (e.g., (srfi 1)), while implementations like Larceny already phase out colons for newer SRFIs. The srfi- prefix retains backward compatibility while harmonizing with R⁷RS trends.
3. URI Incompatibility: The colon : is a reserved character in URI syntax (RFC 3986), mandating percent-encoding (e.g., srfi%3A1), while the hyphen - is an unreserved character that requires no escaping, ensuring cleaner and more human-readable URIs.

Discussion: Should this proposal be a patch or replacement to SRFI 97?

Specification

This specification adopts the principle of minimal modifications, and it includes the following: a portable library-referencing scheme without changing the existing infrastructure for all past and future SRFI libraries, two reserved and restricted reference schemes to make SRFI 97 and R⁷RS convenient, an extended naming convention for selecting library names, and an enumeration of library names selected for all currently finalized SRFIs that specify libraries.

Portable SRFI Reference

A SRFI library reference should at least have the form

(srfi srfi-<uinteger 10>),

where <uinteger 10> is a SRFI number, defined as a non-terminal given in R⁶RS Chapter 4, Lexical syntax.

Discussion: The srfi- prefix is used in order to make the SRFI number component an identifier, as required by R⁶RS.

A SRFI Library can be referenced by number, as in

(srfi srfi-1).

Readable and Equivalent SRFI Reference

A SRFI library reference also should have the readable form

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

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

A SRFI Library can be referenced equivalently using the library's name, as in

(srfi lists-1), 

though which may be incompatibility with Windows's and Unix's filesystem.

Discussion: Restriction on portable set of characters may cause incompatible update to previous proposals. Further discussion is required.

Reserved, Restricted and Equivalent SRFI Reference

Only for SRFI library references with SRFI number less than 261 could continually reserve the following SRFI 91's naming manner as equivalent reference forms,

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

in which the colon prefix : plays the same role to make SRFI number <uinteger 10> an identifier, and other non-terminals are defined as given in the portable references.

So that, a SRFI with number less than 261 can be referenced equivalently as in

(srfi :1), 

or equivalently using the library's name, as in

(srfi :1 lists). 

Naming convention

Mnemonic library names are chosen according to the SRFI 97's conventions: 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, in which *, ? and many other characters are allowed. However, such characters are not legal for the filesystem in Windows, Unixes, or URIs. All SRFI library names may be uniformly named in srfi-<uinteger 10> format with additional proper file-name extensions, and library locating affairs can be reserved for various implementations.

Discussion: SRFI 103 proposed a standard for locating files containing libraries with list-of-symbols library names for Unixes and Windows, and above illegal library file names were suggested to be encoded. But it was finally withdrawn.

Included SRFIs

Since SRFI 97, SRFI's family has been largely extended, and this proposal continues to include SRFIs with criterion the same as SRFI 97.

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 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:

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.

Discussion: The following table should be checked by our community together, because since SRFI 111, I have been writing reasons purely based on speculation. They actually are beyond my my technical skills and language proficiency.

Implementation

There is no sample implementation as this SRFI only specifies a portable SRFI library reference.

Acknowledgements

I thank Marc Nieper-Wißkirchen for suggesting that I write this SRFI and providing a fairly complete context. I just wrote down his discussions.

Thanks to the participants in the SRFI 261 mailing list who helped me refine this SRFI, including Marc Nieper-Wißkirchen, Wolfgang Corcoran-Mathe, John Cowan, Arthur A. Gleckler and Daphne Preston-Kendal.

Copyright

© 2025 WANG Zheng (ufo5260987423).

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 (including the next paragraph) 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. 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.