This is an attempt to reduce the problem to its core. The thought process behind the SRFI (from first principles) is: 1. Practically every Scheme has syntax-rules or equally powerful macros. 2. Several Schemes have built-in kw args using CL-style kw objects. 3. Kawa and Racket have built-in kw args using kw as syntax markers. 4. Lambda definitions, and procedure calls, look identical in cases 2 and 3 (only with different #! #: : prefix/suffix) and can be generated easily with macros in all of these implementations, so the keyword-objects-vs-keyword-markers thing doesn't matter for portable macros. 5. Compatibility is all-important. If Scheme is to take off, we need people to write a large mass of portable libraries. Library writers need to be confident that they can reach for a portable solution when they need it. This promise is less alluring with each additional gap in compatibility. The easiest way to be fully compatible is to take the common subset of the things that implementations are already doing. 6. Compatibility should be both ways: Portable code should be able to call implementation-native keyword procedures using only RnRS read syntax; and procedures using implementation-native keyword arguments should be able to call keyword-lambdas defined by portable code. This will be difficult to do without having the portable code use macros that directly expand to the implementation-native syntax. 7. Simplicity for users is the next most important thing. Scheme is attractive because of its small core. I'd like to add the bare minimum amount to this core. It reinforces people's image of Scheme as a simple language, and frees brainpower to be spent on libraries and applications. This is why it's nice if keyword-lambda can be just like lambda. Lambda is something people already know and like. Fast code is also nice and led to a very interesting discussion. But Scheme is very fast already :) I ran some benchmarks with the naive plist implementation, and calling keyword procedures with no keywords (i.e. null rest argument) is practically identical in speed to calling non-keyword procedures. Calling with one or two keywords is 2-10x slower, but you have to do like 100K calls per second for it to matter. If native keyword args are used, it can potentially be equally fast to using only positional args. Since Marc and John care about fast calls, would you accept the current compromise where the naive plist implementation is retained as the "least common denominator" compatible option, and if faster keywords are desired, the Scheme implementation is free to have a special calling convention? Thanks to everyone for all the thoughtful comments so far!
