I received these comments about SRFI-0 from someone who wishes to
remain anonymous.  I'm posting them to srfi-0@srfi.schemers.org for
the record.

Marc

Anonymous wrote:

1.  It is amost certainly a mistake to base feature-ids on SRFI document
    numbers.  There are many reasons why this is a bad idea, but it should
    be sufficient to point out that when I'm -reading- a piece of Scheme
    code, how am I going to figure out what `(if-implements SRFI-17 ...)'
    does?  I have to look it up somewhere.  So why not write
    `(if-implements extensible-strings ...)' instead, and save me the
    trouble?  SRFI-0 hints that there might be "aliases" for feature-ids,
    presumably nice mnemonic names, which I guess is supposed to address
    this problem.  Presumably people will be encouraged to use the mnemonic
    aliases to keep their code readable.  So then what's the point of the
    document number based IDs?  You should just be giving features mnemonic
    names from the very beginning.

2.  Logical combinations of features will be wanted all the time.  Suppose
    there is an easy way to do something only if -both- the `foo' and `bar'
    features are available.  I would like to write:

      (if-implements (and foo bar)
                     easy-way
                     hard-way)

    but instead I have to write:

      (if-implements foo
                     (if-implements bar
                                    easy-way
                                    hard-way)
                     hard-way)

    duplicating the hard-way code.  Yes, I can write my own feature testing
    macro that implements "feature expressions" and expands into the
    appropriate nest of `if-implements' expressions, but this is such a
    common thing to want that it might as well be built in to the basic
    mechanism.

3.  I'd like to have something with a `cond'-like syntax, instead of an
    `if'-like syntax.  I can always define this myself, but I'm mentioning
    it here anyway because it might provide a clearer way to decide when the
    lack of -any- matching feature is an error: you can use the lack of an
    `else' clause to indicate that one of the alternatives -must- be true.
    For example:

      (cond-implements (foo a b)
                       (bar c))

    is equivalent to `(begin a b)' if `foo' is an available feature, it is
    equivalent to `c' if `foo' isn't available, but `bar' is, and it is an
    error if neither `foo' nor `bar' is available.  Then I can include an
    empty `else' clause if it is OK for neither `foo' nor `bar' to be
    available.  The value of such `cond-implements' expression can be the
    usual unspecified value.

My reply was:

I am (now) also leaning towards a multiway conditional and the use of
"and", "or", "not".  I like your idea that a non-existent "else"
clause indicates that an error must be signaled if none of the SRFI's
are available.

About the "SRFI-n" feature-ids which you find less readable than
explicit feature names, I agree that it would be more readable but
there is a problem with naming different versions of a feature (i.e.
a SRFI author who extends his/her SRFI to add some functionality thus
creating a new SRFI), or different proposals for similar features
(i.e. different authors writing SRFIs to provide a given feature).
Let's say you wrote a SRFI named "extensible-strings" and I have what
I think is a better way of doing extensible strings, how will we call
my SRFI?  extensible-strings2?  I prefer to use a boring SRFI-n name
until a particular extensible string SRFI has become well accepted,
and then the editors can attribute an alias like "extensible-strings"
to the accepted SRFI.  At this point we are back to the same problem
as before, but the problem is less severe because there is less of a
chance that counter proposals will surface.

Anonymous replied:

Naming your proposal `extensible-strings2' is better than naming it
`SRFI-259'.  I have some chance of remembering what `extensible-strings2'
means.  I expect that there will usually be some way to capture the
difference between two proposals that is better than naming the one `foo'
and the other `foo2', but even if that is the best that you can do, it
still beats `SRFI-23' and `SRFI-259'.