I think losing first-class-ness is too much cost to pay.  Gauche heavily uses keyword arguments
for implementation-specific extensions to ordinary procedures, and that's the merit of keyword
arguments---you can add extra feature to existing procedures; if you need to define macros,
you can define another procedure just as well.

Besides, efficiency arugment isn't convincing to me.  Srfi-177 doesn't say keyword arguments
should always be processed as if passed asrest arg, so an implementation is free to optimize
when the caller provides keyword argument via keyword-call (as opposed to apply).

On Wed, Oct 16, 2019 at 11:17 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

SRFI 177 gives a number of good reasons why one wants to add/invent
keyword arguments to procedures. One reason is those keyword arguments
allow one to introduce new parameters without breaking old code.

However, this shouldn't come with the price of decreased efficiency.

In the portable R5RS/R7RS sample implementation coming with SRFI 177,
whenever a procedure defined with `keyword-lambda' is being called, a
lot of work for the keyword dispatch is done, which causes procedures
defined through `keyword-lambda' to be noticeably less efficient than
ordinary procedures defined through `lambda'.

The same will most likely be true for native implementations when the
call site does not know the called procedure as it will most likely
have to resort to runtime dispatching as well.

Therefore, I think it is much better if "procedures" taking keyword
arguments are implemented as macros instead, the runtime dispatch
overhead into a compile-time dispatch overhead, which is fine.

Of course, "procedures" taking keyword arguments wouldn't be
first-class procedures anymore, but I don't see a convincing use case
where this would matter.

We can even get rid of `keyword-call', whose current need is a bit unfortunate.



P.S.: In case someone finds them valuable, a number of arguments in
favor and against keyword arguments are raised here: