Another mistake in my long posting:  It doesn't make any sense to have an
IF-IMPLEMENTS with no definitions.

I suggested that IF-IMPLEMENTS be restricted to top level, and to
definitions.  Marc Feeley asked:
> Why?  How does this help the implementor or user?

Restricting IF-IMPLEMENTS (or COND-IMPLEMENTS, or whatever its name may
become) to top-level would have these advantages:

    *  A programmer scanning for uses of IF-IMPLEMENTS wouldn't have to
       look at all of the code, just the beginnings of the top-level
       forms.

    *  A program-walking tool that needs to locate all uses of
       IF-IMPLEMENTS wouldn't have to macro-expand the entire program,
       just enough of the top-level forms.

    *  There will be less confusion about the "scope" of features that
       are mentioned in an IF-IMPLEMENTS form.  If IF-IMPLEMENTS can be
       used inside a local scope, then some programmers will think that
       the "scope" of the feature requested by the IF-IMPLEMENTS is local
       to that scope.  This is likely to cause confusion because...

    *  SRFI-0 is written as though none of the SRFIs will be in conflict
       with other SRFIs, or at least as though no implementation will
       support two SRFIs that are in conflict.  This is unrealistic.
       Larceny will probably support some SRFIs by loading or linking
       them on demand.  This allows conflicting SRFIs to be supported,
       though not within a single program.  If the syntax of SRFI-0
       misleads programmers into thinking that an IF-IMPLEMENTS can have
       local scope, then some of them will try to use conflicting SRFIs
       within a single program by exploiting those nonexistent local
       scopes to keep them apart.  Users don't like to waste time trying
       things that don't work, and implementors don't like to waste time
       dealing with spurious bug reports.

The main advantage of restricting IF-IMPLEMENTS to definitions is greater
portability.  When restricted to definitions, SRFI-0 can be implemented
as an R5RS macro.  The unrestricted SRFI-0 cannot be implemented as an
R5RS macro, which will make it unnecessarily difficult to port SRFI-using
code to implementations that don't support SRFI-0.  This would limit
acceptance of the SRFI-0 mechanism, on which the entire SRFI enterprise
depends.

I suspect that most implementations that won't support SRFI-0 won't
support R5RS macros either, but many of them will provide a macro facility
that would be good enough to implement a definition-only SRFI-0 but not the
definition-or-expression version that has been proposed.

Anything that could be accomplished by a top-level IF-IMPLEMENTS expression
could be accomplished by an IF-IMPLEMENTS definition of a nonary procedure
followed by a top-level call to that procedure, so restricting IF-IMPLEMENTS
to definitions would improve portability without hurting expressiveness.

Will