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.
References: <199902261636.LAA11953@xxxxxxxxxxxxxxx> From: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Michael Sperber [Mr. Preprocessor]) Date: 26 Feb 1999 17:52:16 +0100 Sure, that's just not the way we intended it to be written. It's the way you wrote it in the revised SRFI. I quote: To demonstrate the utility of the conditional construct, consider the following example: (cond-implements (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. All I did was make srfi-a and srfi-b a little more concrete. How about: (cond-implements (srfi-x 'good) (else (cond-implements (srfi-y (display "GIF only, sorry") (newline) ... jpeg stubs that raise errors ...)) ? I don't see why this makes a difference. Is the intent that the implementation not be allowed to choose the ELSE clause if it doesn't have to? What if the ELSE clause has a more efficient implementation than any others? The existence of a feature may make the program less efficient rather than more. What bothers me is that the programmer and user know so much and the implementation knows so little. All the implementation knows about is the general efficiency of its SRFI implementations. It knows nothing about the semantic loss of a particular choice, or the actual efficieny gains. What if the semantic loss is crucial to the user, or if the program only makes minimal use of an SRFI? In neither case would the efficieny matter. No, the way we thought it up, the implementation could indeed make different choices from COND-IMPLEMENTS to COND-IMPLEMENTS. I don't see how this is awful. It makes it hard to determine what program is actually going to run. Suppose SRFI-Y defines function Y and SRFI-Z defines function Z and both require some kind of initialization. My program leads off with: (cond-implements ((and srfi-x srfi-y) ... initialize y using x ...) ((and srfi-x srfi-z) ... initialize z using x ...) (else (error "insufficient implementation"))) Later I do: (cond-implements (srfi-y (y)) (srfi-z (z))) If the implementation prefers SRFI-Z to SRFI-Y in the presence of SRFI-X, but the other way around without SRFI-X, then this will break because the second form will call the uninitialized SRFI. In fact, there is no COND-IMPLEMENTS form I can write which will necessarily call the correct function, if the implementation is free to ignore previous choices. -Richard