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.
> > Remember that an SRFI just describes a property of a Scheme system > > which is more general than an API consisting of a set of procedures > > and special forms. [...] > > True -- that issue I didn't know how to deal with. > > But then I'm having trouble seeing how `if-implements' could ever work if > SRFIs ever conflict (as they will, especially when libraries are revised). > It becomes an inherently a global operator, with no control over scope or > conflict. If two SRFI's conflict then it simply means that if-implements can't say yes on both (i.e. both can't be implemented at the same time, which is emminently reasonable since they conflict). There is no contradiction here. Note however that a given Scheme system might have two possible "modes" (for example selected with a command line option) which implements different SRFI's in each mode. In a sense this Scheme system should be viewed as two Scheme systems which happen to share most of their executable. > It sounds, then, like a system which supports conflicting SRFIs could not > support SRFI-0, which makes me uncomfortable -- I was hoping SRFI-0 could > specify anchor from which all else could be determined. It seems like you want a mechanism to **request** a specific feature within some scope... this sounds very much like a module system. SRFI-0 is not a module system, it is strictly a mechanism to **test** that a specific property holds of the host Scheme system. But you could use SRFI-0 to test if a particular module system is available. > On the other > hand, maybe some future SRFI could just contain a conflicting > specification for `if-implements' in some clever mostly > backward-compatible way, and SRFI-0 will become deprecated. This is possible, but I REALLY REALLY hope this will not happen. SRFI-0 (and the if-implements form) has to be as solid as a rock because it is the basis on which the whole SRFI business rests. That is why it has to be simple and clear, and must find widespread acceptance. I hope noone ever has a reason to propose a new SRFI, say SRFI-10, with a conflicting semantics for if-implements (for example, reversing the direction of the two branches of the if-implements), because a program containing (if-implements SRFI-1 *X* *Y*) will be meaningless (since it is not explicit whether this refers to the semantics of if-implements described in SRFI-0 or SRFI-10). If you ever feel the urge, at least consider a different name for the new form (and perhaps the SRFI editors should enforce this). Marc