On Wed, 6 Jan 1999, Marc Feeley wrote:

> Note however that a given Scheme system might
> have two possible "modes" (for example selected with a command line
> option) which implements different SRFI's in each mode.  In a sense
> this Scheme system should be viewed as two Scheme systems which happen
> to share most of their executable.

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 ..

A portable implemenation of `program-suggests' is a NOP.  Then my
implementation can support no SRFIs by default (or just a few of my
favorites, e.g., any with a global impact on lexical analysis or whatever)
and import them on-demand in `program-suggests'.  The implementation is
advised to not make available conflicting SRFIs.

Basically, I am trying to move your out-of-band mechanism in-band to ease
the user burden of figuring out how to turn on the right features in
their Scheme system to get a program to run.  The programs ability to test
if it can run falls far short of helping the user figure out how to do so.

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