2.1.3 Rationale

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). To write code that will run on several Scheme systems, it is useful to have a common construct to enable or disable sections of code based on the existence or absence of a feature in the Scheme system being used. For example, the construct could be used to check if a particular binary I/O procedure is present, and if not, load a portable library which implements that procedure.

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. It is expected 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.

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.

The construct is restricted to the top level of a program in order to simplify its implementation and to force a more disciplined use of the construct (to facilitate reading and understanding programs) and to avoid (some) misunderstandings related to the scope of features. These restrictions can of course be lifted by some Scheme systems or by other SRFIs (in particular module system SRFIs).