[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Suggestion for SRFI 0

This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.

Hi Marc,

we have reviewed the issues surrounding SRFI 0 resulting from the
discussion so far.  We've also studied a range of Scheme
implementations for compatibility with the ideas of SRFI 0.  The
current draft covers a lot of the ground, but not all of it.

In particular, some Scheme implementations take the stance that no
features beyond R5RS are present "by default"; any additional features
require explicit imports.  It would be great if we could have a SRFI 0
which would cater to this situation, without impeding its viability on
more traditional systems.  This has turned out to be a complicated
task; the mailing list discussion had already uncovered that there are
non-trivial scoping issues to be worked out.

Since the mailing list discussion has already shown most of the issues
at hand, we decided to just go ahead and suggest a concrete revision
of SRFI 0 which caters to these requirements.  It is implementable
with essentially the same machinery as the current SRFI 0 draft, but
allows for a wider range of implementation strategies, and thus maps
more naturally to the various native language extension mechanisms of
current Scheme systems.  Functionally, the revision suggestion
subsumes the current draft.

We hope you like it.  Let us know!

Dave, Mike, and Shriram (The SRFI Editors)

Title: SRFI 0: Feature import and feature-based conditional expansion


Feature import and feature-based conditional expansion


Marc Feeley


It is desirable that program 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 and handle their correct use. It is anticipated that there will be two classes of features:

("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 and different kinds of parentheses.

One of the goals of this SRFI is to have feature implementations map naturally to the module systems of the respective Scheme implementations, where such a module system exists.

The scope of bindings for the provided features will vary over different implementations. Thus, to achieve portability, a program should only use a feature after an appropriate import clause, even if some Scheme implementations provide it by default.

SRFI 0, unlike other "require"-like library systems common in the Lisp world, separates between testing for the sheer existence of a feature and actually using it. This allows programs to be written which function in a wide variety of different Scheme implementations.


Most Scheme systems extend the language with some additional features (such as the ability to manipulate Unicode characters and strings, to do binary I/O, or to handle asynchronous interrupts). Such features may be provided in a variety of ways including new procedures, new program syntax, and extended behavior of standard procedures and special-forms. A particular functionality may exist in several or even most Scheme systems but its API may be different (use of a procedure or special-form, name, number of parameters, etc).


Different Scheme systems provide language extensions by different means: Some have them built-in by default, some provide them via on-demand loading of code, some provide them via module systems. Combinations of these approaches also exist.

To write code that will run on several Scheme systems, it is useful to have common constructs to:

Features are identified by feature identifiers. In order for the semantics of this construct to be well-defined, the feature identifier must of course refer to a feature which has a well-defined meaning. There is thus a need for a registry, independent of this SRFI, to keep track of the formal specification associated with each valid feature-identifier. The SRFI registry is used for this purpose.

Another issue is the binding time of this construct (i.e. the moment when it operates). It is important that the binding time be early so that a compiler can discard the sections of code that are not needed, and perform better static analyses. Expressing this construct through a procedure returning a boolean, such as (feature-implemented? 'srfi-5), would not achieve this goal, as its binding time is too late (i.e. program run-time). A read-time construct, such as Common Lisp's #+ read-macro, is very early but would require non-trivial changes to the reader of existing Scheme systems and the syntax is not particularly human-friendly. Instead, a macro-expansion-time construct is used.

It is desirable to separate the act of checking for the existence of a feature from actually making it available for a Scheme program to use. This enables program to make more involved decisions about what features of the ones available it might use. Hence, the SRFI also specifies an IMPORT-IMPLEMENTATION form which makes the bindings provided by a feature available. Separating this from the conditional construct also makes for more readable programs, especially in cases where the program requires a fixed set of features, and the only decision it makes are is to determine if qthe features exist (and the program will run) or not (in which case it won't).

Macro-expansion time may not be early enough to handle features which are effectively changes to the reader used by the Scheme implementation. Therefore, a third construct, IMPORT-READER-SYNTAX, which may only occur at the beginning of a syntactic processing unit, specifies its syntax.


One valid way to implement COND-IMPLEMENTS is in terms of a simpler IF-IMPLEMENTS construct with dependencies on just one feature at a time, and just one or two branches. Why not specify IF-IMPLEMENTS instead?

The COND-IMPLEMENTS construct specified here gives Scheme implementations more flexibility in implementing it. The specification is intentionally ambiguous as to which clause will be expanded in a COND-IMPLEMENTS form. This is in order to allow Scheme implementations to choose an especially convenient (fastest/least memory-intensive/...) combination of implementations.

To demonstrate the utility of the conditional construct, consider the following example:

       (srfi-a ... aaa ...)
       (srfi-b ... bbb ...))

where the programmer is implementing some abstraction that can use function aaa from SRFI a or can use function bbb from SRFI b. However, the semantic fit with aaa is substantially better, which the programmer recognized by giving that implementation first. So if both SRFIs exist, and the "quality" of implementation is the comparable for SRFI a and SRFI b, then using the version with the better semantic fit is probably more efficient. However if they both exist, but SRFI a must be compiled and loaded from a slow reference implementation, and SRFI b is implemented as a built-in native-code library, it is preferable that the Scheme implementation should use the second version.



<_expression_> --> (COND-IMPLEMENTS <cond-implements clause>+)
<command or definition>
             --> (IMPORT-IMPLEMENTATION <feature identifier>+)
<cond-implements clause>
             --> (<implementation requirement> <body>)
             --> (ELSE <body>)
<implementation requirement>
             --> <feature identifier>
             --> (AND <implementation requirement>*)
             --> (OR <implementation requirement>*)
             --> (NOT <implementation requirement>)
<feature identifier>
             --> srfi-<srfi number>
<srfi number> --> <nonzero digit 10> <digit 10>*
<nonzero digit 10> --> 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

<program>    --> <syntax import>? <command or definition>*
<syntax import> --> (IMPORT-READER-SYNTAX <feature identifier>+)


COND-IMPLEMENTS tests for the existence of feature implementations. It either expands into the body of one of its clauses or signals an error during syntactic processing. COND-IMPLEMENTS expands into the body of a clause whose implementation requirement the underlying Scheme implementation can satisfy.

An implementation requirement has an obvious interpretation as a logical formula, where the <feature identifier> variables have meaning TRUE if an implementation corresponding to the named feature exists in the underlying Scheme implementation, and FALSE otherwise. An implementation requirement is satisfied if its formula is true under this interpretation.

It is unspecified into which body the COND-IMPLEMENTS form expands if several clauses have satisfiable requirements.

The existence of an implementation in no way implies that the bindings provided by it are actually visible. (But it is possible that bindings provided by implementations are visible by default.)


IMPORT-IMPLEMENTATION makes available value and syntactic bindings from feature implementations. If a feature specified in an IMPORT-IMPLEMENTATION clause does not exist, an error is signalled during syntactic processing. If the bindings relating to a feature implementation are already available, IMPORT-IMPLEMENTATION is a no-op. It is an error for the bindings imported by one or several IMPORT-IMPLEMENTATION forms to conflict with each other. The existence test here is the same as in COND-IMPLEMENTS.

It is an error for an IMPORT-IMPLEMENTATION to appear anywhere other than at toplevel.


In Scheme implementations which implement alternate reader syntaxes, IMPORT-READER-SYNTAX allows stating that a syntactic processing unit is written in the syntax specified by a SRFI. If a feature specified in an IMPORT-READER-SYNTAX clause does not have an implementation, an error is signalled during syntactic processing. The alternative syntax will be in effect immediately following the closing parenthesis of the IMPORT-READER-SYNTAX form. If the reader changes relating to a feature implementation are already in effect, IMPORT-READER-SYNTAX is a no-op. It is an error for the syntaxes imported by one or several IMPORT-READER-SYNTAX forms to conflict with each other. The existence test here is the same as in COND-IMPLEMENTS.

It is an error for an IMPORT-READER-SYNTAX to appear anywhere but as the first form in a syntactic processing unit or within that first form, either literally or as a result of macro expansion.

Appendix: Implementation Issues

This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.

A feature implementation may be, for example:

The latter two possibilities allow loading or linking a feature implementation "on-demand" only for programs which actually use them. Some Scheme implementations might use the underlying package system to implement on-demand loading. Batch implementations might process a program using SRFI 0 to generate link commands. Other possibilities exist.

It is the intention that, if the implementation has a choice between equivalent "quality," it will choose the first matching clause in left-to-right order.

In Scheme implementations where feature implementations are loadable, COND-IMPLEMENTS by itself should merely test for the existence of implementations, but not actually load any code, import any bindings, or make any reader changes. The actual loading/importing only happens through IMPORT-IMPLEMENTATION and IMPORT-READER-SYNTAX.

In Scheme implementations where feature implementations are not loadable, COND-IMPLEMENTS is a simple feature test, and IMPORT-IMPLEMENTATION and IMPORT-READER-SYNTAX are no-ops if they do not signal an error.

The issue of alternative reader syntax is the most difficult. The specification of IMPORT-READER-SYNTAX makes the assumption that one syntactic processing unit has a single syntax throughout. It is convenient to have the processing unit specify which syntax it is written in, rather than specifying the syntax externally.

Since changing the reader syntax may have complex interactions with macro expansion and other syntactic processing, the IMPORT-READER-SYNTAX must appear at the beginning of a processing unit. The intention is that a Scheme implementation can determine the syntax of a processing unit by retrieving the first form in a unit via READ and macro-expanding that form. This makes the proposal compatible with Scheme implementations which depend on reading in a whole processing unit before macro expansion.

A consequence of the specification is that an initial form specifying a syntax change can really only use LET-SYNTAX, LETREC-SYNTAX, uses of macros defined by them, and COND-IMPLEMENTS.

Scheme implementations that do not support changable readers need not handle a COND-IMPLEMENTS that appears as the first form specially. Here, IMPORT-READER-SYNTAX may be a simple macro.


The simplest implementation of SRFI 0 assumes that all existent features are built-in.

Nota bene: This implementation only demonstrates implementability under R5RS Scheme. It is by no means a reference implementation to be used in actual Scheme systems. Moreover, the behavior of this implementation is a significant restriction on the specification.

(define-syntax import-implementation
  (syntax-rules ()
    ((import-implementation feature-id ...)
     (cond-implements (and feature-id ...) 42))))

(define-syntax import-reader-syntax
  (syntax-rules ()
    ((import-reader-syntax feature-id ...)
     (cond-implements (and feature-id ...) 42))))

(The specification requires a macro-expansion time error to be signalled if a COND-IMPLEMENTS has no fulfilled clause. There is no standard way to so that, so this implementation uses the SYNTAX-ERROR form, with the assumption that an actual implementation would provide some way to do this.)

(define-syntax cond-implements
  (syntax-rules (and or not else srfi-0 srfi-5)
    ((cond-implements) (syntax-error "Unfulfilled COND-IMPLEMENTS"))
    ((cond-implements (else body ...))
     (begin body ...))
    ((cond-implements ((and) body ...) more-clauses ...)
     (begin body ...))
    ((cond-implements ((and req1 req2 ...) body ...) more-clauses ...)
           ((and req2 ...) body ...)
           more-clauses ...))
       more-clauses ...))
    ((cond-implements ((or) body ...) more-clauses ...)
     (cond-implements more-clauses ...))
    ((cond-implements ((or req1 req2 ...) body ...) more-clauses ...)
        (begin body ...))
           ((or req2 ...) body ...)
           more-clauses ...))))
    ((cond-implements ((not req) body ...) more-clauses ...)
         (cond-implements more-clauses ...))
       (else body ...)))
    ((cond-implements (srfi-0 body ...) more-clauses ...)
       (begin body...))
    ((cond-implements (srfi-5 body ...) more-clauses ...)
       (begin body...))
    ((cond-implements (feature-id body ...) more-clauses ...)
       (cond-implements more-clauses ...))))


Copyright (C) Marc Feeley (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Scheme Request For Implementation process or editors, except as needed for the purpose of developing SRFIs in which case the procedures for copyrights defined in the SRFI process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the authors or their successors or assigns.


Editor: Mike Sperber
Last modified: Fri Feb 5 21:10:35 MET 1999