Re: Wrapping up SRFI 177: Portable keyword arguments Lassi Kortela 23 Feb 2020 00:12 UTC
> 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?