I generally like the suggestion for changing SRFI-0 to use COND-IMPLEMENTS
plus IMPORT-IMPLEMENTATION.

However, I am trying to figure out the usefulness of the `OR' construct in
COND-IMPLEMENTS.

Since the bindings are only accesible from IMPORT-IMPLEMENTS, which names
a specific feature, any use of OR would involve (elsewhere) an expansion
of that OR into its clauses for the purpose of importing the
implementation.

Suppose SRFI-42 is a better version of SRFI-11, but they do enough of the
same thing for this application.

You can't write:

  (cond-implements
   ((or SRFI-11 SRFI-42)
     ..app-specific defns using intersection..))

because the bindings aren't (necessarily) available.

But you can't import either, because you don't know which one matched.
It seems you have to write:

  (cond-implements
   (SRFI-11
    (import-implementation SRFI-11))
   (SRFI-42
    (import-implementation SRFI-42)))

  (cond-implements
   ((or SRFI-11 SRFI-42)
    ..app-specific defns using intersection..))

which, while tractable, seems a little odd.

I guess OR would be useful by itself for truly global features (though I'm
not sure what such a thing would be -- even something like case
sensitivity can be an option.)

Thoughts?

Does anybody have any experience with analagous capabilities in other
systems to get an idea of how complicated the expressions are likely to
get?  I have seen some seriously hairy #ifdef trees in C...  (which makes
me wonder if we should put in a #define-analog in SRFI-0, or wait for
later.  Probably later... SRFI-0 is for the library user; we need other
capabilities besides for the library writer.)

-- Donovan Kolbly                    (  RScheme Development Group
                                     (  xxxxxx@rscheme.org
				     (  http://www.rscheme.org/~donovan/