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.
>>>>> "Richard" == Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx> writes: Richard> References: <199902261636.LAA11953@xxxxxxxxxxxxxxx> Richard> From: sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Michael Sperber [Mr. Preprocessor]) Richard> Date: 26 Feb 1999 17:52:16 +0100 Richard> Sure, that's just not the way we intended it to be written. Richard> It's the way you wrote it in the revised SRFI. I quote: Richard> where the programmer is implementing some abstraction that can use Richard> function aaa from SRFI a or can use function bbb from SRFI b. However, Richard> the semantic fit with aaa is substantially better, which the programmer Richard> recognized by giving that implementation first. Ooops. Our wording is obviously incorrect. It's probably a remnant from an earlier draft. This should be fixed. I'll get to work on something tomorrow. Richard> All I did was make srfi-a and srfi-b a little more concrete. Richard> How about: Richard> (cond-implements Richard> (srfi-x 'good) Richard> (else Richard> (cond-implements Richard> (srfi-y (display "GIF only, sorry") Richard> (newline) Richard> ... jpeg stubs that raise errors ...)) Richard> ? Richard> I don't see why this makes a difference. Is the intent that the Richard> implementation not be allowed to choose the ELSE clause if it Richard> doesn't have to? Exactly. This should also be clarified. Sorry for the sloppy wording. Richard> What if the ELSE clause has a more efficient implementation Richard> than any others? The existence of a feature may make the Richard> program less efficient rather than more. Then you should have written your COND-IMPLEMENTS form the other way around, using NOT. (Now I finally see what NOT is for. You read this, Dave?) Richard> What bothers me is that the programmer and user know so much and Richard> the implementation knows so little. All the implementation knows Richard> about is the general efficiency of its SRFI implementations. Richard> It knows nothing about the semantic loss of a particular choice, Richard> or the actual efficieny gains. What if the semantic loss is Richard> crucial to the user, or if the program only makes minimal use Richard> of an SRFI? In neither case would the efficieny matter. I agree, but as pointed out above, the idea of COND-IMPLEMENTS is that the implementation must choose a non-ELSE branch if it can. This allows you to write down a linear conditional if you want. Richard> It makes it hard to determine what program is actually going to run. Richard> Suppose SRFI-Y defines function Y and SRFI-Z defines function Z and Richard> both require some kind of initialization. My program leads off with: Richard> (cond-implements ((and srfi-x srfi-y) Richard> ... initialize y using x ...) Richard> ((and srfi-x srfi-z) Richard> ... initialize z using x ...) Richard> (else Richard> (error "insufficient implementation"))) Richard> Later I do: Richard> (cond-implements (srfi-y (y)) Richard> (srfi-z (z))) Richard> If the implementation prefers SRFI-Z to SRFI-Y in the presence Richard> of SRFI-X, but the other way around without SRFI-X, then this will Richard> break because the second form will call the uninitialized SRFI. Richard> In fact, there is no COND-IMPLEMENTS form I can write which will Richard> necessarily call the correct function, if the implementation is Richard> free to ignore previous choices. Sure, but that's because your program is buggy. (cond-implements ((and srfi-x srfi-y) ... initialize y using x ...) (define a y) ((and srfi-x srfi-z) ... initialize z using x ...) (define a z) (else (error "insufficient implementation"))) (a) I agree this needs to be documented more clearly. -- Cheers =8-} Mike