> I understand your point that SRFI 177 shall be compatible with existing > keyword systems as far as this is feasible. Thanks. Indeed, the major advantage of the current draft is that it's compatible with all existing ones. But there may be other approaches that are compatible as well. > But we also have to make sure that SRFI 177 is compatible with whatever > SRFI about keyword arguments that will finally make it into R7RS-large. > As we don't know that SRFI yet, we may have to be a bit conservative. Agreed. It would be sad if 177 ends up incompatible with R7RS-large. > To me, now the question comes up how to write specifications for SRFIs > that want to make use of keyword arguments. There implementation may > depend on a specific system like SRFI 177, but the interface should be > opaque. > > How would you write this? I would not make those SRFIs depend on 177, but would simply talk about "keyword arguments" in without referring to a particular keyword SRFI. > A related question is: How can we make sure that if we have two > implementations of a keyword system, say of SRFI 177 and of SRFI 277, in > a Scheme system, they can talk to each other? It's good that you bring this up again now that we have explored more alternatives. We should probably write a document that is even shorter and simpler than SRFI 177, specifying a minimal set of guarantees given by Scheme implementations and future standards for keyword arguments. It would specify something like: 1. it's possible to make a procedure taking optional keyword arguments, default value #f. 2. other kinds of keyword arguments may be possible as well, but they are compatible with point 1. 3. the implementation provide one or more systems that can define and call keyword procedures. keyword procedures conforming to point 1, defined using any of those systems, can be called via any other one of the systems. So it would give the bare minimum that lets people write SRFIs using keywords, confident that implementations and R7RS-large will keep the interoperability promise. Meanwhile, R7RS-large and implementations would be free to explore more sophisticated keyword systems as long as they can express a subset that is compatible with the promise. Having an explicit promise like this would probably be good for everyone's peace of mind, would give clarity to specification efforts, and would let us start writing SRFIs making simple use of keyword args without fear of future incompatibility. How would this sound?