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.
>>>>> "Donovan" == Donovan Kolbly <donovan@xxxxxxxxxxx> writes: Donovan> However, I am trying to figure out the usefulness of the `OR' construct in Donovan> COND-IMPLEMENTS. [ ... ] Donovan> Suppose SRFI-42 is a better version of SRFI-11, but they do enough of the Donovan> same thing for this application. Donovan> You can't write: Donovan> (cond-implements Donovan> ((or SRFI-11 SRFI-42) Donovan> ..app-specific defns using intersection..)) Donovan> because the bindings aren't (necessarily) available. Donovan> But you can't import either, because you don't know which one matched. Donovan> It seems you have to write: Donovan> (cond-implements Donovan> (SRFI-11 Donovan> (import-implementation SRFI-11)) Donovan> (SRFI-42 Donovan> (import-implementation SRFI-42))) Donovan> (cond-implements Donovan> ((or SRFI-11 SRFI-42) Donovan> ..app-specific defns using intersection..)) Donovan> which, while tractable, seems a little odd. This is how we figured. We actually thought (well, *I* did) of allowing a general feature requirement in IMPORT-IMPLEMENTATION as well, so you could write: (cond-implements ((or SRFI-11 SRFI-42) (import-implementation (or SRFI-11 SRFI-42)))) Unfortunately, we couldn't think of a way to specify this cleanly and without obscuring the explanation. You really want to leave unspecified which set SRFIs the implementation imports for a given requirement, just as long as it satisfies the associated logical formula. This, in turn, can lead to obscure bugs in interaction with COND-IMPLEMENTS. So we decided to just allow this simple form of IMPORT-IMPLEMENTATION. Anyhow, the real trick is to figure out what the usefulness of NOT is ... :-) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla