> I think we editors have pretty much adopted Richard's view that the
> whole feature business should happen in a separate configuration
> language.  His message is at:
>
> http://srfi.schemers.org/srfi-0/mail-archive/msg00020.html

I've looked at Richard's proposal and, generally speaking, the idea of
a separate configuration language for programs is compatible with the
cond-implements form as I see it but it is not the only way to go.  I
don't want to discuss the specifics of Richard's proposal at this
point because I think this would be premature.

The fundamental problem is that we want a way to express the fact that
a certain piece of code in our program (a "chunk" so as to not use the
term "module") is dependent on some SRFI.  Richard's proposal places
this information outside of the chunk.  It seems to me that the only
reasons for doing this is that we don't have a formal notion of what a
chunk is (i.e. a scope) and a way to define chunks and the things it
is dependent on (other chunks, SRFIs, etc).  This cries out **MODULE
SYSTEM** to me.  Yes I know that we don't currently have a module
system, but this is clearly where such information should be placed.

Note that I'm not saying that a configuration file for programs (such
as the one suggested by Richard) doesn't have a place.  In fact, I'm
pretty sure such a thing is useful to glue the various modules
together.  All I am saying is that, for modularity reasons, the SRFI
dependency information should be put on the module, not in the program
configuration file.  As an example (intentionnaly naive), if we
defined a "module" to mean a source file, then we could say that the
first couple of forms in that file declare the dependency information
and the scope of these declarations extends to the end of the file.

Matthew Flatt's variant of Richard's external configuration language
is a more modular approach, closer to what I have in mind.  However, I
think this should not be part of SRFI-0 and the reason is simply that
we need something **NOW**.  Agreeing on a module system will take a
long time.  So what I want to propose for SRFI-0 is simply a
cond-implements form that tests for the presence of a feature.  Future
module system SRFIs or configuration language SRFIs can provide
mechanisms for requiring that the Scheme implementation provide a
particular feature, possibly limited to the scope of a particular
module or whatever.  Until such module SRFIs surface (!) it will be up
to the user of a piece of code to add whatever is needed for their
Scheme implementation to satisfy the cond-implements forms that are
found (in fact I can easily imagine an automatic tool, supplied with
each Scheme implementation, that would do this automatically... i.e.
the tool tries to load the program and, if it bombs at load time
because some SRFI hasn't been put in the configuration file, it adds
this dependency to the configuration file, and tries to load the
program anew).  What isn't obvious to me is how to word SRFI-0 so that
it will be compatible with future module SRFIs (in my original
proposal feature identifiers had global scope, i.e. a particular
feature either is available in all parts of the program or is not, but
the notion of a not-necessarily-global "feature identifier scope" has
to be part of SRFI-0).

Marc