This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
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