>>>>> "Donovan" == Donovan Kolbly <xxxxxx@rscheme.org> 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