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.
To follow up, here are clarified/corrected paragraphs describing
COND-IMPLEMENTS, relative to the editors' suggestion for revising SRFI
0:
Definition:
If one the clauses has a satisfiable implementation requirement,
COND-IMPLEMENTS must expand into the body of a clause with a
satisfiable requirement. (I.e., it must not expand into the ELSE
clause in that case.) It is unspecified into which body the
COND-IMPLEMENTS form expands if several clauses have satisfiable
requirements.
Example:
To demonstrate the utility of the conditional construct, consider the
following example:
The programmer is implementing some abstraction which can use function
aaa from SRFI a or can use function bbb from SRFI b.
If the programmer does not care which implementation her code uses,
she can just write:
(cond-implements
(srfi-a ... aaa ...)
(srfi-b ... bbb ...))
In this case, the Scheme system, if it implements both SRFI a and SRFI
b, will pick a branch based on its own preference, supposedly the more
efficient or easier-to-load implementation.
It may also be that the programmer has a preference for SRFI a,
maybe because the program can provide more functionality in this
case. Only if SRFI a is unavailable, she wants SRFI b. Here is the
code:
(cond-implements
(srfi-a ... aaa ...)
(else
(cond-implements
(srfi-b ... bbb ...))))
This works because COND-IMPLEMENTS must choose a non-ELSE branch if
possible.
--
Cheers =8-} Mike