> I guess that answers my question -- any management of conflicting SRFIs is
> to be outside the SRFI mechanism itself (or at least SRFI-0).
>
> I appreciate and agree with your goals for a simple `if-implements'.
> However, I am have some remaining concerns.  I wouldn't want a user to
> have to try a bunch of different command-line options to get a program to
> load!
>
> Perhaps this is the solution:
>
> Would a reasonable SRFI, in your view, specify a "program-suggests"
> special form whose effect is to communicate to the Scheme system that the
> program is going to test for some features (SRFIs) and would very much
> like to have them available if possible.  The implementation is free to
> ignore the suggestions if it so chooses.
>
> e.g.,
>
>    (program-suggests SRFI-1)
>
>    (if-implements SRFI-1
>     'cool
>     (error "you lose -- go get a real Scheme system :-)"))
>
>    ... blah blah blah using SRFI-1 features ..

I'm not fond of this idea.  Once again the problem is binding time...
when does the suggestion of the (program-suggests SRFI-1) take effect?
If the compiler can satisfy the suggestion, which branch is
chosen in (if-implements SRFI-1 A B) if

1) the form (if-implements SRFI-1 A B) is after (program-suggests SRFI-1)
2) the form (if-implements SRFI-1 A B) is before (program-suggests SRFI-1)
3) the form (if-implements SRFI-1 A B) is in another module

I don't see any good answers... and because there are so many
variations possible I suggest that such a mechanism be relegated to a
separate SRFI.

On the other hand I really think that what you want is a module
system.  In fact I think that the SRFI process should not be used for
specifying sets of procedures that could easily form a module (for
example SRFI-1).  SRFIs should mainly focus on describing basic
functionalities that can't be implemented portably and that have to be
part of the Scheme system itself.  Things like: modules, exceptions,
records, IEEE floating point, Unicode, binary I/O, etc.

Marc