What I want is a simple SRFI-0 that works.  We can embellish it in a later
SRFI if necessary, but the entire SRFI project will be stillborn if we can't
agree on SRFI-0.

I could live with Feeley's original draft or with Kelsey's proposal.  Both
are a bit more general than necessary, in different ways, but that's just
a minor quibble.  I would be happier to have either one of those proposals
be accepted than to delay SRFI-0 beyond the next release date for Larceny.

I would be quite unhappy with the SRFI editors' proposal, partly because of
the nondeterminism but also because it was so elaborate that its semantics
were unclear.  My original understanding of the proposal was that the
nondeterministic choices were uncorrelated, which just wouldn't work for
reasons that Richard Kelsey explained quite well.  Then it was explained
that the nondeterministic choices were supposed to be correlated, but the
precise semantics remained a mystery.  Almost 40 years after John McCarthy
proposed his AMB operator, the semantics of correlated choice remains a
research area with many difficult open problems, and many of the things
that we have learned along the way are more complex than most programmers
can handle (e.g. CCS, CSP, Petri Nets, call-time versus run-time choice,
temporal logic).  This is not the kind of thing that people should have
to understand in order to use the most basic SRFI.

I disagree with Matthew Flatt about the problem that is to be solved by
SRFI-0.  I agree that modularity is _a_ problem, but it is not _the_
problem that we can reasonably expect SRFI-0 to solve.

My view is closer to Donovan Kolbly's, who hopes that SRFIs will contribute
to standardization of useful features, but I don't think that is exactly
the purpose of SRFI-0 either.

In my view, the point of SRFI-0 is to allow Scheme programmers to get
their work done.  Many of the features that programmers need to use
actually do exist in most implementations.  Sometimes the interface is
the same across several different implementations, sometimes it is
slightly different, and sometimes it is greatly different.  SRFI-0
allows programmers (whether individuals or teams) to specify the
interfaces to those features that are used by a particular program,
without requiring the Scheme community as a whole to agree on anything
at all, not even on what an "interface" should look like.

This is important.  We have been needing an intermediate step between
the implementation-independent standards and the grungy details of
particular implementations.  SLIB has served that purpose to some
extent, but SLIB has been limited by its failure to separate interface
from code.  With SRFI-0 we will be able to say that a program is written
in R5RS Scheme plus SRFI-0, SRFI-17, SRFI-24, and SRFI-30.  That's a lot
better than saying that it's written in Scheme 48 v0.36.  It tells me
something about what I would have to do to make the program run in
Larceny v1.0a2 or Gambit v3.0 or even Scheme 48 v0.37.

Over time, these SRFIs probably will contribute to standardization.
I certainly hope so.  But they will serve a purpose even if they don't.

--------

I will now suggest how Feeley's and Kelsey's proposals might be simplified.
This isn't very important, but having said that I would prefer to simplify
them, I feel as though I owe an explanation.

I think Feeley's proposal would be improved by adding a very small fixed
set of boolean connectives such as AND, OR, NOT.  I would be happier if
IF-IMPLEMENTS were restricted to top level, and to definitions.  I have
noted previously that the discussion of case-sensitivity in Feeley's
draft is inadequate and would best be deleted.  To simplify program
transformers, I would like to allow zero definitions where Feeley's
proposal requires at least one.  With these changes, the syntax of
Feeley's proposal would reduce to the following new or altered
productions:

    <program>  -->  <command>  |  <definition>  |  <if-implements>
    <if-implements>  -->  (if-implements <feature> <definition>*)
    <feature>  -->  <feature-id>  |  (NOT <feature>)
                 |  (OR <feature>*)  |  (AND <feature>*)
    <feature-id>  -->  a symbol which is the name or alias of a SRFI

Note that the anonymous objection to names like "SRFI-25" is an objection
to the naming conventions that have been adopted by the SRFI editors, and
is not in any way an objection to Feeley's syntax or to the above syntax.
I think the editors should rethink their naming conventions after some
SRFI-0 has been adopted.

I think Kelsey's proposal could be simplified by leaving the READER-SYNTAX,
FILES, and CODE features to another SRFI, because they are orthogonal to
the REQUIRES and FEATURE-COND forms, which suffice for the purpose of
SRFI-0.  There would not be much difference in practice between this
simplified form of Kelsey's proposal and the syntax suggested above.

That's what I want.  Something simple that would work.

Will