I'm ready to wrap up this SRFI as soon as we decide on what to do. ### Naming There was wide agreement: * Rename keyword-lambda to lambda/kw. * Rename keyword-call to call/kw. I'll also add define/kw, which is the obvious combination of define and lambda/kw. ### Performance, aka should define/kw make lambdas or macros? I designed lambda/kw as making real lambdas (using a rest argument for the keywords in Scheme implementations that don't have real keyword args) for simplicity: if keyword lambdas behave like ordinary lambdas in as many ways as possible, there is the least potential for surprises, and maximally easy to add keyword arguments to existing Scheme procedures that don't have any yet. Marc Nieper-Wißkirchen suggested that define/kw could make macros instead of lambdas, which would make keyword calls easier to optimize. That strategy makes me a bit uneasy since making keyword lambdas subtly different from other lambdas makes it a more complicated abstraction, with potentially more edge cases that cause trouble to some users. However, I don't have any particular concrete problems in mind; simplicity is just a design instinct. A good point of comparison is when OpenBSD designed the strlcpy() and strlcat() safer string functions for libc. They could certainly have better characteristics, but the priority was to design drop-in replacements for strcpy() and strcat(). I had a similar design mentality of trying to make lambda/kw a drop-in replacement for lambda. Common Lisp compilers can optimize keyword calls, but custom compiler macros may have to be written. Gambit, Kawa and Racket probably have some optimizations of their own. I'm not really qualified to judge the issue. Preliminary benchmarks (making lambdas with way too many keyword arguments) showed predictable slowdown in the portable implementation, but calls were still reasonably fast. They might not be fast enough in a tight inner loop; my recommendation would be to avoid fancy coding techiques such as keyword arguments in the hot path. FWIW, Dybvig is generally cautious about adding new language features to Chez Scheme since their performance implications are unclear. ### Syntax The current syntax is (lambda/kw (a b c (d e f)) ...) and (call/kw 1 2 3 (d 4 e 5 f 6)). It's a non-ideal compromise to allow implementations using only syntax-rules. We came to the conclusion that almost all Schemes support another macro system, so we agreed to drop the syntax-rules compatibility requirement. That gives more design freedom. Following that decision, this was the favorite lambda syntax: (lambda/kw (a b c :key d e f) ...) The precise naming of :key vs key: vs &key is up for debate. This Common Lisp -style call syntax seemed most people's favorite: (call/kw proc 1 2 3 :d 4 :e 5 :f 6) Again, :d vs d: vs #:d is up for debate (resolved below). Other alternatives: (lambda/kw (a b c : d e f) ...) (call/kw foo 1 2 3 : c 4 d 5 e 6) (call/kw foo 1 2 3 : c 4 : d 5 : e 6) ### R7RS-large and hygienic keywords Marc Nieper-Wißkirchen expressed concern about what happens in situations where keywords can be confused with identifiers from the surrounding lexical environment. E.g.: (let ((:e 3)) (call/kw foo 1 2 :e 4)) Does the :e inside call/kw signify a keyword argument named `e`, or a positional argument whose value comes from the lexical variable named `:e`? Considerations: * While a separate : identifier would work, no existing Lisp/Scheme system with keyword arguments uses it. All of them use some variant of :foo or #:foo with the colon joined to the identifier. * Several Scheme implementations already read :e as a keyword object. This means that in practice, when reading random Scheme code from the internet, :e may already be intended as a keyword object. Hence using :e as a variable name in a portable Scheme program may be confusing to people or unreliable across existing Scheme implementations. * However, no RnRS report has keyword objects yet so standard Scheme reads :e as an ordinary identifier. It would be nice to preserve this simplicity in the standard, and add an alternative syntax for keyword objects. Kawa, Guile and Racket already have #:e. * Allowing either ordinary identifiers or keyword objects as keyword names permits hygienic keywords (which don't yet exist in any known language, but could be added to Scheme implementations that want them). I suggest we do the following: * Since SRFI 177's main goal is compatibility with existing Scheme keyword systems, it will use the syntax (call/kw foo 1 2 :d 3 :e 4). Here, :d and :e can be either identifiers (in any Scheme implementation) or keyword objects (in Scheme implementations that have them). In identifiers, the colon is recognized as either a prefix or a suffix. Since there are Scheme implementations that accept either or both, it's clearest to allow all alternatives for users of the SRFI. call/kw would scan for those literal symbols at read time, so the symbol :e inside the lambda list would shadow any lexical variable named :e. * SRFI 177 call/kw would translate all of e: and :e and #:e into the non-hygienic, global keyword name `e`. So an `e` keyword used in one Scheme library would be equal to the `e` keyword in any other library. This is the case in Common Lisp, as well as in all Scheme implementations that currently have keyword arguments. * R7RS-large should probably not use SRFI 177. If it gets keyword arguments, it could add the #:e standard syntax for global keyword objects, and could use its own version of call/kw that accepts only keyword objects. R7RS-large keyword lambdas should be specified so that: - R7RS call/kw can call SRFI 177 keyword lambdas. - SRFI 177 call/kw can call R7RS keyword lambas as long as all keywords used are non-hygienic Common Lisp-style global keywords. * While the R7RS-large keyword lambdas probably don't need to support hygienic keywords, they should leave open the possibility that a particular implementation may add them. This can be done by requiring keyword objects and leaving the SRFI 177 symbol-parsing compatibility hack out of the standard language. ### More complex keyword specifications SRFI 177 is meant to be the simplest thing that could work. Hence its lambda/kw purposefully leaves out features like: * default values for keyword arguments * mixing keyword arguments with positional optional arguments * mixing keyword arguments with a rest argument * allow-other-keys (collecting unknown keywords into a list) However, SRFI 177 call/kw is fully capable of calling procedures defined by other facilities (such as SRFI 89 or implementation-native lambda) which use these features. Since SRFI 177 is compatible, its restricted feature set does not present a problem in my opinion. Once we decide the final form of SRFI 177, and how to tackle keywords in R7RS-large, we have a good basis for writing a follow-up SRFI(s) that allow more complex keyword lambdas to be defined. Perhaps SRFI 89 or Gauche's syntax is already enough. If Marc implements hygienic keywords, those would probably have to be taken into account by specifying a version of call/kw that is different from both SRFI 177 as well as R7RS-large. It would have to be different because it needs a different way to detect which elements in the lambda list are keywords. The (call/kw 1 2 3 : d 4 : e 5) syntax could handle both hygienic and non-hygienic keywords, as could the original (call/kw 1 2 3 (d 4 e 5)). However, these syntaxes work differently from the usual (call/kw 1 2 3 :d 4 :e 5) that Lisp/Scheme programmers have used for decades. Since interest in hygienic keywords is limited so far, and there are 10 Scheme implementations as well as Common Lisp, Emacs Lisp and Clojure using the :e style keywords, I think we should go with that convention for SRFI 177. It would probably be wise for R7RS-large as well, but I'll leave that decision to others.
