> About performance and making it macros--
>
> To argue for macros based on performance is only valid when you want to
> implement such optimization
> portably.  An implementations can always employ inlining
> keyword-argument parsing, therefore process keyword
> argument binding at compile-time, as far as it can prove the procedure
> binding is not altered and all the keyword
> arguments are available at call site literally (such condition is
> _forced_ if lambda/kw creates a macro, but that
> only restricts the use of keyword arguments.)

Good point.

If define/kw were a macro, and there was no lambda/kw at all, then it
would be possible to specify define/kw such that only literal keywords
known at compile time are allowed. So there would be no need to account
for the possibility that keywords need to be parsed at run time. Whereas
in traditional Lisp, parsing them at run time has been the default thing
to do, and parsing at compile time is an optimization.

> So, the question should be if we want a _portable_ optimizing
> implementation or not.  If it's just a possibility
> to allow *some* implementations to do optimization, they can do it
> without forcing it a macro.

IMHO the portable implementation doesn't need to be fast. You have to
have unrealistic numbers of arguments or calls/second for it to really
matter. In that case, it's best to avoid keyword lambdas in the hot path
and use ordinary lambdas. I guess some 3D graphics software uses
complicated argument lists for procedures that need to run fast. But
that's quite fringe. The point of keyword args is to be optional; and
optional args require conditional statements in the procedure body. Why
would we put so many conditional statements into the hot path?