> It has been argued that "procedures" taking keyword arguments shall be > first-class procedures (so they cannot be implemented as macros, which > I would have preferred). My argument for that is just compatibility and uniformity. For example, if an RnRS procedure is extended with keyword arguments, that can't be done in a compatible way if the keyword procedure cannot act like a normal procedure in every way. > First-class procedures with keyword arguments without any way to > forward unknown keyword arguments lose much of their power, though. > Thus, I think that if we want first-class procedures with keyword > arguments, we also need some mechanism to forward unknown keyword > arguments. I agree; it would be great to standardize that mechanism! 177 cannot can only have things that all implementations already supprt. But nothing stops us from writing SRFI 178 with a lambda/kw that supports allow-other-keys :) If it's a compatible superset of SRFI 177 functionality, then users can import whichever SRFI they like. It's also possible to define another macro like `lambda/kw*`. But maybe it's best to extend lambda/kw. In either case, we should study how Gauche does it, since it has the most comprehensive allow-other-keys handling (it can separate recognized keyword args from unrecognized ones, as Shiro explained).