This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 are here. Eventually, the entire history will be moved there, including any new messages.
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