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