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.
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 ( d.kolbly@xxxxxxxxxxx ( http://www.rscheme.org/~donovan/